Scrub code lines from backtrace/Sentry event

[jarmo]

Currently, when raven-ruby is used, then by default private data is sent to the Sentry server, which is called context. It includes actual source code lines related with the exception. This should not happen at all or it should be configurable at least. Sending the actual backtrace is okay.

[moll]

Same problem with the Node plugin @ getsentry/raven-node#49.

[dcramer]

You don't want to send the line of code with the backtrace?

You can install a processor to scrub data in the plugin, but this is very uncommon behavior and I dont see a need for this being builtin.

[jarmo]

Yes, i don't want to send any actual source code to 3rd party servers/services, because it might include some sensitive information and might give an advantage to any possible attacker if sentry server(s) will be compromised with that data lying there. Imagine if my sentry account gets compromised how easy it would be for attacker to start trying out different attack vectors by looking at the source code after each exception.

This functionality just feels going back to 90-s when Apache servers were incorrectly configured by default so anyone could read your php source code in files with .inc extensions.

You're okay with sharing your source code with 3rd party services?

[dcramer]

You can self host Sentry if that's a concern, but really a lot of the power is in that ability to introspect things.

On Sat, Sep 14, 2013 at 5:59 PM, Jarmo Pertman [email protected]
wrote:

Yes, i don't want to send any actual source code to 3rd party servers/services, because it might include some sensitive information and might give an advantage to any possible attacker if sentry server(s) will be compromised with that data lying there. Imagine if my sentry account gets compromised how easy it would be for attacker to start trying out different attack vectors by looking at the source code after each exception.
This functionality just feels going back to 90-s when Apache servers were incorrectly configured by default so anyone could read your php source code in files with .inc extensions.

You're okay with sharing your source code with 3rd party services?

Reply to this email directly or view it on GitHub:
#130 (comment)

[jarmo]

Self hosting does not solve the problem, because there's still some other service which has access to the source code in addition to the VCS and the actual application itself.

[dcramer]

What are you hoping to get out of sentry if it can't show you any context around an error?

If you're hosting it yourself why can't you simply secure the server like anything else. 

IMHO you're overthinking the vulnerabilities here. It's only sending bits of the source and it'd be pretty difficult to piece it all together.

On Sat, Sep 14, 2013 at 6:09 PM, Jarmo Pertman [email protected]
wrote:

Self hosting does not solve the problem, because there's still some other service which has access to the source code in addition to the VCS and the actual application itself.

Reply to this email directly or view it on GitHub:
#130 (comment)

[moll]

Come on, this is a security issue — data leakage beyond the scope of an "error reporter". Its uncommonness is merely because most developers don't think of security or privacy issues even if they hit them in the ass.

[jarmo]

I can get out stactraces out of Sentry and then look from the logs and add some additional logging around these lines.

Don't say you're actually thinking of implementing of showing values for local variables as in #7 ?

[dcramer]

More than welcome to your opinion but were going to have to disagree on the security side here. 

Like I said its possible to create a sanitizer (and it should be fairly easy). From the product standpoint we don't see this as important to our uses or our customers so it's not something we plan to build ourselves.

On Sat, Sep 14, 2013 at 6:19 PM, Andri Möll [email protected]
wrote:

Come on, this is a security issue — data leakage beyond the scope of an "error reporter". Its uncommonness is merely because most developers don't think of security or privacy issues even if they hit them in the ass.

Reply to this email directly or view it on GitHub:
#130 (comment)

[moll]

Hehe, seems exactly as I said most developers behave. 😏

Build exactly what? I'm taking @jarmo doesn't want his private data to be sent with the notification. Now it's time to either destroy the leaking bit that someone already built or just make it configurable, which is hardly building.

[jarmo]

@dcramer: What are you implying with that statement exactly? Are you saying that privacy and security of users are not that important as it is troubleshooting of errors? Are you saying that as a software developer and not as a product owner?

Do you mean that i should create a sanitizer similar to Raven::Processor::SanitizeData?

[dcramer]

Ya just create a sanitizer processor. Well accept a PR, but have absolutely no plans to make it the default behavior.

On Sat, Sep 14, 2013 at 6:35 PM, Jarmo Pertman [email protected]
wrote:

@dcramer: What are you implying with that statement exactly? Are you saying that privacy and security of users are not that important as it is troubleshooting of errors? Are you saying that as a software developer and not as a product owner?

Do you mean that i should create a sanitizer similar to Raven::Processor::SanitizeData?

Reply to this email directly or view it on GitHub:
#130 (comment)

[nateberkopec]

+1 on making this a processor included in the repo, but not on by default.

[nateberkopec]

So, I'm confused a bit now on what people believe is the sensitive information here - the issue above seems to indicate differing views (line numbers, actual lines of code). What about module names? Are those too sensitive to be sent?

Here's an example stacktrace frame that Sentry might send. Currently, this processor I've created in the above PR wipes ALL of this and sends NONE of it to Sentry:

{"abs_path"=>"/Users/nateberkopec/Documents/code/raven-ruby/spec/raven/processors/removestacktrace_spec.rb",
        "function"=>"block (2 levels) in <top (required)>",
        "pre_context"=>["  end\n", "\n", "  it 'should remove stacktraces' do\n"],
        "post_context"=>
         ["    binding.pry\n", "    expect(data['exception']['stacktrace']).to_not eq(nil)\n", "    result = @processor.process(data)\n"],
        "context_line"=>"    data = Raven::Event.capture_exception(build_exception).to_hash\n",
        "lineno"=>12,
        "in_app"=>false,
        "filename"=>"raven/processors/removestacktrace_spec.rb"}

See that PR with instructions on how to use this processor. Please give it a shot and let me know if it works for you.

[nateberkopec]

Considering this closed. If you feel you need configurability on this, please open another issue.

Adding the RemoveStacktrace processor instructions are here.