2 Cross-site scripting (XSS)

In 2014, the BBC reported (https://www.bbc.com/news/technology-29241563) that clicking on certain links on eBay would redirect users to a phishing site: it looked similar to eBay, but, of course, wasn’t legitimate. The security researcher who found the vulnerability supposedly contacted the firm to no avail. An official inquiry by the BBC then sped things up, and the issue was resolved.

About 10 years earlier, a security researcher managed to pull a similar stunt, redirecting eBay users to phishing sites where they were prompted for their credentials—and this happened live on German television! eBay obtained an injunction against one researcher who announced he would demonstrate the exploit. However, the TV show had already contracted a second researcher who was not covered by the injunction.

In both cases, the researchers (or, more generally, the attackers) managed to inject JavaScript code into the website, which then took care of the redirection to the phishing site. Let’s have a look at how such an attack—which usually consists of injecting JavaScript code (and other content) into a website—works.

2.1 Anatomy of a cross-site scripting attack

2.2 Preventing cross-site scripting

2.2.1 Understanding the same-origin policy

2.2.2 Escaping HTML

2.2.3 Escaping in a different context

2.3 Content Security Policy

2.3.1 Sample application

2.3.2 How Content Security Policy works

2.3.3 Refactoring applications for Content Security Policy

2.3.4 Content Security Policy best practices

2.3.5 Content Security Policy Level 3 features

2.4 More browser safeguards

Summary