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.
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.
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.
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.
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 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.
Different consequences can occur from XSS attacks but commonly it leads back to three when it comes to JavaScripts:
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.
For web developers, there are two different ways of performing secure input handling:
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.