6

I apologize if this is a dumb question.

I recently came across a website that embedded its error log out in a JSON response if the request to the website failed. In this case, it appeared there was a DB mismatch and it printed the SQL request, including the DB table's structure, to the console like so:

SQL Statement

How unsafe/dangerous is this, and why?

My gut tells me this is bad practice and is not very safe, but I can't exactly pinpoint the reason why.

  • 5
    The least information you give to the attackers, the better. – ThoriumBR Aug 15 '18 at 18:13
  • 1
    It is both useless to the client getting this back (he can change nothing on his side in order to resolve that, it is not like it was using a wrong URL...), so it smells more like some debugging feature left open in production, and if of course give internal details to the outside, which by just themselves may not be a big deal (except sometimes you will even see DB passwords in that stacktraces or other credentials like that) but will certainly help anyone wanting to mount a more specific attack. So there is no valid reason to keep that in production for the public.It shows sloppy programming – Patrick Mevzek Aug 15 '18 at 18:58
9

What you are referring to is potentially an error-based SQLi vulnerability, which falls under a larger category known as In-band/Classic SQL injection. Essentially, these vulnerabilities allow an attacker to both launch an attack as well as gather information about the database from the same communication channel. I say it is only a potential vulnerability because we are not sure if you've actually tried SQLi, rather you've just discovered an error. This can be confirmed via testing, assuming permission.

The error-based SQLi vulnerability you are potentially seeing provides information about database structure (as you've pointed out) which aids in enumeration of the database (potentially the entire database) for the attacker.

It's saying, "Hello friendly internet user who I have no reason to mistrust, the query you are trying to perform (with obviously no malicious intent) is unfortunately incorrect, so here is the exact structure of my database so that your next query can be more appropriately written to achieve success!"

Such a verbose error message should be disabled on a live site or logged to a file with restricted access. A better practice would be to, depending on the situation, provide the user with either a 400 or 500 error while being cognizant to not provide more information than is absolutely necessary.

  • 1
    I would argue for a generic 500 error page instead of a 404, clear to users and less likely to have side effects with web crawlers. – LukePH Aug 16 '18 at 1:20
  • 1
    @LukePH That's fair, though I think it really depends on the situation and request being made. More context is needed but I'm going to edit my post because I think it would be more appropriate for either a 400 or 500 error, but not a 404. – waymobetta Aug 16 '18 at 1:48
0

Disclosing your table structures is not inherently dangerous and opens no new security issues that didn't already exist in your application. It may assist an attacker to find an existing exploit in your application but very likely they will be able to work out the table structure anyway.

Almost every website I have seen the code for has the HTML form input names exactly the same as the db columns as there is really no need to translate them. Usually the only other columns you can't see while submitting are things like id, created_at, deleted_at, author_id and other obvious things. Also considering there are numerous open source websites where you can read the whole schema but those websites are still secure.

The main issue with this example in particular is it seems to be a development debugging tool which was not intended to be left in production. The information in this example in my opinion is not sensitive but often debugging tools will give other information which can be very unsafe to give out such as ENV vars which can contain passwords.

If you care about security you should be filtering the params the user can send so the user isn't able to update things like the role column on their own account. The user knowing the fact that there is a role column won't help if the server rejects that param.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.