Tag Archives: Web Application Security

Burp Macros: Automatic Re-authentication

During a recent penetration test I came up against a security feature that would invalidate my session whilst I was fuzzing if it saw simple attack strings, so if I used <script> anywhere then it’d kill my session. Most frustrating! Especially as it essentially prevented the use of tools such as Burp’s Active Scanner and it made using Repeater inconvenient too. So I quickly threw together a Burp Macro to handle automatic re-authentication for me and went back to fuzzing!

So here’s how to do that!

Continue reading: Burp Macros: Automatic Re-authentication

Web Application Defense: Filtering User Input

Effectively filtering user input is one of the best ways to prevent an awful lot of web application vulnerabilities. There are several ways to approach this, each with their own pros and cons so I’ll run through them here an then you can think of the best way to combine them for your context. It’s important to remember though, that filters are context specific, there is not one filter that will work for a whole application and that’s what can make writing an effective filter tricky.

Continue reading: Web Application Defense: Filtering User Input

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)