Looking into the world of security there are many attack vectors with respect to validations of the input in the wild. It is more prominent in the world of Web Applications but with respect to the infrastructure each and every thing which accepts an input is surrounded by a large bag of variety of Attack Vectors. Some of which are KNOWN to us and some of which are UNKNOWN.
To avoid of what are known to us is do a proper input validation. Seldom developers are able to cover all the aspects of input validation which leave the application more vulnerable. Out of all those vulnerabilities the article extends a little to talk about a famous Vulnerability “CSRF” and the attack vectors in concern with it .Once we are clear about CSRF attack and the attack vectors we will check on how to find the flaw in a web application while testing with the help of tool in handy from OWASP known as CSRF Tester.
When I first heard this term I thought it is very similar to the Initialization vector of Cryptography but on further reading, it made me clearer on what is actually an Attack Vector.
To understand it let us put it in this way that Attack vector is something which assists in exploiting vulnerability with the help of a Payload.
While surfing I came across a very nice definition of it given by the folks of Search Security as under.
“An attack vector is a path or means by which a hacker (or cracker) can gain access to a computer or network server in order to deliver a payload or malicious outcome. Attack vectors enable hackers to exploit system vulnerabilities, including the human element.” 
The thing that was the most important in this definition that attracted me was the mention of Human element which involves the use of Social Engineering and utilizing the people involved in the Defense system of any Organization to break into them which is easier than breaking into the networks of the target.
There has always been a problem in differentiating between the attack vector and the payload. So if the attack vector is the Web pages with malicious content, chat rooms, malicious e-mail attachments, etc. then the payload can be treated as the viruses and executable.
With the advent of Web 2.0, the attack vector also increased dramatically thereby increasing their range of attacks as well. On being the savior of the world the solution also has to evolve with the evolvement of Attack Vectors as the defenses effective today may be outdated tomorrow.
OWASP has a very beautiful diagram which very nicely depicts the different paths that can be available to the attacker for exploiting the web application and how the Attack vector can be the starting point of the overall loss of the Business and the impact on the reputation on the Organizations worldwide.
Fig 1: Paths to exploit 
The weakness of a Web Applications in security arises due to failure in validation of input.
An application is said to be robust against all forms of Attacks which are input based (where a user is required) if the data is properly validated irrespective of the data flow from any source say it is from the end user, infrastructure, external entities or databases.
Validation is not just input based but on many various lines like the integrity of the data thereby ensuring that the data before and after the validation are same. These kinds of checks are usually advised to be implemented whenever the data passes from a trusted to a less trusted boundary, such as from the application to the user’s browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return. The extent of check is dependent on the criticality of the data.
The other validation of data is where the data is checked for strongly typed, correct syntax, within length boundaries, contains only permitted characters, or that numbers are correctly signed and within range boundaries.
These kinds of validations should be performed on every tier. However, validation should be performed as per the function of the server executing the code. For example, the web / presentation tier should validate for web related issues, persistence layers should validate for persistence issues such as SQL injection, directory lookups should check for LDAP injection, and so on.
Apart from all validation all the Business requirement should be implemented as per the business rule with proper validations. For example, the rates after discount % are calculated as per the permitted boundaries. Business rules are known during design, and they influence implementation. The developer should ensure not to skip any of the validations in terms of the design.
Another strategy which is there is “Accepting what is Good” also known as “whitelist” or “positive” validation. The concept is to check that the data which is accepted is what is required and not a tampered one. Any data that doesn’t match should be rejected. For this the developer should ensure that the input data is:
- Strongly typed at all times
- Length checked and fields length minimized
- Range checked if a numeric
- Unsigned unless required to be signed
- Syntax or grammar should be checked prior to first use or inspection
CSRF-Cross Site Request Forgery
CSRF-Cross Site Request Forgery is a serious Vulnerability which was very dominant in the web application but with the education of the user and developer it has considerably reduced but still is prevalent in many web applications in the production environment. OWASP categorized CSRF in its TOP 10 on the number 5 which moved to number 8 this year. Usually this is a difficult vulnerability to be found because of its nature. It is a tedious process for the security tester to grab this flaw. So let’s try to make it simpler to understand the flaw first and then try to find it in a Web Application.
CSRF takes advantage of web application which allows malicious user to predict the way application has been constructed or the application behavior. For the CSRF attack to be successful, the user should be logged i.e. authenticated onto that application with an active and a valid session.
Here comes the twist now. The attacker now forces the logged on user (i.e. the browser) to send a request of his choice and action on the susceptible application; the server processes the request without validating the source of the request. Forcing here may be tricking the user by sending an email or chat or making him click on some image tags etc. which can be done using Social Engineering.
Again I would like to mention of the OWASP testing guide who gives an overview of the Vulnerability and the risk involved with mention to the possible attack vector and the impact.
Fig 2: CSRF – Showing the attack and the Business impact
Let’s us understand on how this attack works in detail. For that we have to understand on how is the normal behavior.
Now in a normal scenario in an HTTP based authentication the browser automatically sends all the information which is required to identify the session of the user. Once the end user has authenticated himself to the website, the server sends back a session cookie which is used to identify the requests sent by the user who is already authenticated to the website. So once the browser receives that cookie it automatically sends the cookie along with each request which is being generated by the client. It avoids the process of authenticating the end user multiple times.
Fig 3: Browser Server Communication and sending of the Session ID’s
Let’s us consider a website named www.target.com which we will plan to target. Once the end user authenticates to this web application it gets redirected to www.target.com/user.html which has a form which has to be submitted by the end user and the data goes to action.html thereby making the URL as www.target.com/action.html where the data is used by action.html to perform some function say updating the profile or database or changing the theme for example. Now in the attack scenario we have to perform the attack in such a way that the attacker fills the data in home.html according to his will and then submits it action.html without the end user getting to know about this.
Fig 4: Demonstration of a simple CSRF Attack
This can be achieved in a number of ways:
Embedding a resource to and Image tag such as
<img src=”http://target.com/action.html?field1=foo&field2=bar” width=”1” height=”1”>
Creating a form in HTML such as
Here is an example using an HTML form on the attacker’s site, say http://evil.com/CSRF_attack.html:
<form action=”http://target.com/action.html” method=”POST”>
<input name=”field1” value=”foo”>
<input name=”field2” value=”bar”>
The attacker would inject the following into the CSRF site:
<iframe width=”0” height=”0” style=”visibility: hidden;”src=”http://evil.com/CSRF_attack.html”>
A very good plus point for the attacker is to find a web site with a cross-site scripting (Which is really an easy task….evil laugh) and the same can be used to launch the CSRF attack thereby removing the headache of hosting an attack page.
This is rather the simplest way to attract the users to be victim of the CSRF attack. Here the attacker has to lure the user to visit his/her website and make them click on the malicious link or sending out emails with links showing luring offers and making them click on it to grab there session and perform the CSRF attack.
TESTING For CSRF
Yes now this is an interesting part. The CSRF attack is used fraudulently to perform actions on the web application which means that all those pages where there is an action to be performed are the ones we have to test for the CSRF vulnerability. It can be updating the details, transfer of fund, changing of password etc.
We can test the application by ensuring that whether the application’s session management relies on only client side values such as cookies, http credentials etc. We can include some kind of random tokens which are generated with the requests through which the server can identify the authenticity of the client. Session related information passed in URL in and unpredictable format or not can also be checked.
For testing purpose we use the open source tool like CSRF Tester form OWASP which is a wonderful tool to find the vulnerable points of CSRF in any web application. There are many other tools also available to test this vulnerability but you have to decide your weapon and mine is CSRF Tester. It is a simple tool with an understandable UI to use and gives very good results.
Fig 5: A look and feel of OWASP CSRF Tester
The Following steps are followed to find vulnerability in CSRF Tester.
- Configure the application over the same listening port such that the flow that we are going to test is recorded onto CSRF Tester
This can be done by configuring the proxy on the default port of CSRF Tester which is 8008.Once configured it starts listening to the port which can be seen.
Once we are on the action page we click on “Start Recording”.
Fig 6: Important Buttons to be noticed
- Login to the application with valid credentials so that a valid session is created and go through the flow of actions that is subjected to be tested.
- CSRF Tester automatically records the sequence of actions. Click on “Stop Recording” once the actions are successfully captured.
Fig 7: Capturing the Actions from the web application
- On Completion click on “Generate HTML” which generates an HTML page with the source code involving the sequences.
Fig 8: Saved in an HTML format
- Open the HTML page using Notepad/any editor on desktop and modify the values you want to tamper.
Fig 9: Editing the Source Code with the help of an Editor
- Open the HTML page in the browser. (Note: A valid user session should be established)
- If the application goes out session, re-login to the application with valid credentials and if we view that a user within the applications home page and a duplicate account is created successfully then we can conclude that the application is vulnerable to CSRF.
- We can play with the source code and change the values of the different parameters and check on the impact on the application
Once the Attack is actually performed the next step will be to exploit it. There are varieties of things that we can do with the help of this attack.
If the attack is successful it can compromise the data and in turn the whole of web application.
There are variety of unauthenticated actions as well that can be performed with the help of CSRF like voting or something big like launching a DOS attack.
Following are some of the industry specified best practices for protecting application against Cross Site Request Forgery flaw
- A random token can be included. The token will act as a unique identifier for the user session. The token can be present in the hidden HTML field and not the session. It can be appended to the URL during communication as well. Try making this session details more unpredictable thereby making the job difficult for the attacker to exploit the same.
- Apart from these it is also important for the education of the user as the weakest link is the HUMAN link which is more easily exploitable.
- It is advised to educate our users not to click on e-mail links to login into the website or any other website which they don’t trust.
- Logging out of the application is also a good practice which should be widely followed which thereby reduces the risk.
- Avoid the browser to remember your user credentials or any kind of data related to your LOGIN.
- Avoid using the same browser for the surfing of normal internet and important websites to be on safer side.
Amit Kumar Sharma commonly known as AKS-44 has an engineering degree in Electronics & Communication and works in Information Security for a reputed firm. He is passionate about Security and spends his time learning/researching in the wild