The original piece of data analysis was performed by two of our interns (Daniel and Chris) as part of Cisco’s intended contribution to the next Top 10 publication from OWASP however due to time constraints, our data points were not submitted. As a result, the co-authors (Simone and Isa) chose to compare the EMEAR team’s statistics from 2016 against the now public 2017 Top 10 published by OWASP. Additionally, they also took a look at the most common web application issues reported by the Team during the last year and analysed their impact and severity.

WAW.pdf
September 6, 2017
Version: 1.0

925.6 KiB
MD5 hash: 0986d3ab7f6f55c71199296189ce5f62
Details

Date:

September 6, 2017

The post Web Application Whitepaper appeared first on Portcullis Labs.

The basic premise of the attack (as described on SpiderLabs’s Reflected File Download whitepaper) is as follows:

1. The user follows a malicious link to a trusted web site
2. An executable file is downloaded and saved on the user’s machine. All security indicators show that the file was hosted on the trusted web site
3. The user executes the file which contains shell commands that gain complete control over the computer

So how does it work? On a recent engagement, one of our consultants found a similar issue. In their case, it was a stored variant of the issue SpiderLabs describe but in other regards, it was identical. The consultant discovered that the application they were testing used two APIs that allowed for the storage and retrieval of data, like so:

POST /putData HTTP/1.0
...
{"id":12345, "input":"asdf||calc.exe||pause"}

This data could then be retrieved using the following URL:

• http://URL/getData/12345;1.bat

Requesting this in a browser results in the browser believing that the user has downloaded what appeared to be a batch file called 12345;1.bat. If the user executes this file, then calc.exe (part of our original input) will be executed.

As with other similar attacks, which exploit variances in how user controlled data is treated by different components of a solution (in this case, the browser and the server), once you know what to watch out for, it’s fairly easy to mitigate.

Specifically:

• Validate all user input
• Sanitise by means of context sensitive encoding/escaping any user input that remains
• Avoid wildcard mappings such as /getdata/* on exposed web services
• Ensure that you’re correctly setting the important HTTP headers such as Content-Type and Content-Disposition (and other related headers such as X-Content-Type-Options) so that direct requests for the URL cause the file to be downloaded

This last point is particularly important, browsers will often attempt to automatically render downloaded content using whatever application is rendered for the target file type. Sending a Content-Disposition header of:

attachment; filename=1.txt

precludes this, as no matter whether it is saved or opened, it will be treated as text, a relatively safe file type.

All in all, a nice catch and one we’ll definitely use in our red team engagements.

The post You can’t even trust your own reflection these days… appeared first on Portcullis Labs.

Key features

• Allows on the fly manipulation of Content Security Policy
• Enables UX developers to get visual feedback on how a CSP affects the application functionality
• Minimises the changes required to an existing application to allow this to happen

Overview

Content Security Policies are a new feature of modern browsers that support HTML 5 designed to augment the traditional Same Origin Policy of browsers and help to limit the potential impact of Cross-site Scripting and other content manipulation vulnerabilities that may exist within a given web site and which could be exploited by an attacker. It allows allows web site owners to declare approved sources of content that browsers should be allowed to load on that page out-of-band through the use of additional HTTP headers.

The aim here is to minimise the leg work for UX developers in creating web applications that both function and utilise secure development practices. We do this by reducing the server side code changes down to the injection of some client side JavaScript along with a few lines of server side stub code (in this case, in PHP). Once this has been integrated into application in a staging environment, the UX developer can tweak the CSP from their own browser and see how it affects the application functionality :).

Installation

• Copy styles and js from src/html to your web root
• Copy index.php from src/html/examples/php to your web root or tweak your existing web pages in a similar fashion

Usage

The client side code (HTML) should include the following changes:

<head>
...
	<link rel="stylesheet" href="styles/cspCalculator.css" type="text/css"/>
...
</head>
<body>
	<script src="js/cspCalculator.js"></script>
	...
</body>

This will result in the CSS and JavaScript used to construct the cspCalculator UI being injected into resultant pages.

Additionally, as a minimum case, the server side code should implement the following logic:

$directiveslist = array("default-src", "connect-src", "font-src", "frame-src", "img-src", "media-src", "object-src", "script-src", "style-src", "sandbox");
$headerslist =  array("Content-Security-Policy", "X-Content-Security-Policy", "X-WebKit-CSP");
foreach ($directiveslist as $directivename) {
	header("Set-Cookie: " . $directivename . "=" . $_COOKIE[$directivename], false);
}
foreach ($headerslist as $headername) {
	$headervalue = "";
	foreach ($directiveslist as $directivename) {
		$headervalue .= "; " . $directivename . " " . $_COOKIE[$directivename];
	}
	header($headername . ": " . $headervalue);
}

We use cookies as a back channel to allow changes to the Content Security Policy by the UX developer from the UI to easily be signaled back to the web application so that the appropriate headers can be set. Cookies work nicely for this purpose as they do not interfere with any GET or POST parameters that the application may need to send for normal operation.

Once operational, your web application will now include a drop down cspCalculator box on each of its pages. Within the drop down you will see various text boxes for each of the CSP directives that can be defined. The “Calculate” button next to each will attempt to determine the appropriate policy by examining the page’s DOM (something that isn’t 100% effective yet). The “Apply” button will force a round-trip to the server to force it to send the page with the new CSP headers applied. It is recommended that you use this tool in combination with something such as Chrome’s Inspect Element feature to identify any DOM elements that are blocked and which cspCalculator is unable to identify automatically.

cspCalculator should not be deployed in a production environment, since the setting of cookies and/or a CSP by use of header() calls may itself introduce other classes of vulnerability. Rather, once the appropriate CSP has been identified it should be set statically through the use of header() (as in PHP) or other similar calls.

Examples

Since cspCalculator isn’t particularly easy to demonstrate in a static context, a demo version has been deployed for your amusement. This can be found on at www.cspcalculator.org. It has been presented on a separate domain to minimise the risks outlined above in the Usage section of this page.

cspCalculator-0.2.tar.gz
November 29, 2013

14.2 KiB
MD5 hash: 496b55e3ffa575178428d1d85e42e113
Details

Date:

November 29, 2013

The post cspCalculator appeared first on Portcullis Labs.

Portcullis was asked to provide consultancy in the form of analysis and good practice recommendations with respect to migrations from Flash to HTML 5.

Whilst this document is not intended to be a definitive guide, Portcullis believes that it should provide a high level summary of the pros and cons of the proposed migration.

HTML5GPG.pdf
April 26, 2013

383.1 KiB
MD5 hash: 419f5768fc2814c6e1eeaa774ba42148
Details

Date:

April 26, 2013

The post HTML 5 Good Practice Guide appeared first on Portcullis Labs.