FEATURE
Caught in the cross-site scripting fire Andrew Mason
Andrew Mason, RandomStorm Programming is back on the curriculum. The goal of the Raspberry Pi Foundation is to promote computing education by taking children back to the basics of programming computers and to “foster a renaissance in coding”, in the words of Raspberry Pi Foundation’s director, Eben Upton.1,2 To facilitate this, the Foundation has developed a fully functioning computer that retails for just $25. While this drive to get programming onto the national curriculum is laudable, as penetration testers will tell you, one of the issues they frequently encounter is the gap between the ability to program and the knowledge of how to program securely. This article will examine some of the techniques used by security researchers to test common web platforms for vulnerabilities that could be exploited by malicious hackers and cyber-criminals. Many web application vulnerabilities can be searched automatically using underground hacking tools. For the purposes of this article, we will be using the Damned Vulnerable Web App (DVWA) tool, developed by security researcher and ethical hacker Ryan Dewhurst to provide a legal platform for teaching developers and security researchers about common vulnerabilities. We will then provide a fictitious example of a common vulnerability, to demonstrate how slipshod application development can put businesses and their customers at risk of privacy breaches, identity theft and fraud.
disclosure of an information security breach within 24 hours and the introduction of fines amounting to 2% of an organisation’s global turnover if customer databases are compromised.3,4 As the web is the main vector for attacks on company databases and intellectual property, this is a good time to reassess the importance of secure web application development.
Using the DVWA The DVWA is a free PHP/MySQL web application that contains many of the common vulnerabilities that hackers and cyber-criminals seek to exploit.5 It was developed by Dewhurst to provide a way of teaching application developers about
the common programming mistakes that allow malicious code to be inserted into strings, making the application unsafe for users. DVWA also serves as a training tool for security professionals, to help them hone their penetration testing skills in a legal environment. The web app can also be used in classrooms as part of a computer science and cybersecurity course to show students how to test for Cross-Site Scripting (XSS), file inclusion, SQL injection, brute force attacks or how to upload exploit vulnerabilities within web applications. As its name suggests, DVWA is indeed ‘damned vulnerable’ and it should therefore never be uploaded to a live web server, as it will be hacked. It’s recommended that you download and install XAMPP – a distribution of the Apache web server that also includes MySQL, PHP, Perl and a number of other libraries and tools – onto a local
“As the web is the main vector for attacks on company databases and intellectual property, this is a good time to reassess the importance of secure web application development” This is an important issue for all organisations. Proposed changes to European data protection laws call for
May 2012
Figure 1: The input field that is going to be attacked.
Network Security
5
FEATURE today. This has been borne out in vulnerability testing by penetration testers who also take part in voluntary disclosure programmes to help improve the security of public web platforms.
“A recent survey found that 90% of webmasters were not aware that their sites had been compromised”
Figure 2: Innocent input entered to see how it is subsequently used.
Figure 3: The HTML of the resulting page.
machine and that the DVWA is only ever run on a test machine on your local area network.6 Further details on downloading and running the DVWA tool can be read on the DVWA wiki and Dewhurst has also created an installation video.7,8
Exploiting XSS The Open Web Application Security Project (OWASP) is a not-for-profit organisation set up to improve the security of applications.9 OWASP has acknowledged that XSS is the most common security flaw found in websites
Figure 4: Injecting HTML into the input. The text is returned in bold showing that injection has worked.
6
Network Security
It is important to remove XSS vulnerabilities from websites, because they can be maliciously exploited to steal cookies, hijack user accounts, execute ActiveX and Flash content, or to redirect visitors to scam websites that launch phishing attacks. Examples of organisations’ websites that have been compromised using these methods include the BBC 6 Music and 1Xtra websites, which were used to host a drive-by download attack to infect visitors’ computers with the Phoenix Trojan, and the Sun newspaper website, which was hacked by LulzSec and displayed a false story that Rupert Murdoch had died.10,11 XSS vulnerabilities can also be used to insert malicious code into websites, without the owner’s knowledge. A recent survey undertaken by anti-malware vendor Commtouch found that 90% of webmasters were not aware that their sites had been compromised, even though they were being used to send spam, host phishing sites and to execute drive-by download attacks on site visitors.12 Once malware from a compromised website has been executed on a user’s computer, hackers and cyber-criminals can exploit this in a number of ways, such as initiating unauthorised activity on your hard disk and altering, spying on, stealing or deleting your data. And as Commtouch found in its webmaster survey, it is not easy to spot when your site has been compromised.13 Hackers use tactics such as inserting infected iframes, which look like normal pictures on the web page, but which can be used to initiate drive-by downloads of malware to visitors’ computers. This sort of activity can get your site blacklisted so it’s important to scan for vulnerabilities and remove them.
May 2012
FEATURE However, as we can see from security researchers posting vulnerabilities to the XSSed website, XSS vulnerabilities are still routinely discovered, even on the largest organisations’ websites.14 This indicates that their web developers still do not understand the potential impact on site visitors if their applications and web pages contain an XSS vulnerability.
Figure 5: The HTML showing the injected tags.
“The main cause of vulnerabilities on public web platforms is that web developers are paid to create working sites and applications as quickly as possible, but they are not security experts” The main cause of vulnerabilities on public web platforms is that web developers are paid to create working sites and applications as quickly as possible, but they are not security experts. Therefore, they don’t necessarily know how to follow OWASP best practice when developing web applications, or how to test whether their code is vulnerable to XSS attacks. That’s why the work of voluntary web application testers is so important for improving safety for all web users.
Testing for web application vulnerabilities Figures 1-8 show a demonstration, carried out by RandomStorm’s senior security engineer Robin Wood, of how to use DVWA to check for a web application for XSS vulnerability. Figure 1 shows the input field we’re going to attack. In Figure 2, we enter some innocent input to see where it is reflected back. In this case we use the word ‘Test’. Figure 3 shows how this looks in the resulting HTML. Now we’re going to see if we can inject some HTML. In Figure 4, we enter Test and see if the message comes back in bold – and it does, proving we have HTML injection. Figure 5 shows the resulting HTML. In Figure 6, we see if we can inject JavaScript with the standard basic attack
May 2012
Figure 6: Trying injection again, this time with JavaScript. The pop-up shows it worked.
Figure 7: Viewing the page’s HTML, showing inserted JavaScript.
Figure 8: Using JavaScript to create a login form.
Figure 9: A theoretical attack against a social networking site.
Network Security
7
FEATURE code of . If this works we will see a popup box containing the message XSS – and indeed it does work, showing that we can inject JavaScript. Figure 7 again shows the HTML. Most testers stop here, having shown that there’s a code injection vulnerability that could lead to XSS. But to demonstrate the full effect, let’s use JavaScript to rewrite the page to include a login box, rather than the current input field. The JavaScript used here is: getElementsByTagName(‘div’) [5].innerHTML%3D’
Please Login