Exploiting SQL injection with no space

https://gupta-bless.medium.com/exploiting-sql-injection-with-no-space-query-4840362d1674

SQL Injection: A SQLI attack consists of an injection in SQL query via user supplied input to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute operations on the database.

SQLi occurs when an application uses invalidated user input to dynamically construct SQL query.

Example: We want to retrieving data from a library application that publishes articles.

1) The application executes SQL query which returns public articles. The URL looks like this https://blog.test.com/articles.php?status=public. Which executes this query

SELECT * FROM library WHERE category = ‘articles’ AND status = ‘public’.

2) Attacker tries to retrieve all articles (public and confidential) so he modify above

Sql query simply by using an OR statement such as articles’ or 1=1 — ‘.

SELECT * FROM library WHERE category = ‘articles’ OR 1=1 — ’ and status =’public’

3) Since 1=1 is a true statement, all articles (public and confidential) are retrieved.

Types:

● In-band SQLI /Classic: The malicious user uses the same communication channel to launch the attack and gather results.

Error-based: This technique relies on the error thrown by the database server to obtain information about the structure of the database.

Union-based: This technique relies on UNION SQL operator to combine multiple SELECT statements to get a single result, returned as part of the HTTP response.

● Inferential /Blind: In this technique, an attacker sends data payloads to the server and observes the response and behavior of the server to learn more about its structure.

Boolean: Attacker sends a SQL query to the database and the result varies depending on whether the query is true or false. Based on the result, the information within the HTTP response will modify or stay unchanged. Based on the response, the attacker can infer if it’s a true or a false result.

Time-based: The attacker sends a SQL query to the database, which makes the database wait (in seconds) before it can react. This time delay helps the attacker in identifying whether a query is true or false.

Exploitation: Our aim is to retrieve all the contents of the database.

· Upon opening the URL we can see this page.

· So to check SQL injection I gave basic payload i.e ‘ it all the data got removed from the page.

· So I tried with this simple payload ‘ or ‘1’=’1 and it was giving a strange “ERROR NO SPACE” error:

· So I thought why not use sqlmap for the sqlinjection in this application. So I fired Up sqlmap with the basic command.

· But as you can see in above image sqlmap was not able to inject the name parameter and was giving a simple advices to use –tamper=space2comment in sqlmap query. Now the problem is that if the application detects any space in the parameter it throws out an error so we have to use our injection payload with the space or with some special characters instead of spaces. So we will look for some tamper payloads in the SQLmap. To do so type this command in the terminal.

Note: Tamper scripts used to evade filters and WAF’s.

Syntax: sqlmap –list-tamper

· After running above command, we got so many options but we took space2comment as per our requirement. Because “space2comment” remove spaces from the injection payload and we can achieve SQLi through it.

Function: Space = = > /**/

Example: SELECT * from users = = > SELECT/**/id/**/From/**/users

Syntax: Sqlmap –u “192.168.1.11/sqli/example3.php?name=root” –tamper=space2comment — current-db

After running the above command, you can see that SQLmap was able to inject the payload and was able to retrieve the database name successfully which means that we can actually do the injection with the above tamper script.

Preventive measures /Mitigation

● Prepared statements — Parameterized queries forces to first define all the SQL codes and then pass in each parameter to the query later.

● Use stored procedures: SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Ensure that the stored procedure does not include any unsafe dynamic SQL generation.

● Filter and sanitize input: This technique is to escape user input before putting it in a query.

● Limit database permissions and privileges: To minimize the damage from a SQL injection attack follow the principle of least privilege when assigning privileges to any database account.