Thu 9 Apr 2009
Displaying internal errors to the customer
Posted by Slavik under SQL injection, security
[5] Comments
I recently had a discussion with our development team about displaying stack traces to the customer.
Looking at this from a support point of view, no doubt that if a customer can tell support exactly what the problem is, it will shorten the investigation and will allow support to pinpoint the issue faster. On the other hand, looking at this from a security point of view (my argument), displaying stack traces can disclose a lot of information about the internal structure and workings of the application and this is something an attacker can use. Also, SQL injection attacks can use errors returned from the database to retrieve information from the database. For SQL injection, in-band attacks are the easiest to exploit and displaying errors allows that. If nothing is displayed to the attacker except a generic message, the attacker is forced to try out-of-band or even blind SQL injections which are harder to use.
Here is an example I got from Guy Lichtman after the discussion while he was browsing MSNBC.com on his mobile.
System.NullReferenceException: Object reference not set to an instance of an object.
at Msnbc.Workbench.Rendering.FrontComponents.MobileVideo.GetVideo(HttpContext context, MobileVideoData mobileVideoData, Boolean isMappedId) in
d:\tfsbuild\techno\integration\Sources\WB\Site\Rendering\Bin-Sources\Msnbc.Workbench.Rendering.FrontComponents\MobileVideo.cs:line 242 at Msnbc.Workbench.Rendering.FrontComponents.MobileVideo.Process(HttpContext context, Object componentData, WorkAreas workArea, String device, Site site, PageParameters pageParams) in
d:\tfsbuild\techno\integration\Sources\WB\Site\Rendering\Bin-Sources\Msnbc.Workbench.Rendering.FrontComponents\MobileVideo.cs:line 155
An attacker can learn from the exception some info regarding file system layout and code package naming conventions. It is then possible to do some Google hacking on the package name and find out even more…
Google hacking
Eventually, we agreed on the following course of action:
1. Generate a public/private key-pair for support
2. Distribute the public key with our software
3. Encrypt the stack trace with the public key before displaying on screen
4. Create a small utility for support to decrypt the stack traces when received from customers
How did you solve this problem?
5 Responses to “ Displaying internal errors to the customer ”
Trackbacks & Pingbacks:
-
[...] talked about displaying errors from the database on the user screen a while ago. In my opinion, this is definitely a big no-no and a security problem just waiting to [...]
What do you do with log files and core files ? Do you also encrypt them ? They also reveal information (error messages and stack trace) about the structure of your application. They are accessible to some (inside) users.
@Ralph
You are right in saying that all of those log files, dumps, etc. are revealing but if you have access to the machine there are many ways for you to find the information including tracing, debugging, reversing, etc. You have to do a lot of hard work to prevent someone for reversing your code (packers, anti-debugging techniques, function encryption and many more).
On the other hand, if you are an attacker with only remote access to the application, I see no reason why I shouldn’t put speed bumps in your way with only minimal effort on my side.
“before displaying on screen”
It is only a speed bump, and a minor one. If someone talented wants to hack your system then he will know how to bypass the encryption, and get the raw trace from the memory.
@Marton
).
Sure, it’s only a speed bump. If a hacker targets your application he has many weapons at his disposal. But, if he has only remote access, I don’t see why I should help him by displaying errors on screen. Getting to the memory to do raw trace requires local access and outside hackers don’t have that (at least initially