Author name: Sushma Singh

There are different types of SQL Injection attacks such as Error based, Time based and Boolean based. Each of the types of SQLi has the potential to cause a complete data breach in an organization. In this article, we are going to explore the Time Based SQL Injection attack. This type of SQL Injection utilizes the database time delays function to extract or dump the database. Let’s explore this in detail. The article is divided into below sections – What is Time Based SQL Injection Attack? SQL Delay Query Examples Time Based SQL Injection Payloads Identify if the Application is Vulnerable to Time-Based SQLi Dumping the database using Time Based SQL Injection Find MySQL Schema names using Time Based SQLi Find names of all tables under the schema in MySQL Time Based SQL Injection Prevention Techniques Conclusion What is Time Based SQL Injection Attack? We can define the Time Based SQL Injection Attack as follows – Time Based SQL Injection attack is a type of SQL Injection attack that relies on time delays in SQL query execution to infer information about database schema structure and the database contents. It is a type of inferential injection attack in which the attacker has to infer (guess, enumerate) the database structure to exploit it. Unlike in Error based SQL Injection attacks, here the application does not send any database information back to the attacker in any form. Instead, the attacker uses database time delay functions to dump the data. After executing a query that triggers a time delay on the database server, the attacker monitors the application’s response time to note whether the time delay has happened on the database server or not. If the application responds slowly as per the time delay set by an attacker, then the attacker gets a clue that the application is vulnerable to Time based SQL Injection. Let’s now first see what these SQL delay queries look like.   SQL Delay Query Examples The below tables mention the delay query syntax of different database server vendors. Database Type SQL Delay Query Description MySQL select sleep(5); Takes 5 seconds for execution. do sleep(10); Takes 10 seconds for execution. MS SQL Server wait for delay ’00:00:02’​; Takes 2 seconds for execution. PostgreSQL pg_sleep(4); Adds a sleep time of 4 seconds. For example, if you run the below query in the MySQL server, it will take 5 seconds before the query returns the version number result. select version(), sleep(10); Now, let’s understand how these time delay queries are used in time based SQL Injection payloads. Time Based SQL Injection Payloads Using the time delay queries of various database server vendors, below are some Time-based SQL Injection payloads for MySQL. ,(select * from (select(sleep(10)))a) %2c(select%20*%20from%20(select(sleep(10)))a) ‘;WAITFOR DELAY ‘0:0:30′– This GitHub repo has a comprehensive list of time-based SQL Injection payloads. Identify if the Application is Vulnerable to Time-Based SQLi Now, you can use the above time based payloads to identify if the application is vulnerable or not. For this, find just one vulnerable input parameter of the application using the below steps – Identify all input parameters of all APIs of the application using a tool like BurpSuite. Insert the time delay SQLi payloads mentioned in the above section in each parameter 1 by 1 and observe the application response time. Any parameter that triggers a slow application response, is the vulnerable one. Note: Even if just 1 parameter is vulnerable, that’s enough to dump the entire database using a Time based SQLi vulnerability. Here, we can surely say and report that the application is vulnerable to time-based SQLi. Dumping the database using Time Based SQL Injection To dump the database using a Time-based SQL injection vulnerability, you need to use conditional expressions. Let’s understand how it works under the hood. For MySQL, below is the syntax for a conditional expression. if(condition, when_true, when_false) Now, the logic to dump the data is, we have to make a guess and then conclude that whether our guess is right or wrong. We use our guesses in the ‘condition’ part and put the query delay function in the True part. If you observe a delay in application response, then it means the condition was evaluated to True. Meaning, that our guess used in the condition is correct. Now, here’s the interesting part. We will now enumerate or guess the database details piece by piece i.e. character by character. For example, if we have to guess the database has a table named ‘products’, then we will guess it, character by character i.e. p,r,o,d,u,c,t,s. So, for the first letter ‘p’, we enumerate all characters between ‘a’ to ‘z’. So, we need a total of 26 enumerations just to guess the first letter of a table. Let’s walk through this process with some real examples. Find MySQL Schema names using Time Based SQLi As mentioned before, for dumping data with time-based SQLi, you need to make guesses and try out all the guesses. For example, with the below query, we try to guess the name of 1 schema from the MySQL database. We know schema name can be read from MySQL table information_schema.SCHEMATA from column name ‘SCHEMA_NAME’ using the below query- select SCHEMA_NAME from information_schema.SCHEMATA s limit 1; Now, let’s use the query delay function and conditional expression to get the first letter of the schema name. Refer the below query – select if(substring(SCHEMA_NAME,1,1) = ‘a’, sleep(5), ”) from information_schema.SCHEMATA s limit 1; Here, we checked if the first letter of the schema name is ‘a’ or not. If it is, the query will sleep for 5 seconds. We make all 26 permutations and for 1 character we will see the query execution sleep for 5 seconds. So, this way using time-based SQL Injection, the database can be dumped. Find names of all tables under the schema in MySQL Once you identified the schema name, you can find table names using the below query and make guesses for every character using the sleep function. SELECT table_name FROM information_schema.tables limit 1; Query with sleep function – select if(substring(TABLE_NAME,1,1) = ‘a’, sleep(5), ”) from information_schema.TABLES s limit 1; Time Based SQL Injection Prevention Techniques There is no special

