could an attacker who'd just found out that you're using mysql make an SQL Injection attack with only this information? If you don't know Any table/db name how come you can find it out? Is that even possible and how to avoid that? Thanks
In addition to what Philipp said, keep in mind that SQL injection attacks are quite often done without knowing the structure of the DB, but once a vulnerability is exposed, it can be used to determine the structure.
For example, one of the first SQL injection string that was once taught used to be
This makes an assumption that the data user provided was being put in quotes in a SQL query, so the first quote in the string closes it, and the following semi-colon ends the statement, which may result in an error. However, the following statement would still be executed, which would be
-- indicates that the rest are comments. So, this string could shutdown a server immediately if the input was not sanitized.
Taking the same one step forward in many DB systems, such as SQL server, the list of system tables is well-known and if the account which was executing the query had privileges, it could be used to list users, tables, stored procs, views, and other SQL configuration. Once that is listed, they can dropped, exported, and the structure of tables or views could be listed too.
Similarly, queries can be constructed to bypass authentication, for example by a string such as
' or '1'='1' --
A string such as the above would be inserted in a
WHERE clause and no matter what user name or password was provided, this would result in a true evaluation, allowing user to authenticate without providing any credentials. e.g.:
SELECT * FROM USERS WHERE UserName = '' or '1'='1' --
In short, once a SQL injection attack is successful, the attacker has the ability to run code on your server which should be considered the same as if they were sitting on the server itself in terms of threat modelling.
To avoid the attacks, most frameworks and DB systems provide mechanism for parameterized queries. Although you should check for your platform, parameterized queries is usually the most secure way. If you must construct SQL queries yourself (e.g. to pass to some external API that requires it), then consider encoding it properly although I would try to avoid it.
- In some web applications, syntactically incorrect SQL statements result in an error message which might get forwarded to the HTML output the visitor sees. This might give the attacker some information how the query looks. ("You have an error in your SQL query near 'myapp_tbl_users'."). To avoid this, configure your webserver to not output detailed error messages.
- There are cases where SQL injection attacks result in database content printed to the frontend. When they figured out such an attack, they can also use it to output meta-information about the database, like which tables exist in it.
- Never assume that all attackers are external. A secure system should also be secure against internal attackers who know how the application works.
- There could be an unrelated vulnerability in your web application which reveals sourcecode. These are usually not that critical, but when there is also a SQL injection in your app, it could help the attacker to get information about the structure of your database.
- The attacker can just guess. The guessing can be automated (run a script which brute-forces possible table names).
But the best way to avoid any of these problems is to just avoid SQL injections in the first place. There are a lot of better ways to communicate with your SQL database than to concatenate strings. Use stored procedures, prepared statements or an ORM wrapper.
Yes - they can find out the structure of your database using the INFORMATION_SCHEMA.
Many online tutorial, such as this one talk you through the process, from a simple exploit to extracting all the data.
From a defenders point of view, you could deny access to the INFORMATION_SCHEMA tables - I doubt your legitimate application ever uses them. However, in that case, an attacker could brute force table and column names, as Philipp suggests. I have actually never seen a web app that does deny access - it's better to spend your effort preventing SQL injection in the first place.