Tag Archives: Web Application Security

XSS: What is Cross-site Scripting? Lesson 1, Basics

Cross-site Scripting is the third vulnerability on the OWASP Top 10 and it is a vulnerability that can allow an attacker to steal confidential data, execute functions on a vulnerable site, virtually deface a site or redirect the user to a malicious page.

The vulnerability comes about because user input is insecurely embedded in a response to the user; this is partly due to the simple way in which web browsers differentiate between text and code. Consider a page like http://xxs.example.com/?name=Holly which has the following web page HTML:

<html><body><p>Hello Holly! Welcome!<p></body></html>

Web browsers utilise < and > characters to determine what is code and what is text. In the above example you can see the code “tags” such as <html> are wrapped around the text “Hello there!”. So above the browsers interpretation of what is code is shown in green and what is text is shown in blue. However instead of Holly, if I enter my name as Holly<script>alert(“Vulnerable!”)</script> the page that would be given to the web browser would look like this:

<html><body><p>Hello Holly<script>alert("Vulnerable")</script>! Welcome!<p></body></html>

As you can see, even though the script tags originated from user input and were supposed to be interpreted as simple text, as they contained those important < and > characters, the web browser has interpreted them as code and not text! This means that code has sneaked its way in from the URL in the case into the body of the page as the site did not protect against this vulnerability.

This means that an attacker can craft a malicious link which contains scripts designed to attack the user, if a user is coerced into clicking the malicious link then the attacker’s payload could fire. The payload could steal the victim user’s session credentials from their cookie, deface the pay or redirect the user to a malicious site.

If the attacker’s payload is immediately returned to the user, for example when a user clicks a link the payload fires – then this is known as Reflected Cross-site Scripting. As the payload bounces, or is reflected, on the server and delivered to the victim. Alternatively the same kind of attack can be achieved in a function such as a guestbook or forum where an attacker can save a payload and simply wait for a victim to stumble across it as they navigate the vulnerable site. This type of deployment is called Stored Cross-site Scripting.

 

Defending against Cross-site Scripting

The vast majority of XSS can be fixed in a relatively simple way, by encoding all dangerous characters that originated as user input using HTML entity encoding. The benefit of HTML entities is that the browser will show the correct character to the user but it’ll prevent an attacker from injection scripts. HTML entities look like this:

<   &lt;
>   &gt;
'   &apos;
"   &quot;

If the original payload shown earlier in the page was encoded in this way it would render in the web page code like this:

<html><body><p>Hello Holly&ltscript&gt;alert("Vulnerable")&lt;/script&gt;! Welcome!<p></body></html> 

Although it’d look a little messy – it certainly would protect the user from the attacker’s payload!

 

 

 

This article is part of a series, want to read more?
What is Cross-site Scripting?
Cross-site Scripting, Lesson 2: Contexts
An Introduction to DOM-XSS
An Introduction to Content-Security-Policy
Life After the alert(1)

 

 

 

CSRF: What Is Cross-site Request Forgery?

Often abbreviated to CSRF and often pronounced as “Sea-Surf” is an attack against a Web Application that abuses an application’s trust in the user. An attacker’s aim is to cause a function to execute on the application using the user’s authentication credentials simply by causing the user’s browser to request that function in the normal way, but from a malicious site.

For example, a user navigates to a malicious site and this site in turn sends a request to the vulnerable function on the vulnerable web site. This is where “Cross-site” comes from, it is a malicious site sending a request to the vulnerable site.

A protection mechanism exists to prevent domains from messing with each other, known as Same-Origin Protection (SOP). This protection prevents one domain from processing responses from other domains and there-by generally prevents any malicious two-way interaction between websites. However, it only prevents the malicious application from processing the response, it does not prevent the victim application from receiving and processing a request. Some requests can cause damage without the requirement for a response.

Take the function for changing a user’s password. If an application has a change password function that is accessed in a way such as:

http://vulnerable.example.com/myprofile?change-password=Password123

and the response is simply “Success” this could be abused by attackers for the purposes of account take-over. The attack would simply be that the victim navigates to a malicious site where that site sends the above GET request to the vulnerable web-server.
The attacker can place the payload on a malicious site with HTML such as:

<img src="http://vulnerable.example.com/myprofile?change-password=Password123" width=0 height=0>

The user’s web browser will by default pass along the user’s cookie-based access token to the victim website and as far as the site is concerned the user has changed their password. Allowing the attacker to simply navigate to vulnerable.example.com in their own browser and login using the password “Password123”.

There are two simple ways to fix this issue, either is generally sufficient independently. The first is for the application to check the “Referer” header in the HTTP request, if it’s not coming from a trusted site then the request should be denied. The second way to fix this issue is to embedded in the page body a security token that is required for each function to execute, as the token is embedded in the page body an attacker would not be able to determine what this is as Same-Origin Policy blocks the attacker from reading responses!

Burp Suite Keyboard Shortcuts!

If you use Burp Suite a lot then you’ll no doubt love the interface – moving between tools is really fast and the interface is just friendly; however I recently heard someone complaining that it’s annoying that it’s mouse-only and you can’t use hotkeys to swap between tabs and move between tools…but you can!

Continue reading: Burp Suite Keyboard Shortcuts!

SOP: Same-Origin Policy Basics

Same-Origin Policy (SOP) is a critical part of the security implemented within a web browser. It’s the part of your browser’s security system that prevents malicious pages from reading confidential information from other sites. So thepiratebay.com can’t read data from barclays.com because it’s blocked by SOP.

Continue reading: SOP: Same-Origin Policy Basics

Path Traversal Cheat Sheet: Windows

Got a path/directory traversal or file disclosure vulnerability on a Windows-server and need to know some interesting files to hunt for? I’ve got you covered Know any more good files to look for? Let me know! Are you on a Linux server? Try this one instead: Path Traversal Cheat Sheet: Linux

Continue reading: Path Traversal Cheat Sheet: Windows