Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Is it safe to display the detailed query in the error webpage with the below details?
**INSERT statement conflicted with the FOREIGN KEY constraint "ABC". The conflict occurred in database ** The statement has been terminated.[INSERT INTO ** ] **
I know that showing this kind of error will help penetration testers and hackers, but I need someone to shed lights on this. How can this information be used for SQL injection or that kind of things? Or is it okay to display such sensitive information?
End users should never get to see the gory details of your environment.
Instead it is more professional to show a generic 'Sorry something went wrong' page. At least visitors can see that you have a real error handling mechanism present on your website.
However those errors should be written to the mysql error log and should also trigger a notification by E-mail or otherwise to the IT team. Those errors should not happen so it can be a sign that your site is failing or is possibly under attack.
No it is definitely not safe because it creates additional SQL injection attack vectors not present otherwise. Example: If you have an SQL injection flow in an insert then this is some kind of "blind" injection because the insert doesn't report back any result rows to the caller. But if you bring a potential insert error message back to the client then you make this vulnerable to the so-called "XPath" injection (see this paper for details). The essence is that you inject an xml function that is supposed to compute a variable of data type xml. One of the function's arguments is an xpath variable which can again be computed by select statements and string concatenation. Instead of providing a valid xpath you do a select (E.g. "select password_hash from users where id='admin'"). So the DB will execute an INSERT that is purposefully wrong through your injection. The result will be an error message like
'bb9af55cd325deaa89bb7b4e36085b4d' is not a valid xpath
If you display error messages like these to the caller this can be used to basically enumerate the DB. I have seen this happening recently. The error message was cut to 30 characters and it was only possible to select one column and one row at a time but still possible to enumerate the entire DB with it.
Others have rightfully touched on why MySQL details should not be exposed via the main user interface of a website/application on a production server.
But there is a broader, much more high level issue in play when you display errors to an end user like this:
Meaning you are a riper target for hacking not because of the content of the details but because the details have been exposed to begin with.
Your attitude as an application developer—systems administrator and such—is to make your final product can fail gracefully in some way that does not expose the “bones” of the system’s architecture yet still somehow convey some useful debugging data to you.
If your application is correctly designed, displaying the text of error messages should not be a security problem. If it was, it would mean that your security relies on obfuscation which is considered as bad practice.
That being said the real question is: what will be the user experience facing messages like that? If your application is meant for average users, they will get an message that bring them no useful information: either they do not understand anything or cannot do anything useful with it. Worse, they could think those lazy devs did not even correctly process their errors - that is what I would think...
That's the reason why the common usage is to display a softer message saying something went wrong, please retry and contact support if the error persists, without the gory details. The full error message should only be displayed when the application is run by the support in a special mode because support techs are interested in the error details.
If you really want to do the nicest job with errors:
This last possibility only makes sense for high value applications with a limited number of users. That will allow the support to immediately have all the references for the problem when they will be contacted by the user. But it also means that you are ready to answer individually for any error which could be really expensive for normal applications.
Any technical detail that can be obtained by an attacker can potentially be leveraged to exploit flaws or to get a better understanding of the system (to later on exploit flaws..). In your case it could possibly be leveraged for SQL Injection but it could also allow one to identify your DBMS (if you use native queries with functions proper to MySQL for example), and then test DBMS-specific exploits if the system is not patched.
So to answer the question : no, it is not safe to disclose your queries because doing this increases your security risk.
As mentioned in the comments, the best practice is to hide such information in production environments.
A common practice (for example Maven profiles for Java developers) is to build a project for a specific environment. The "production" profile would have a different configuration that does not show stacktraces on the html responses but only log them in the backend instead.
As a sidenote, displaying technical error messages might also "attract" random attackers that want to hone their skills by hacking any system, as it makes you look like a weak target.
A number of answers have pointed out that it's not best practice to display these errors. However, I'm going to focus on your question: is it safe?
Lets have a look at an example error message. This app is written in Python and Flask:
This tells us a few things about the application: it's using SQLite, the app is in c:\jobs\token\, there's a table data and a few other things.
There is no user data here. It doesn't reveal another person's account balance, private messages, anything like that. While it's possible an error message could reveal that, in practice that is rare.
So how confidential are the application details? The main concern here is making life easier for an attacker. Certain vulnerabilities, such as path traversal and SQL injection are easier to exploit with a bit of information leakage in the error messages. However, they are still exploitable without the information leak - it's just harder work. Restricting error messages does not stop these attacks. It only makes exploitation slightly harder. The change is so minor I don't even consider it when I'm assessing the risk of a vulnerability like SQL injection.
So, the answer to your question is yes, it is safe. It's not best practice, but in no way is it particularly unsafe.
Giving out details of your database setup is generally a bad idea. Legitimate users should not need to know about it and malicious users may find something there that they'd otherwise have to make guesses at.
Other answers have rather well detailed what kind of risk this may pose to your database.
Showing the error report may also open a whole new attack vector in your website. Say, what if I requested the document with ID <script>alert('XSS')</script> — likely that one is not found in the database and I get the error report. Error handlers often are not the most carefully built part of a codebase, so I may just have managed to execute an XSS attack against the site.
Syntax error messages for SQL statements should never be revealed, as that would really save time for the attacker trying to exploit an SQLi vulnerability.
Application line numbers are less severe, but from a security perspective, the error page should not reveal any details, because error pages are often an intermediate step used to complete a successful hack.
If you wish to keep the convenience of detailed error pages, I would recommend configuring your system to only reveal such details to authorized persons based on LAN IP address, and perhaps also some Cookie-based authentication. If code your own custom error pages, this should be reasonably straight-forward to do.
Otherwise, you'll just have to use the less convenient approach of looking in the error logs whenever you need such details.
It’s highly recommended not to show the actual error to users. This applies everywhere, not only in MySQL. You should use a try catch block to handle errors.
In your case, a user or attacker might see your table name, row details, and name. A hacker may use SQL injection or any other attack through your provided error. So it’s better to hide these sensitive details.
It is definitely not a good idea to show details of your database environment to users. The backend of your system should be a total mystery to users. Your server logs should give you enough information to diagnose errors such as the one you have shown.
You should also consider what users can see if they view the source of any page of your web application — does the page source reveal database table or column details in form field names?
If you have time, you could mess with attackers by having fake error messages displayed, which describe database objects that do not exist in your database. Then attackers would be frustrated trying to attack those tables.
