It’s a dangerous hack that accounts for over 80% of security vulnerabilities since 2007, cross-site scripting attacks can go from being a nuisance issue to becoming a significant security problem for companies that handle sensitive data.
What is cross-site scripting?
Cross-site scripting, also known as XSS is typically found in web applications and is a vulnerability in computer security. XSS gives attackers the ability to administer client-side scripts into online pages to be viewed by other users. Code injection exploits computer bugs that are created from invalid data, adding the harmful code to a website and leaving it vulnerable to even more harmful security issues.
XSS background
What are the main types of XSS? Originally there were two known types of XSS – stored and reflected. The third was then founded and after more research, some were blended together and now cross over each other. These types of attacks are created with different tactics, the XSS hacks use these occurrences to their advantage then inject the malicious data.
- Stored XSS: these attacks happen when user input from guests to the website is added to the targeted host site. Forums, databases, visitor logs and comment fields are all used for this type of attack. Victims can retrieve stored data from web applications that haven’t been made safe to render in the browser. The harmful package can attach add-ons to your computer commonly but this is a tame attack compared to its potential of destroying data.
- Reflected XSS: when a user’s input is returned immediately with a web application error message, search result or another response that includes most or all the input provided by the user as part of the request, without that data being made safe to render by the browser. The attacker’s payload is basically part of the request and looks organic in the search. The XSS is reflected towards the user and by using phishing emails and other engineer techniques, the attacker will lure victims into disclosing information to what they think is a legitimate site.
- DOM Based XSS: Document Object Model attacks are created by altering the “environment“ in the victim’s browsers used by the original client-side script. From the client’s side, it will run in an unexpected manner, the page itself will not change but due to the malicious modifications that have occurred, the page executes differently.
Current types of cross-site scripting
Previously, there were a few different types of Cross-site scripting, but in recent years’ research has proven that most of them overlap each other constantly and there’s no easy way to break down how a website is being targeted. Currently, the two types are known as Server and Client cross-site scripting.
Server XSS
This happens when untrusted user-supplied data is added to the HTML response generated by the server. The origin of the data could be from a request or stored location. This means it can be both stored or reflected XSS. With server XSS all the vulnerability comes from the server’s side, and the browser is simply renders the response and applies any valid script embedded.
Client XSS
Client XSS occurs when untrusted user-supplied data is added to the DOM with an unsafe JavaScript call. The origin of the data could come from the DOM or be sent from the server (page load, for example). The source of the data could potentially originate from a request, or from a stored location on the client or server. That’s why it could be either a reflected client or stored client XSS.
These two new definitions don’t ignore the DOM based attacks. DOM XSS is a subsidiary of a client XSS. The data has come somewhere from the DOM rather than the server.
Consequences from malicious attacks
Different consequences can occur from XSS attacks but commonly it leads back to three when it comes to JavaScripts:
- Cookie Theft: A victim’s cookies can be accessed by the attacker using document.cookie via the website. The attacker can then send sensitive information from the victim’s current sessions like ID’s, for example.
- Keylogging: the attacker can add a keyboard event listener to the victim’s server and then have the ability to send all the victim’s keystrokes to the attacking server. By doing this the attacker can record sensitive information such as passwords and credit cards numbers.
- Phishing: mentioned earlier briefly, the attacker can insert a fake login form to the victim using DOM manipulation, adjust the form’s attributes to target their own server and then manipulate the victims into submitting personal information.
Defending against XSS attacks
If you have a website you need to guard all parts of the pages that welcome incoming data. Each section needs to be hardened against malicious data that could be executable code. This will require adding multiple filters to your site along the communication pathway. A web application firewall like ModSecurity will add sanitization with the server-side input processing code, which in turn protects browsers.
Another approach to enhancing web application security is the use of sigma rules, which are standardized detection rules that can be applied across various security information and event management (SIEM) systems to identify suspicious activity in log events.
For web developers, there are two different ways of performing secure input handling:
- Encoding: this avoids the user input so that the browser interprets it only as data rather than code, meaning attackers are unable to alter it.
- Validation: this filters the user’s input so the browser interprets it as code without any malicious commands.
As a webmaster, you’re not expected to know everything about online security and how its best to avoid hacks, so consider researching the best options for yourself and your users. There are tools like XSS Me for Firefox and Domsnitch for Chrome for those who want to test their own sites against potential vulnerabilities. If you are unsure about your protection against XSS, speaking to a cyber security researcher can also help on advising you the best approach to take.
It can be a dangerous hack to be involved with so if you do run a site it’s worth investing in protection. Likely if your visitor is being impacted by the problems and they find out its because your site is vulnerable, and simply go elsewhere for their browsing needs.
If you feel you might be a victim to a XSS attack, asking a professional to look into your system is advised. Be sure to use someone who has experience with resolving the issues and also has IT contractor insurance, this avoids further problems and if the issue isn’t resolved, both you and the contractor are protected from any loss or further damage.
Add comment