7 minutes, 29 seconds read
Published on Sep 25, 2017
Updated on Apr 24, 2020
In the previous article, we discussed risks and web application security testing measures for 5 types of attacks-
- Injection
- Broken authentication and session management
- Cross-site scripting
- Indirect object security reference
- Security misconfiguration
Link – Part 1
Now let’s continue with the remaining 5 web application security threats.
6. Sensitive data exposure
Broken authentication and inefficient session management leads to sensitive data exposure. Examples of applications vulnerable to sensitive data exposure.
- Data stored in plain text, such as passwords or credit card data
- 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
I would suggest going through the part 1 of this series for in-depth knowledge about this vulnerability.
7. Cross-site forgery
Cross-Site Request Forgery (CSRF) or session riding- attacks, an attacker forces a victim to make an inappropriate 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 proceeding the transfer.
The following steps detail the anatomy of a CSRF attack:
- The attacker finds a functionality in a web application that is vulnerable to CSRF.
- Attacker builds a link invoking the vulnerable function and by passing the required parameters, executes the attack.
- The Attacker then waits until the victim client authenticates with the vulnerable web application.
- Attacker tricks the victim client into following the malicious link.
- Victim client sends a forged request to a vulnerable server.
- Vulnerable server allows and executes the forged request.
For example, the link might look like this when the payload is to transfer money from the victim’s to the attacker’s account:
/makeTransfer?amount=1000&dest=attacker@attackersite.com
The following link sends an email titled ‘Hello’ to johny@example.com –
/sendMail?to=johny@example.com&title=Hello&body=I+did+not+send+this
Basic test for cross-site request forgery
You can follow these test steps to test against CSRF bugs-
- Find a web application page that triggers/performs an action upon 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 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 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″>
</form>
<script>
document.forms[0].submit();
</script>
- 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, attackers can manipulate cookies.
Another example,
Suppose, we allow users to post images on our forum. What if one of our users post this image?
<img src= “http://foo.com/logout”>
This is not really an image. 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 requires no confirmation, every user who visits that page would be immediately logged out.
Consider these examples of cross-site forgery: CSRF token leakage through Google Analytics, deleting account and erasing imported contacts, change any user ZONE, Add optional two factor mobile number
8. Missing function level access control
If the authentication check in sensitive request handlers is insufficient or non-existent, the vulnerability is Missing Function Level Access Control.
How to test for missing function level access control?
The best way to find out if an application fails to properly restrict function level access is to verify every application function-
- Does the UI show navigation to unauthorized functions?
- Are server side authentication or authorization checks missing?
- Are server side checks 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 Organization application is probably vulnerable.
In one potential scenario an attacker simply forces the browser to target URLs. Consider the following (non-My Organisation) URLs which should require authentication. One also requires admin rights to access the “admin_getappInfo” page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
If a non-authentic user (attacker) gets access to either page, then it means — unauthorized access was allowed. This flaw may lead the attacker to access more unprotected admin pages.
Example of missing function level access control atack – Delete Credit Cards from any Twitter Account.
9. Shellshock and Heartbleed attacks
Shellshock
It 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.
More on — manually exploiting shellshock vulnerability
Tools for checking Shellshock
Through command line:
To determine if your Linux or Unix system is vulnerable, type the following in the command line-
env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If the system is vulnerable, the output will be:
vulnerable
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 –
Heartbleed
It is a critical bug in OpenSSL’s implementation of the TLS/DTLS heartbeat extension. It 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.
Web application security testing tools for heartbleed attack
- defribulator v1.16 : Command→ python ssltest.py example.com (ssltest.py file is available with me)
- Online tool: Filippo
- For android, you can download Bluebox open SSL scanner
Also read – Heartbleed bug FAQs, Bugs and solutions
How to prevent heartbleed attack?
- 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 security attacks: information disclosure on Concrete5, port 1433, server returning more data
10. Unvalidated redirects and forwards
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.
It is 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 unvalidated redirects and forwards?
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.
Web application security testing: preventing unvalidated redirects
- Simply avoid using redirects and forwards.
- If at all you’re using redirects/forwards, do not allow the url as user input for the destination. In this case, you should have a method to validate the URL.
- If you cannot avoid user input, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
- Map any such destination input to a value, rather than the actual URL or portion of the URL. Ensure that server side code translates 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.
Consider these examples: open redirect, open redirect in bulk edit
So, this was all about prevailing risks and web application security testing measures to prevent your website from attackers. For further queries & doubts, feel free to write to hello@mantralabsglobal.com
About the author: Rijin Raj is a Senior Software Engineer-QA at Mantra Labs, Bangalore. He is a seasoned tester and backbone of the organization with non-compromising attention to details.
Related:
Knowledge thats worth delivered in your inbox
