Tag Archives: OWASP Top 10

SQL Injection: Basics and Defence

Structured Query Language (SQL) is used all over the web and is potentially vulnerable to an injection attack any time that user input is insecurely concatenated into a query. An injection attack allows an attacker to alter the logic of the query and the attack can lead to confidential data theft, website defacement, malware propagation and host/network compromise.

Continue reading: SQL Injection: Basics and Defence

IDOR: Insecure Direct Object Reference

In my experience Insecure Direct Object Reference is one of the least well known vulnerabilities out there, but it’s a very simply issue to explain. It’s a vulnerability that generally leads to loss of confidential data but can result in the less of modification of data too.

Continue reading: IDOR: Insecure Direct Object Reference

XSS: Cross-site Scripting: Lesson 2, Contexts!

Sometimes when I’m chatting to security engineers and developers I hear them say that the only characters you need to encode (or strip) are < and >. This often comes around due to .Net’s security filter which restricts any alpha-character from appearing after a < character. This filter prevents a lot of XSS attacks but it’s definitely not complete.

So here’s a quick page about the different context in which you can exploit cross-site scripting! Throughout this page I’ll show user input in blue and the attacker’s aim is simply to get a JavaScript alert box to fire with the payload alert(1). So you’ll see that a few of these payloads don’t need those < or > characters at all!

0. Example Page

Throughout these examples I’ll use the following page HTML and I’ll move the reflection point around to show the different places you often find XSS and the characters needed for each context. The four areas of reflection have been highlighted in blue. The page could be generated with a URL along the lines of: http://xss.example.com/page?id=foo&name=Holly&greenting=Hello&profile=%2Fprofile%3Fid%3D132 

<html><body>
<div id="foo">
<p>Hello <script>document.write('Holly!')</script></p>
<a href="/profile?id=132">Profile</a>
</div>
</body></html>

1. Within the page body

<html><body>
<div id="foo">
<p>Hello <script>alert(1)</script><script>document.write('Holly!')</script></p>
<a href="/profile?id=132">Profile</a>
</div>
</body></html>

2. Within a HTML tag

<html><body>
<div id="" onmouseover=alert(1) ">
<p>Hello <script>document.write('Holly!')</script></p>
<a href="/profile?id=132">Profile</a>
</div>
</body></html>

3. Within an a HREF attribute

<html><body>
<div id="foo">
<p>Hello <script>document.write('Holly!')</script></p>
<a href="javascript:alert(1)">Profile</a>
</div>
</body></html>

The above reflection point is an interesting one because in this context the normally recommended fix of HTML entity encoding won’t work as the browser will entity decode anything within a HREF attribute! Additionally an attacker could simply replace the URL that the developer intended the link to point to with a link to a malicious site, causing a redirection if the user clicked the affected link. The lesson here is don’t allow reflection into the base of a HREF!

4. Within an existing script

<html><body>
<div id="foo">
<p>Hello <script>document.write('');alert(1);//!')</script></p>
<a href="/profile?id=132">Profile</a>
</div>
</body></html>

So as you can see there are plenty of places where an attacker can successfully get XSS payloads to fire without the requirement for < and > characters, with payloads such as ‘);alert(1);// it’s important to remember that all dangerous characters should be encoded to prevent attacks. This should include

< > " ' / ;

 

 

 

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)
 

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!