Comments on: Displaying internal errors to the customer

By: Tapulous MySQL Error and SQL Injection vulnerability » Musings on Database Security

Thu, 07 Jan 2010 06:36:15 +0000

[...] 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 [...]

By: Slavik

Slavik — Mon, 30 Nov 2009 08:07:47 +0000

@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 ).

By: Marton

Marton — Mon, 30 Nov 2009 01:30:25 +0000

“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.

By: Slavik

Slavik — Fri, 10 Apr 2009 21:03:28 +0000

@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.

By: Ralph

Ralph — Fri, 10 Apr 2009 18:46:09 +0000

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.