SQL Injection

The SQL Injection is a code penetration technique that might cause loss to our database. It is one of the most practiced web hacking techniques to place malicious code in SQL statements, via webpage input. SQL injection can be used to manipulate the application’s web server by malicious users.

SQL injection generally occurs when we ask a user to input their username/userID. Instead of a name or ID, the user gives us an SQL statement that we will unknowingly run on our database. For Example – we create a SELECT statement by adding a variable “demoUserID” to select a string. The variable will be fetched from user input (getRequestString).

demoUserI = getrequestString("UserId");  

demoSQL = "SELECT * FROM users WHERE UserId =" +demoUserId;

Types of SQL injection attacks

SQL injections can do more harm other than passing the login algorithms. Some of the SQL injection attacks include:

  • Updating, deleting, and inserting the data: An attack can modify the cookies to poison a web application’s database query.
  • It is executing commands on the server that can download and install malicious programs such as Trojans.
  • We are exporting valuable data such as credit card details, email, and passwords to the attacker’s remote server.
  • Getting user login details: It is the simplest form of SQL injection. Web application typically accepts user input through a form, and the front end passes the user input to the back end database for processing.

Example of SQL Injection

We have an application based on employee records. Any employee can view only their own records by entering a unique and private employee ID. We have a field like an Employee ID. And the employee enters the following in the input field:

236893238 or 1=1

It will translate to:

SELECT * from EMPLOYEE where EMPLOYEE_ID == 236893238 or 1=1  

The SQL code above is valid and will return EMPLOYEE_ID row from the EMPLOYEE table. The 1=1 will return all records for which this holds true. All the employee data is compromised; now, the malicious user can also similarly delete the employee records.

Example:

SELECT * from Employee where (Username == "" or 1=1) AND (Password="" or 1=1).  

Now the malicious user can use the ‘=’ operator sensibly to retrieve private and secure user information. So instead of the query mentioned above, the following query, when exhausted, retrieve protected data, not intended to be shown to users.

SELECT * from EMPLOYEE where (Employee_name =" " or 1=1) AND (Password=" " or 1=1)  

SQL injection based on Batched SQL statements

Several databases support batched SQL statements. It is a group of two or more SQL statements separated by semicolons.

The SQL statement given below will return all rows from the Employee table, then delete the Employee_Add table.

SELECT * From Employee; DROP Table Employee_Add  

How to detect SQL Injection attacks

Creating a SQL Injection attack is not difficult, but even the best and good-intentioned developers make mistakes. The detection of SQL Injection is, therefore, an essential component of creating the risk of an SQL injection attack. Web Application Firewall can detect and block basic SQL injection attacks, but we should depend on it as the sole preventive measure.

Intrusion Detection System (IDS) is both network-based and host-based. It can be tuned to detect SQL injection attacks. Network-based IDSec can monitor all connections to our database server, and flags suspicious activities. The host-based IDS can monitor web server logs and alert when something strange happens.

Impact of SQL Injection

The intruder can retrieve all the user-data present in the database, such as user details, credit card information, and social security numbers, and can also gain access to protected areas like the administrator portal. It is also possible to delete the user data from the tables. These days all the online shopping applications, bank transactions use back-end database servers. If the intruder can exploit SQL injection, the entire server is compromised.

How to prevent SQL Injection attack

  • We should use user authentication to validate input from the user by pre-defining length, input type, and the input field.
  • Restricting the access privileges of users and defining the amount of data any outsider can access from the database. Generally, the user cannot be granted permission to access everything in the database.
  • We should not use system administrator accounts.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *