Sqli Exploit

[Waneta]

If you're familiar with the basic concepts behind SQLi vulnerabilities and want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access labs in this topic from the link below.

In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure. It can also enable them to perform denial-of-service attacks.

SQL injection attacks have been used in many high-profile data breaches over the years. These have caused reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise that can go unnoticed for an extended period.

Crucially, note that -- is a comment indicator in SQL. This means that the rest of the query is interpreted as a comment, effectively removing it. In this example, this means the query no longer includes AND released = 1. As a result, all products are displayed, including those that are not yet released.

Take care when injecting the condition OR 1=1 into a SQL query. Even if it appears to be harmless in the context you're injecting into, it's common for applications to use data from a single request in multiple different queries. If your condition reaches an UPDATE or DELETE statement, for example, it can result in an accidental loss of data.

Imagine 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:

In this case, an attacker can log in as any user without the need for a password. They can do this 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:

In cases where the application responds with the results of a SQL query, an attacker can use a SQL injection vulnerability to retrieve data from other tables within the database. You can use the UNION keyword to execute an additional SELECT query and append the results to the original query.

Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.

Second-order SQL injection occurs when the application takes user input from an HTTP request and stores it for future use. This is usually done by placing the input into a database, but no vulnerability occurs at the point where the data is stored. Later, when handling a different HTTP request, the application retrieves the stored data and incorporates it into a SQL query in an unsafe way. For this reason, second-order SQL injection is also known as stored SQL injection.

Second-order SQL injection often occurs in situations where developers are aware of SQL injection vulnerabilities, and so safely handle the initial placement of the input into the database. When the data is later processed, it is deemed to be safe, since it was previously placed into the database safely. At this point, the data is handled in an unsafe way, because the developer wrongly deems it to be trusted.

Some core features of the SQL language are implemented in the same way across popular database platforms, and so many ways of detecting and exploiting SQL injection vulnerabilities work identically on different types of database.

You can query the version details for the database. Different methods work for different database types. This means that if you find a particular method that works, you can infer the database type. For example, on Oracle you can execute:

In the previous labs, you used the query string to inject your malicious SQL payload. However, you can perform SQL injection attacks using any controllable input that is processed as a SQL query by the application. For example, some websites take input in JSON or XML format and use this to query the database.

These different formats may provide different ways for you to obfuscate attacks that are otherwise blocked due to WAFs and other defense mechanisms. Weak implementations often look for common SQL injection keywords within the request, so you may be able to bypass these filters by encoding or escaping characters in the prohibited keywords. For example, the following XML-based SQL injection uses an XML escape sequence to encode the S character in SELECT:

For a parameterized query to be effective in preventing SQL injection, the string that is used in the query must always be a hard-coded constant. It must never contain any variable data from any origin. Do not be tempted to decide case-by-case whether an item of data is trusted, and continue using string concatenation within the query for cases that are considered safe. It's easy to make mistakes about the possible origin of data, or for changes in other code to taint trusted data.

SQL Injection has become a commonissue with database-driven web sites. The flaw is easily detected, andeasily exploited, and as such, any site or software package with even aminimal user base is likely to be subject to an attempted attack of thiskind.

Essentially, the attack is accomplished by placing a meta character intodata input to then place SQL commands in the control plane, which didnot exist there before. This flaw depends on the fact that SQL makes noreal distinction between the control and data planes.

The following C# code dynamically constructs and executes a SQL querythat searches for items matching a specified name. The query restrictsthe items displayed to those where owner matches the user name of thecurrently-authenticated user.

However, because the query is constructed dynamically by concatenating aconstant base query string and a user input string, the query onlybehaves correctly if itemName does not contain a single-quote character.If an attacker with the user name wiley enters the string "name' OR'a'='a" for itemName, then the query becomes the following:

This simplification of the query allows the attacker to bypass therequirement that the query only return items owned by the authenticateduser; the query now returns all entries stored in the items table,regardless of their specified owner.

This example examines the effects of a different malicious value passedto the query constructed and executed in Example 1. If an attacker withthe user name hacker enters the string "name'); DELETE FROM items; --"for itemName, then the query becomes the following two queries:

Many database servers, including Microsoft SQL Server 2000, allowmultiple SQL statements separated by semicolons to be executed at once.While this attack string results in an error in Oracle and otherdatabase servers that do not allow the batch-execution of statementsseparated by semicolons, in databases that do allow batch execution,this type of attack allows the attacker to execute arbitrary commandsagainst the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated asa comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In adatabase where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar tothe one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT \* FROM items WHERE 'a'='a", the followingthree valid statements will be created:

One traditional approach to preventing SQL injection attacks is tohandle them as an input validation problem and either accept onlycharacters from an allow list of safe values or identify and escape adeny list of potentially malicious values. An allow list can be a veryeffective means of enforcing strict input validation rules, butparameterized SQL statements require less maintenance and can offer moreguarantees with respect to security. As is almost always the case,deny listing is riddled with loopholes that make it ineffective atpreventing SQL injection attacks. For example, attackers can:

Another solution commonly proposed for dealing with SQL injectionattacks is to use stored procedures. Although stored procedures preventsome types of SQL injection attacks, they fail to protect against manyothers. For example, the following PL/SQL procedure is vulnerable to thesame SQL injection attack shown in the first example.

Stored procedures typically help prevent SQL injection attacks bylimiting the types of statements that can be passed to their parameters.However, there are many ways around the limitations and many interestingstatements that can still be passed to stored procedures. Again, storedprocedures can prevent some exploits, but they will not make yourapplication secure against SQL injection attacks.

In this series, we will be showing step-by-step examples of common attacks. We will start off with a basic SQL Injection attack directed at a web application and leading to privilege escalation to OS root.

For the purposes of this demonstration, we have performed a security audit on a sample web application. During our penetration test, we have identified a plugin endpoint that accepts the user ID via a $_GET request and displays their user name.

The endpoint is directly accessible, which could indicate weak security. The first thing someone would do is to manipulate the entry point (user input: $_GET parameter) and observe the response. What we are looking for is to see if our input causes the output of the application to change in any way. Ideally, we want to see an SQL error which could indicate that our input is parsed as part of a query.

There are many ways to identify whether an application is vulnerable to SQL injection. One of the most common and simple ones is the use of a single quote which under certain circumstances breaks the database query:

c80f0f1006