Path Traversal is one of the most prevalent attack techniques against web applications and is also part of the OWASP Top 10 list of web-based attacks. It is also very common and simple to exploit, with consequences ranging from file system access, information disclosure and Remote Code Execution. What is a Path Traversal attack? It is an attack technique that is intended towards accessing file system locations (files, directories) that are outside of the container on which the web application is running in. It can lead to leaking information about the system hosting the web application, such as sensitive files (config files, environment variables, files hidden from the web application etc), information (such as application source code) and even Remote Code Execution. Impact of a Path Traversal attack A Path traversal attack can have serious implications, if exploited: Leak of sensitive files and information on the filesystem Remote-code execution Creation of backdoors into the affected server How does an application become susceptible to a Path Traversal attack? Path Traversal is a consequence of improper input sanitization (at the application level) when dealing with flows that access the filesystem (such as reading of files, images and scripts). Creative constructs of payloads for those parameters can allow for traversing different locations across the filesystem, that are outside the location of the web server root. At its core, Path Traversal payloads involve parameters denoting paths to locations away from the root web application directory. The simplest payload is as below: http:///?file=../ This denotes access to one level above the base web application directory. Different types of Payloads for a Path Traversal attack Regular payloads http:///?file=../ -> Nix environmentshttp:///?file=/etc/passwd -> Absolute pathhttp:///?file=.. -> Windows environments For exploits, variations of the relative and absolute path can be picked up and can work way up the levels to reach to different areas of the filesystem.Another technique can be to fuzz the directory names in a scan to see if they exist or not. Stripped payloads http:///?file=….//….//etc/passwd This is a non-recursive traversal payload that is stripped to ../../etc/passwd Encoded payloads http:///?file=..%2F..%2F..%2Fetc%2Fpasswd%20 The above example has a URL-encoded parameter that translates to ../../../etc/passwd In addition to a single encoding level, multiple encodings can be made for more creative exploits. Payload starting from expected path http:///?file=/var/www/images/../../../etc/passwd In this case, the web application has validation in the input parameter that mandates input file to be present in the /var/www/images directory. The above payload bypasses that validation. Null-byte character These payloads are used to bypass specific file restrictions for input file (such as a requirement for the file being a PNG file). http:///?file=../../../etc/passwd%00.png The null byte at the end is discarded after validation. Basic Vulnerable App Exploit and Impact $file = $_GET[‘file’];include($file); Accessing through the following exploit GET /dirtraversal.php?file=../../../../etc/passwd Similar payloads to get the same result /dirtraversal.php?file=/etc/passwd ..%2F..%2F..%2F..%2Fetc%2Fpasswd /etc/passwd How do you prevent a Path Traversal attack? Path Traversal is a fairly simple thing to solve. At its core involves proper sanitization of user input. Preferably, do not have user input for calls to the filesystem. Check user input -> Should contain only allowed values and input containing traversal characters should be stripped off. Accept the known good input. Canonicalize user input to verify it starts with an expected base directory. A simple way to do accomplish this is to compare actual paths on the file system and determine whether there is a traversal mechanism in place. This can be done by resolving to an actual path on the filesystem and then comparing with the resolution of the actual file path. $base_path = “/opt/homebrew/var/www”;$file_path = $base_path . $file;$real_path = realpath($file_path);if($real_path === false || strpos($real_path, realpath($base_path) !== 0))echo “File not found!”;elseinclude($file_path); The above code ensures that the file path of the parameter exists in the /opt/homebrew/var/www folder, which is not the case if there is path traversal in place, resulting in the following output. Conclusion As shown, Path Traversal is a fairly common attack, being part of the OWASP Top 10 list of attacks. It is mostly caused due to developer ignorance and can cause a whole world of pain if exploited, with sensitive information disclosure and remote code execution being fairly common results of such attacks. It is fairly easy to solve and can be done with checks and balances for user input and ensuring whether filesystem access for user-input is even needed in the first place. If those measures are taken, we will be one step further in securing our web applications. At BUZZ, we have found various applications susceptible to Path Traversal attacks, which can lead to serious implications for the organizations business and reputation, if exploited. Check once or contact BUZZ experts for securing your applications and systems.

If you have detected that an application is vulnerable to SQL Injection vulnerability, then the next step to exploit the vulnerability is to know which type of SQL Injection it is. This will help you craft your SQL injection payloads as per the type. In this article, we are going to look at Error based SQL Injection which is a type of in-band SQL Injection attack. We will also provide a live demo of an error-based SQL Injection attack using Acunetix. So, let’s get started. The article will encompass the below sections. You can jump directly to any section if you want. What is error based SQL Injection? Definition of Error based SQL injection Live example of Error based SQL Injection on Acunetix Error based SQL Injection payloads How to prevent Error based SQL Injection attacks? Validate input parameters properly Use Prepared Statements Conclusion What is error based SQL Injection? An Error based SQL Injection is an in-band type of SQL Injection attack in which attackers use a single channel to fire the SQL Injection payloads and also extract the results from the same channel. An example of an in-band attack is when an attacker hits any REST API request and immediately sees the desired results in the API response. In error based SQL Injection, the attacker relies on error messages returned by the database server. The error messages help provide information about the structure of the schema and where exactly the error has occurred in the SQL query. Let’s look at the formal definition. Definition of Error based SQL injection Error based SQL Injection definition is as follows- “Error based SQL Injection is a type of SQL Injection in which the attacker can see error messages thrown by the database server when any SQL Injection payloads are fired.” The error messages contain sensitive information about the database schema, the vulnerable SQL query, and the database type. The attacker uses error information so as to accurately craft the SQL injection payloads for further penetration into the victim’s database system. It will be clearer to you when you see some live examples of error based SQL Injection in the next section. Live example of Error based SQL Injection on Acunetix Acunetix hosts a vulnerable web application online for testing purposes. It is freely accessible to all. The aim of the application is to demonstrate some of the severe web application vulnerabilities. You can access the Acunetix vulnerable web application here. There are many vulnerabilities in this application. However, we will only demonstrate the Error based SQL Injection. To do this, you need to navigate as below : Click on the Categories menu -> Click on any category displayed -> You will see posters in the category. Now observe the URL in the address bar. It accepts a category ID as an input parameter as highlighted below. http://testphp.vulnweb.com/listproducts.php?cat=1 This parameter is vulnerable to Error-based SQL Injection. Now, to test for SQL Injection on this parameter, just append a single quote (‘) in the URL right after the value of the category ID. The resulting URL may be as below (You can copy and paste in address bar): http://testphp.vulnweb.com/listproducts.php?cat=1′ Now as soon as you hit enter, instead of posters in the category you will see an Error message. Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”’ at line 1 Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in /hj/var/www/listproducts.php on line 74 This error message is thrown by the MySQL database server. This database-side error message is a first clue to an attacker that the entered parameter value is reaching to query as it is entered (along with possibly any junk characters entered). We have highlighted the sensitive information in the above log. It clearly shows the underlying database is of type MySQL and there is an error at line 1. You can now play around with parameter values and try to inject different variants of SQL Injection payloads from the payload list in the next section. Error based SQL Injection payloads Now we know the parameter named ‘cat‘ is vulnerable to Error based SQL Injection, we can now embed various SQLi payloads. Let’s inject the payloads now – SQLi Payload Direct link to hit (Including payload) 1 OR 1=1 Link – Shows posters from all categories 1 AND (SELECT 2839 FROM (SELECT(SLEEP(10)))DtDN) Link – Make database thread to sleep for 10 seconds For a full list of thousands of Error-based SQL Injection payloads, visit this GitHub repository. How to prevent Error based SQL Injection? As with any SQL Injection attack, the attacker tries to exploit the input parameters in the application and injects the SQLi payload into the same. This is also applicable to error based SQL Injection attacks. Below we list down the 2 important prevention techniques. Validate input parameters properly As in the above Acunetix application’s example, the vulnerable parameter is ‘cat‘. It is a numeric field representing the category ID. Hence, on the server side we need to put a validation to check whether provided category ID is really an integer or not. Use PreparedStatements Do not create the SQL query using the string concatenation technique. You need to use PreparedStatements so that the query parameters do not alter the structure of the query being fired. Conclusion Out of all types of SQL Injection attacks, the error based SQL Injection is the most severe. It is severe because of the reduced turnaround time in seeing the results. And hence in a few minutes of time, the attacker will be able to download the entire database of victim applications. BUZZ is an expert player in doing security assessments of SMBs and startups. We have found many instances of Error-based SQL Injection vulnerability in SMB’s internet-facing systems. Remember, a single vulnerable parameter is a doorway for an attacker to download the entire database. The endpoints look safe to the open eyes but upon security assessment, the full database gets exposed. Do your application’s endpoints also look

