In this post, I would like to introduce you to examples of SQL Injection and ways to prevent SQL Injection attacks when testing Web.
While testing a website or a system, the purpose of Tester is to make sure the product is protected as much as possible.
Security testing is usually done for this purpose. To perform this type of testing, we first need to consider which attacks are most likely to occur. And SQL Injection is one of those types of attacks.
SQL Injection is one of the most common types of attacks when it can be dangerous and harm your system as well as sensitive data.
What is SQL Injection?
Some users pass SQL statements that are executed on the database. It makes the application unable to handle user provided data incorrectly.
In this case, a malicious user could provide unwanted input to the application, then frame and execute the SQL statement on the database. It is called SQL Injection . The consequences of such an action may be alarming.
As the name implies, the purpose of an SQL Injection attack is to inject malicious SQL code.
Each field of the website is a portal to a database. In the login form, the user enters the login data. In the search field, the user enters search words. In the data saving form, the user enters the data that can be stored. All specified data can lead to the database.
Instead of entering the right data, any malicious code entered can lead to serious database and system damage.
SQL Injection is done with the SQL programming language. SQL (Structured Query Language) is used to manage the data organized in the database. Therefore this programming language code is being used as a malicious injection.
This is one of the common attacks, because the database is used for almost all technologies.
Many applications use some kind of database. An application under test may have a user interface that accepts user input to perform the following tasks:
- Display stored data related to the user. For example, the application checks the user’s login credentials using login credentials entered by the user and displays only user-related functions and data.
- Stores the data entered by the user into the database. For example: Every time the user enters data into the form and submits it, the processing application stores the data in the database. This data will then be provided to the user during the same or subsequent sessions.
Risks of SQL Injection
Today, databases are used for almost all systems and websites, because data should be stored in many places.
When sensitive data is stored in a database, there are more risks in system security. If any personal website or blog data is stolen, it won’t cause as much damage as stolen bank data.
The main purpose of this attack is to hack the system’s database, so its consequences are really harmful.
The following may be the result of SQL Injection:
- Hack someone else’s account
- Steals and copies sensitive system data
- Change the sensitive data of the system
- Delete sensitive system data
- Hackers can login to applications like other users, even admins
- Hackers can view personal information of other users. For example: profile details, transaction details, …
- Hackers can change application configuration information and data of other users
- Hackers can edit database structure, even delete tables in the database
- Hackers can control server database and execute commands on it.
The risks listed above can be really dangerous, because restoring a database or its data costs a lot of money. It can take your company’s reputation and money to recover lost data and systems. Therefore, care must be taken to protect your system from attacks, and Security testing is a good solution for your company’s and your company’s reputation.
As a tester, I would like to comment that testing against attacks may be the best method even though Security Testing is not planned. This way, you can protect and test your product against unexpected situations and malicious users.
The nature of this attack
As mentioned above, the nature of this attack is malicious database hacking.
To perform Security Testing, you first need to find system vulnerabilities and then through them send malicious SQL code to the database. If feasible, these malicious SQL code will be sent and malicious actions will be able to be performed in the database.
Each field of a website is similar to a gateway to the database. Any data or input we normally enter in any system or website field goes to the database. Therefore, instead of entering the correct data, if we enter any malicious code, it can execute a database query and has serious consequences.
Recommended tool
### 1. Kiuwan
Easily find and fix vulnerabilities such as SQL Injection in your code at each stage of SDLC (Software Development Life Cycle – Software Development Life Cycle). Kiuwan complies with the most stringent security standards, including OWASP, CWE, SANS 25, HIPPA, etc.
Integrating Kiuwan into the IDE for instant feedback during development. Kiuwan supports all major programming languages and integrates with leading DevOps tools.
To perform this attack, we must change the action and purpose of the appropriate database queries. One of the possible methods is to make the queries always correct, and then insert the malicious code. Changing the database query to always true can be done with a simple code like [‘or 1 = 1; -].
The tester should keep in mind that checking whether changing the query to true can always be done or not, different quotes should be tried with single and double. Therefore, if we try the single code [‘or 1 = 1; -], then we should also try the double code [“or 1 = 1; -].
Example : Consider the following query together
select from notes nt where nt.subject = ‘searchword’;
Instead of the search term, we enter the SQL Injection query [‘or 1 = 1; -], then the query becomes always true.
select from notes nt where nt.subject = ” or 1 = 1; –
In this case, the “subject” parameter is closed with the citation and then we have code [or 1 = 1], which will not be implemented. This is one of the most common and easiest ways to start query control.
Some other code that can be used to make the query always true, is as follows:
- ‘or’ abc ‘=’ abc ‘; –
- ‘or’ ‘=’ ‘; –
The most important part here is that we can then enter any malicious code we wish to execute.
For example :
If this injection is possible, then we can write any malicious code. In this case, it will only depend on the knowledge and will of the malicious user. How to check SQL Injection?
Testing for this vulnerability can be done very easily. Sometimes just typing [‘or “] into the test field. If it returns any undesirable or abnormal messages, we can be sure that SQL Injection can perform with that field.
For example , if the “Internal Server Error” message is displayed as a search result, we can be sure that an attack is made on this part of the system.
Some other results indicate that it is possible to execute an SQL Injection attack:
- Show blank page
- No error or success message – function and page do not respond to input
- Success message for malicious code
Let’s look at how it works.
For example : Let’s test if the login window is a flaw of SQL Injection.
To accomplish this purpose, in the email and password fields, enter the following:
If the result is an ‘Internal Server Error’ error message or any other inconsistent results listed, we can be sure that it is possible to attack that field.
Therefore, checking SQL Injection with single quotes ” is a fairly reliable way to check if an attack can be performed.
If the single quote doesn’t return an inappropriate result, we can try entering a double quote and checking the results
In addition, the SQL code to change the query to always true is also a way to check whether an attack is possible or not. It closes the parameter and changes the query to “true”. Therefore if unauthenticated, each such input may also return any similar unexpected results, and an attack is possible in this case.
Checking of SQL attacks can also be done from the website link. Suppose we have the link: http://www.testing.com/books=1 . In this case, “books” are parameters and “1” is the value. If we replace [1] with [‘] then we can check whether injection is possible or not.
Therefore, the link http://www.testing.com/books= will be checked to see if an SQL attack is possible for the website http://www.testing.com.
In this case, if http://www.testing.com/books= returns an error message like ‘Internal Server Error’ or a blank page, or any other unexpected error message, then we can be sure that SQL Injection is possible. After that, we can try sending more complex SQL code through this website link.
To check if an attack is possible via a website link, code like [‘or 1 = 1; -] can be used.
As an experienced tester, I would like to remind that not only unexpected error messages can be considered SQL Injection vulnerabilities. Many testers check for possible attacks only on error messages.
However, it should be kept in mind that no authentication error message or success message for malicious code can also be an indication, that this attack is possible.
Security Testing Web Application against SQL Injection
Security Testing a web application is explained with the following simple example:
As the consequences of enabling this vulnerability technique can be serious, this attack should be carried out during the application’s security test. Now with an overview of this technique, let’s understand a few practical examples of SQL Injection.
Important note: SQL Injection Test is performed only in test environment
If the application has a login page, it is possible that the application is using the dynamic SQL statement as shown below. This statement is expected to return at least one single row with the user details from the Users table when there are rows containing the username and password entered in the SQL statement.
SELECT * FROM Users WHERE UserName = ‘”& strUserName &”‘ AND Password = ‘”& strPassword &”‘; “
If the tester wants to enter “John” as strUsername (in textbox username) and “Smith” is strPassword (in textbox Password), the above command will become:
SELECT FROM Users WHERE UserName = ‘John’ AND Password = ‘Smith’;
If the tester wants to enter “John” as strUsername (in the textbox username) and does not have strPassword, the above command will become:
SELECT FROM Users WHERE UserName = ‘John’ – AND Password = ‘Smith’ ;
Note that part of the SQL statement after John translates into a comment. If there is any user whose username is John in the Users table, the application may allow the tester to log in as the user John. The tester can see John’s details.
What if the tester doesn’t know the name of any user in the application? In this case, the tester can try with generic usernames like admin, administrator, and sysadmin. If no user exists in the database, the tester can enter [John ‘or’ x ‘=’ x] as strUsername and [Smith ‘or’ x ‘=’ x] as strPassword. The SQL statement will become as follows:
SELECT FROM Users WHERE UserName = ‘John’ or ‘x’ = ‘x’ AND Password = ‘Smith’ or ‘x’ = ‘x’;
Because the condition ‘x’ = ‘x’ is always true, the result will return all rows of the Users table. From there, the tester can log in as the first user in the Users table.
Important : The tester needs to ask the database administrator or developer to copy the table in question before attempting the following attacks.
If the tester enters [John ‘; DROP table users_details; ‘-] like strUsername and whatever does strPassword, the SQL statement will become as follows:
SELECT FROM Users WHERE UserName = ‘John’; DROP table usersdetails; ‘ – ‘AND Password =’ Smith ‘;
This statement may cause the “users_details” table to be permanently deleted from the database.
The above examples use SQL Injection technique only for login page, tester should use this test technique for all other pages of the application such as search, feedback, …
SQL injection can be used with applications that use SSL. Even firewalls may not be able to protect the application against this technique.
I want to remind you once again that this attack technique is only tested in a test environment, not in development, production or any other environment.
The vulnerable parts when executing this attack
Before performing the test procedure, each tester should more or less know which parts are most vulnerable to this attack.
It is also a good way to plan which test system fields are correct and in what order. I have learned that it is not advisable to randomly test some fields against SQL attacks because some fields may be missed. Because the attack is done in the database, all parts of the input system, input fields, and website paths can be hacked.
The vulnerable parts include:
- Login fields
- The search field
- The comment field
- Any other input and storage fields
- Website link
It is important to remember that while testing against this attack, it is not possible to check only one or several schools. Typically, some schools are protected from SQL injection attacks, but others are not. Therefore, do not forget to test the entire field of the website.
Automated test of SQL Injection
Because some systems or websites tested are complex and contain sensitive data, manual testing can be difficult and time consuming. Therefore, testing to prevent SQL Injection attacks with special tools can be really helpful.
One of the SQL Injection tools is the SOAP UI. If you run an automatic regression test at the API level, you can also use this tool to combat SQL attacks. In the SOAP UI tool, there are templates that can be used to test against this attack. Those templates can also be added with your code.
This is a pretty reliable tool.
However, automated testing at the API level is not easy. Therefore, another way is to use different browser plugins to test automatically.
It should be noted that automated tools can save time, but not always reliably. If you are testing a banking system or a website with sensitive data, it is best to use the manual test. Where you can view accurate results and analyze them. Also, in this case, we can be sure that nothing is missed.
Compare with other attacks
SQL injection can be considered as one of the most dangerous attacks, because it affects the database and can seriously destroy your data as well as your entire system.
To make sure it has more serious consequences than Javascript Injection or HTML Injection, let’s do it all on the client-side. For comparison, with this attack, you have access to the entire database.
To test against this attack, you must have fairly good knowledge of the SQL programming language. And generally, you need to know how database queries work. Also, while executing this attack, you need to be more careful and watchful, as any inaccuracies can be left as SQL holes.
Reference: https://www.softwaretestinghelp.com/sql-injection-how-to-test-application-for-sql-injection-attacks/