In this way, the attacker not only bypasses authentication but also gains administrator privileges. The technique is called union -based SQL Injection.
The following is an example of this technique. It uses the web page testphp. The artist parameter is vulnerable to SQL Injection. The following payload modifies the query to look for an inexistent record.
It sets the value in the URL query string to Of course, it could be any other value that does not exist in the database. However, a negative value is a good guess because an identifier in a database is rarely a negative number.
The result of the injected query will be joined with the result of the original query. This allows the attacker to obtain column values from other tables. The following example shows how an SQL Injection payload could be used to obtain more meaningful data from this intentionally vulnerable site:.
The only sure way to prevent SQL Injection attacks is input validation and parametrized queries including prepared statements. The application code should never use the input directly. The developer must sanitize all input, not only web form inputs such as login forms.
They must remove potential malicious code elements such as single quotes. It is also a good idea to turn off the visibility of database errors on your production sites. Database errors can be used with SQL Injection to gain information about your database. If you discover an SQL Injection vulnerability, for example using an Acunetix scan, you may be unable to fix it immediately.
For example, the vulnerability may be in open source code. In such cases, you can use a web application firewall to sanitize your input temporarily. To find out how to do it in many other different programming languages, refer to the Bobby Tables guide to preventing SQL Injection. Preventing SQL Injection vulnerabilities is not easy. Here is how a web application normally works.
A user first enters their login credentials into the login form. Now, when a SQL injection vulnerability exists, an unauthorized threat actor could somehow skip the authentication process and manually inject SQL statements to send fraudulent queries to the database. This would allow the attacker to view, modify, and delete data from the database. SQL injection is not only highly common, but also very dangerous as it can lead to unauthorized access to personal data, financial information, intellectual property, and trade secrets.
It has been listed as the number one risk on the OWASP top 10 list of web application security threats. A large number of data breaches were the result of SQL injection attacks. Think of a dynamic SQL statement like a multivariate function in mathematics, of which the parameters are fixed, while the values substituted in the independent variables determine the result.
An attacker who reads unauthorized information alone can give you a lot of headaches. The attacker could access and expose sensitive data like financial data and personal information. Most applications allow their users to input data somehow, and web applications are no different. Malicious individuals can abuse those data entering mechanisms in ways that interfere with the generation of SQL queries.
Most of the time, these would be form fields and URL parameters. By tinkering with those elements in just the right way, attackers can inject—hence the name—additional SQL commands, which get executed.
Imagine a real estate agency website. After selecting your search parameters and clicking on the Search button, the selected parameters get added as URL parameters. Your URL would look something like this:. The query above is pretty straightforward. We want to retrieve the rows from the properties table in which the value of the category column is equal to Apartments. Since one always equals one, the query above successfully asks the database for properties from all categories.
The most important aspect of blocking SQL injections can be summed up in a single sentence: Always assume user input to be insecure. Also, any type of data provided by the user, such as form fields, URL parameters, or user-provided files should be automatically distrusted. Data from APIs your app consumes also go on that list. These examples are far from exhaustive, but the same rule applies: Consider user input unsafe by default.
Verify it first, and only when you deem it safe should you proceed. The key thing here is that the double-dash sequence -- is a comment indicator in SQL, and means that the rest of the query is interpreted as a comment. This means that all products are displayed, including unreleased products. Going further, an attacker can cause the application to display all the products in any category, including categories that they don't know about:.
The modified query will return all items where either the category is Gifts, or 1 is equal to 1. Consider an application that lets users log in with a username and password.
If a user submits the username wiener and the password bluecheese , the application checks the credentials by performing the following SQL query:. If the query returns the details of a user, then the login is successful. Otherwise, it is rejected. Here, an attacker can log in as any user without a password simply by using the SQL comment sequence -- to remove the password check from the WHERE clause of the query.
For example, submitting the username administrator'-- and a blank password results in the following query:. This query returns the user whose username is administrator and successfully logs the attacker in as that user.
In cases where the results of an SQL query are returned within the application's responses, an attacker can leverage an SQL injection vulnerability to retrieve data from other tables within the database. For example, if an application executes the following query containing the user input "Gifts":.
This will cause the application to return all usernames and passwords along with the names and descriptions of products. Following initial identification of an SQL injection vulnerability, it is generally useful to obtain some information about the database itself. This information can often pave the way for further exploitation.
You can query the version details for the database. The way that this is done depends on the database type, so you can infer the database type from whichever technique works.
0コメント