In almost all cyber-attacks, hackers exploit the security bugs (aka. vulnerability) in the victim’s networks, machines, or software installed. One such particularly severe vulnerability is “SQL Injection”. This vulnerability is of such significance that attackers can dump entire databases of victims. This might lead to the forced closure of the organization. In this article, you will understand what is SQL Injection attack and what causes SQL Injection attacks to happen. We will also explain a few of the basic prevention techniques for SQL Injection attacks. So, let’s get started. This article is divided into below sections. You can jump directly to any section. Definition of SQL Injection attack How does SQL Injection attack work? Demonstration of SQL Injection Prevention of SQL Injection attack Prevention Technique 1: Use PreparedStatement with parameters Prevention Technique 2: Validate input parameters Does SQL injection still work in 2023? Conclusion Definition of SQL Injection attack SQL Injection attack is an injection type of attack in which an attacker injects malicious SQL statements (aka payloads) in the user-provided input fields of the application. These input fields are then used as is to prepare SQL statements that will be executed on the database server. In other words, in an SQL Injection attack, an attacker can execute unauthorized SQL statements on the victim’s database through the application’s input fields. Using this attack, an attacker can get a complete hold of the victim’s database. The database under attack has no way of knowing whether the SQL statement being executed is a normal SQL statement triggered by the application or is a manipulated SQL statement executed as a part of an SQL injection attack by hackers. Let’s now understand how this attack works internally and what are the main causes of the attack. How does an SQL Injection attack work? Now, we will explain how SQL injection attack works with an example that you can relate to your often, daily required action i.e. a Login form. Consider the below example of a “Login Form” SQL Injection attack. As can be seen, the user needs to enter his username and password in order to log in. Below are the contents of the users table containing the username and password to be checked (Although it’s a bad table design where passwords are kept in unencrypted form, let’s keep the table super simple to understand the SQLi attack) Once the user clicks on the “LOG IN” button, an API call to the backend server will be made with a payload containing the entered username & password. We directly look at server-side logic that validates entered credentials with the credentials in the database table. public static void main(String[] args) { String username = “john”; String password = “John@123”; //password = “John@1231′ OR ‘1’=’1”; // SQLi payload input try { int userid = validateCredentialsAndFetchUserId(username, password); System.out.println(“User is found. User Id is :” + userid); } catch (InvalidUserException e) { System.out.println(“Wrong username or password entered. No user found.”); } } private static int validateCredentialsAndFetchUserId(String username, String password) { Connection con = null; Statement st = null; ResultSet resultSet = null; try { Class.forName(“com.mysql.cj.jdbc.Driver”); con = DriverManager.getConnection(“jdbc:mysql://localhost:3306/mydb”, “mydbuser”, “Mydbpassword@123”); st = con.createStatement(); // Below SQL fetches the user with given username and password combination String sql = “select * from users where username='” + username + “‘ and password='” + password + “‘”; System.out.println(“SQL to be fired :”+sql); resultSet = st.executeQuery(sql); if (resultSet.next()) { // We got the results. This means the user with given userid and password exist. // There can be max 1 record with given combination. // Now just return user id of the first result. return resultSet.getInt(“userid”); } else { throw new InvalidUserException(“Invalid user with username :” + username); } In the above code, we are building an SQL query in the below form. select * from users where username=’john’ and password=’John@123′ If this query returns at least 1 result, then it means entered credentials exist in the database and the user is valid. The query is built using the string concatenation technique as below- String sql = “select * from users where username='” + username + “‘ and password='” + password + “‘”; This code snippet is vulnerable to SQL Injection attacks. It is an example of Error based SQL Injection. Here, the user-provided input fields are passed as is to build a database query using the string concatenation technique. An attacker can embed an actual SQL statement in any of the input fields and our code will concatenate the user’s input as is to the final SQL query to be executed on the database server. Let’s understand with some example input test cases. Note, that we have added some debug logs (using system.out). Demonstration of SQL Injection The test case with valid credentials For username=”john” and password=”John@123″, below is the output. SQL to be fired:- select * from users where username=’john’ and password=’John@123′ User is found. User Id is: 100 The test case with “invalid” credentials For username=”john” and password=”John@123456″, below is the output. SQL to be fired:- select * from users where username=’john’ and password=’John@123456′ Wrong username or password entered. No user found. This is working well. As a developer, you will be happy that the program is working well as you have checked both positive and negative test cases. Now, the time is for some impressive part, the hacker’s test case – The hacker’s test case For username=”john” and password=”John@1231′ OR ‘1’=’1″, below is the output. Observe the quotes in the password. They are important so that a valid SQL statement is generated in the backend. SQL to be fired:- select * from users where username=’john’ and password=’John@1231′ OR ‘1’=’1′ User is found. User Id is: 100 As you can see, the hacker has entered the wrong password of the user (but injected the SQL injection payload in the password field) and is able to fetch the user ID (i.e. bypassed authentication). The SQLi payload used in the above test case is John@1231′ OR ‘1’=’1. Prevention of SQL Injection attack As you have