An organization could also be susceptible to server- or client-based XSS vulnerabilities. Anyone who allows user-supplied input on their server side code as part of their HTML output is vulnerable to server XSS. One way to avoid this is to use context-sensitive escaping. Using JavaScript is another XSS susceptibility. JavaScript and JavaScript APIs can fall victim to attacker-controlled inputs via client XSS. There have been some tools created to help automate finding XSS issues. The issue is with various browser interpreters, such as Silverlight, Flash, JavaScript, and ActiveX, using third-party libraries it makes detection of these XSS issues difficult. There are three major types of XSS attacks: Stored, reflected, and DOM-based. The three categories described below fall into one of two categories, either server or client. Stored XSS Considered the most damaging type of XSS, this is when the payload (the malicious code) is injected into an application that is permanently stored there. When a user navigates to the seemingly benign webpage, the payload is also served, meaning that the user executes the malicious code. One of the most common examples of this is a hacker inserting a malicious script into the comment field of a blog post. Reflected XSS Considered the most common type, this is when the malicious payload is part of a request sent to a web server so that it is included in the HTTP response. The attacker may use a phishing email to have a clueless user make the request containing the malicious payload to the server, so the code is then reflected and executed inside the browser. These types of attacks normally use social media platforms to execute the attack. Since this isn’t a persistent attack, it has to be delivered to each victim and social media provide a larger pool of potential victims. DOM-based XSS Considered a more advanced type of XSS attack, this occurs when a client-side script in a web application writes data input by a user to the document object model (DOM). The data is then read by the web application and output to the browser. The attack can inject the malicious payload and have it stored as part of the DOM, meaning it is executed anytime data is read back from the DOM. Because this is a client-side attack, it is difficult to detect.
Background and Protection
Microsoft first coined the term “cross-site scripting” back in 2000, but cross-site scripting vulnerabilities have been reported since the early 1990s. In 2007, Symantec reported that XSS made up 84% of reported vulnerabilities. Ten years later, in 2017, XSS is still on the top 10 list of threats. XSS has been used to attack most of the social media sites over the years. This list includes MySpace, YouTube, and Facebook. The attack against Facebook happened in 2011. Over a period of 10 days, three different XSS vulnerabilities were discovered. These vulnerabilities were used to trick users into clicking malicious links which were used to install malicious code that allowed hackers to post on behalf of the infected users. They could send their friends spam videos, spam event invites, bogus friend requests, etc. The attacks were deemed very sophisticated and they were very successful. They were able to infect a high number of uses. So many, it was difficult to quantify. Many of the same tools the make web development and use easier are also part of the reason XSS is still so prevalent. Things like JavaScript, ActiveX, VBScript, and Flash are susceptible to XSS vulnerabilities, but are still fundamental to using web browsers. This is why XSS is still such a threat. There is no way to completely avoid it, but there are security practices to help minimize it. One of the first things to do to avoid XSS vulnerabilities is to implement secure coding practices. Using security development lifecycle (SDL) will help to reduce or eliminate XSS vulnerabilities during the development of a webpage and its applications. This includes following secure coding benchmarks and using security scanning tools to scan code during development. One of the other ways to prevent XSS is to separate untrusted data from your active browser data and to limit user input. These are strong tools to help combat against XSS, but one of the most important is always education. Ensuring that your staff, both developers and security engineers, is well educated in current trends and how to protect your organization against these issues is the best overall protection mechanism. SecurityIQ is a computer-based training platform, https://securityiq.infosecinstitute.com/, that can be used to ensure that your assets are protected and properly trained. Unfortunately, we are never going to reach a point where we will need less security. Hackers and bad actors are not becoming nicer as time goes on. Our best defense is ensuring that we know what they are up to and the best way to protect against potential attacks. References https://www.acunetix.com/websitesecurity/xss/ https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf
