Michele Spagnuolo


CSP is Dead, Long Live CSP: On the Insecurity of Whitelists and the Future of the Content Security Policy

Presented at the 23rd ACM Conference on Computer and Communications Security in Vienna -

Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.

We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies - the most comprehensive study to date. We introduce the security-relevant aspects of the CSP specification and provide an in-depth analysis of its threat model, focusing on XSS protections. We identify three common classes of CSP bypasses and explain how they can subvert the security of a policy. We then turn to a quantitative analysis of policies deployed on the Internet in order to understand their security benefits. We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS.

Finally, we propose the 'strict-dynamic' keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on unsafe domain whitelists. We discuss our experience deploying such a nonce-based policy in a complex application and provide guidance to web authors for improving their policy.

CSP is Dead, Long Live CSP: On the Insecurity of Whitelists and the Future of the Content Security Policy - Google Research

Abusing JSONP with Rosetta Flash

First presented at Hack In The Box: Kuala Lumpur -

In this paper we present Rosetta Flash (CVE-2014-4671, CVE-2014-5333), an exploitation technique that involves crafting charset-restricted Flash SWF files in order to abuse JSONP endpoints and allow Cross Site Request Forgery attacks against domains hosting JSONP endpoints, bypassing Same Origin Policy.

With this attack it is possible to make a victim perform arbitrary requests to the domain with the JSONP endpoint and exfiltrate potentially sensitive data, not limited to JSONP responses, to an attacker-controlled site.

High profile Google domains, YouTube, Twitter, LinkedIn, Yahoo!, eBay, Mail.ru, Flickr, Baidu, Instagram, Tumblr and Olark have had or still have vulnerable JSONP endpoints at the time of writing. Popular web development framework Ruby on Rails and MediaWiki also addressed this vulnerability. Rosetta Flash has been nominated for a Pwnie Award and won an Internet Bug Bounty by HackerOne.

Rosetta Flash paper - Slides

BitIodine: Extracting Intelligence from the Bitcoin Network

Master thesis work - University of Illinois at Chicago - Politecnico di Milano

BitIodine design

Bitcoin, the famous peer-to-peer, decentralized electronic currency system, allows users to benefit from pseudonymity, by generating an arbitrary number of aliases (or addresses) to move funds. However, the complete history of all transactions ever performed in the Bitcoin network, called blockchain, is public and replicated on each node. The data contained into the network is difficult to analyze manually, but can yield a high number of relevant information.

In this thesis we present a modular framework, BitIodine, which parses the blockchain, clusters addresses that are likely to belong to a same user or group of users, classifies such users and labels them, and finally visualizes complex information extracted from the Bitcoin network.

BitIodine allows to label users automatically or semi-automatically with information on who they are and what they do, thanks to several web scrapers that incrementally update lists of addresses belonging to known identities, and that connect information from trades recorded in exchanges, thus allowing to trace money entering and exiting the Bitcoin economy. BitIodine also supports manual investigation by finding paths and reverse paths between two addresses or a user and an address.

We test BitIodine on several real-world use cases. For instance, we find a connection between the founder of the Silk Road, the famous black market operating in Bitcoin, and an address with a balance exceeding 111,114 BTC, likely belonging to the encrypted Silk Road cold wallet. In another example, we investigate the CryptoLocker ransomware, a malware that encrypts the victim's personal files with strong encryption, asking for a ransom to be paid in order to release the files. Starting by an address posted on a forum by a victim, we accurately quantify the number of ransoms paid and get information about the victims.

BitIodine - GitHub

BitIodine: Extracting Intelligence from the Bitcoin Network - Thesis .

Michele Spagnuolo, Federico Maggi and Stefano Zanero - BitIodine: Extracting Intelligence from the Bitcoin Network (Financial Cryptography and Data Security 2014).

BitIodine presentation

Using Parse Tree Validation to Prevent SQL Injection Attacks

Based on Using Parse Tree Validation to Prevent SQL Injection Attacks by Gregory T. Buehrer, Bruce W. Weide, and Paolo A. G. Sivilotti

An SQL injection attack targets interactive web applications that employ database services. Such applications accept user input, such as form fields, and then include this input in database requests, typically SQL statements. In SQL injection, the attacker provides user input that results in a different database request than was intended by the application programmer. That is, the interpretation of the user input as part of a larger SQL statement, results in an SQL statement of a different form than originally intended. We describe a technique to prevent this kind of manipulation and hence eliminate SQL injection vulnerabilities. The technique is based on comparing, at run time, the parse tree of the SQL statement before inclusion of user input with that resulting after inclusion of input.

I wrote a simple Bison grammar for a subset of SQL and a lexer in Flex, then a PHP frontend that presents the user differences between parse trees of two queries: a reference query and a query to test.

Using Parse Tree Validation to Prevent SQL Injection Attacks