Web Application Security Testing – Part 2

Let your friend know on :

We have discussed security testing web application in our last week article. Here is the list of remaining web applications security testing tools.


Already explained in Broken Authentication and session management

Examples of vulnerable application

  • Data stored in plain text, such as passwords or credit card data (see the first well-known event)
  • Lack of HTTPS on authenticated pages
  • Hashed passwords with lack of salt, making the password easily cracked
  • Tokens disclosed in public source code
  • Browser header caching sensitive data


Cross-Site Request Forgery (CSRF)-also known as XSRF or session riding- attacks, an attacker forces a victim to make an unexpected web request such as a fraudulent bank transaction. For example, an attacker tricks the victim client into calling a banking function in a vulnerable page that transfers money from the victim’s to the attacker’s account. The victim triggers the attack by following an attacker’s link or visiting an attacker’s page. The vulnerable server page doesn’t recheck the authenticity of the victim’s request and allows the transfer to proceed.

The following steps detail the anatomy of a CSRF attack:

  1. Attacker finds functionality in a web application that is vulnerable to CSRF.
  2. Attacker builds a link invoking the vulnerable function and passing the required parameters as to executed the chosen attack.
  3. Attacker waits until the victim client authenticates with the vulnerable web application.
  4. Attacker tricks victim client into following the malicious link.
  5. Victim client sends forged request to vulnerable server.
  6. Vulnerable server allows and executes the forged request.

For example, the link might looks like this when they payload is to transfer money from the victim’s to the attacker’s account:


The link below sends an email titled Hello to johny@example.com :


Basic Test for Cross-site Request Forgery

Follow these test steps to test against CSRF bugs.

->Find a web application page that performs an action based on a user request.

->Construct a page containing a link or redirect that sends a forged request to the application server. This link usually contains a tag such as an img or iframe (although mostly any tags can be used) with the source address pointing to the request:

<a href=”http://bank.com/transfer.do?acct=MARIA&amount=100000″>View my Pictures!</a>

<img src=”http://bank.com/transfer.do?acct=MARIA&amount=100000″ width=”1″ height=”1″ border=”0″>

->Note that the links above will both generate a GET request. In order to test for POST requests you must create a page containing a form with the URL parameters passed as hidden input, and add a script to automatically submit the form:

<form action=”http://bank.com/transfer.do” method=”post”>

     <input type=”hidden” name=”acct” value=”MARIA”>

     <input type=”hidden” name=”ammount” value=”100000″>





->Open an Internet browser and log in to the web application as a legitimate user.

->Open the page built in step 2 (follow the link if necessary).

->Confirm if the request was successful.

->Repeat test case for every application create/update/delete/mail action.

Expected result: the test fails if the application trusts and processes the forged request.

–Also the cookies can be manipulated.

Another example,

Suppose, we allow users to post images on our forum. What if one of our users posted this image?

<img src=”http://foo.com/logout>

Not really an image, true, but it will force the target URL to be retrieved by any random user who happens to browse that page — using their browser credentials! From the webserver’s perspective, there is no difference whatsoever between a real user initiated browser request and the above image URL retrieval.

If our logout page was a simple HTTP GET that required no confirmation, every user who visited that page would immediately be logged out.

Examples of cross site forgery,






If the authentication check in sensitive request handlers is insufficient or non-existent the vulnerability can be categorised as Missing Function Level Access Control.

To test for missing function level access control:

The best way to find out if an application has failed to properly restrict function level access is to verify every application function:

  1. Does the UI show navigation to unauthorized functions?
  2. Are server side authentication or authorization checks missing?
  3. Are server side checks done that solely rely on information provided by the attacker?

Using a proxy, browse the application with a privileged role. Then revisit restricted pages using a less privileged role. If the server responses are alike, the My Organisation application is probably vulnerable.

In one potential scenario an attacker simply force browses to target URLs. Consider the following (non-My Organisation) URLs which are both supposed to require authentication. Admin rights are also required for access to the “admin_getappInfo” page.



If the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is a flaw, and may lead the attacker to more improperly protected admin pages.





Shellshock is a remote command execution vulnerability in Bash. A series of random characters, () { :; }; , confuses Bash because it doesn’t know what to do with them, so by default, it executes the code after it.

Good read: http://garage4hackers.com/showthread.php?t=6902

Tools used to check Shellshock:

Through command line:

  To determine if your Linux or Unix system is vulnerable, from a command line, type:

        env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

 If the system is vulnerable, the output will be:


 this is a test

 An unaffected (or patched) system will output:

 bash: warning: x: ignoring function definition attempt

 bash: error importing function definition for `x’

           this is a test

Online tools:





It is a critical bug in the OpenSSL’s implementation of the TLS/DTLS heartbeat extension that allows attackers to read portions of the affected server’s memory, potentially revealing users data, that the server did not intend to reveal.

An attacker can trick OpenSSL into allocating a 64KB buffer, copy more bytes than is necessary into the buffer, send that buffer back, and thus leak the contents of the victim’s memory, 64KB at a time.

Tools used for Heartbleed:

defribulator v1.16

Command→ python ssltest.py example.com (ssltest.py file is available with me)

Online test tool : https://filippo.io/Heartbleed/

Good read : https://blog.bugcrowd.com/heartbleed-exploit-yet/ , http://thehackernews.com/2014/04/heartbleed-bug-explained-10-most.html

For android you can download Bluebox open SSL scanner


  • Upgrade the OpenSSL version to 1.0.1g
  • Request revocation of the current SSL certificate
  • Regenerate your private key
  • Request and replace the SSL certificate

Examples of Heartbleed:






Unvalidated redirect vulnerabilities occur when an attacker is able to redirect a user to an untrusted site when the user visits a link located on a trusted website. This vulnerability is also often called Open Redirect.

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.

How to test?

Spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.

Preventing Unvalidated Redirects and Forwards

  • Simply avoid using redirects and forwards.
  • If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
  • If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
  • It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
  • Sanitize input by creating a list of trusted URL’s (lists of hosts or a regex).
  • Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.




This article is written by our QA Rijin Raj.

Let your friend know on :