In the world of technology which is constantly growing and improving comes with increased risks and security vulnerabilities that those with malicious intent seek to take advantage of. Cross-site scripting (XSS) is one such method that is primarily used in web applications to allow the attacker to inject client-side scripts onto web pages. This type of attack is called code injection.
Unsuspecting users then view these web pages which then give the attacker a means of bypassing authorization for access controls. One such access control is the same-origin policy which follows that a script running on a web page is allowed to run on the same web page only if they are both of the same origin (URI scheme, hostname, and port number). Typically, this would prevent a malicious script from one web page from going to another web page and accessing sensitive data and information; however, XSS bypasses this by taking advantage of security flaws in web applications' servers or plug-in systems.
Once the attacker has successfully taken advantage of one of these vulnerabilities and compromised the site, unsuspecting victims have basically granted the script the same level of permissions they would have given to the site, such as access to cookies. This would then allow the attacker to view any sensitive information a user might be inputting onto the site ranging from passwords to credit card information. The website's page content, session cookies, and browser-maintained information would all be accessible by the attacker at this point.
Types of Cross-Site Scripting
The persistent XSS flaw, sometimes called, the stored XSS flaw, occurs when the data is saved by the web server and then displayed on the web page as if everything is fine because the web page does not use HTML escaping. The compromised data is usually stored and displayed permanently on the web page, hence the name and why this type is the more destructive of the two. For example, if users populated online forums or message boards, and while they might have provided their profiles with their full details, they might restrict some of that information from being visible to others. This does, however, mean that the information is still stored on the server. An attacker could join a forum and implement their script in a clever way on their profile, encased in the <script> tag so that it doesn't appear on their profile when others visit it. Then, when unsuspecting people visit our attacker's profile, their script is run automatically and sends all of their information from their very own computer directly to the attacker's server. Throughout the entire process, the user is oblivious to the entire process while their information is being divulged without their consent. Web sites such as online message boards, forums, and social media are actually the main targets of these exploitations. Even Twitter and Facebook were quite riddled with them in their earliest stages.
The non-persistent XSS flaw, or the reflected XSS flaw, is more basic and common than its counterpart and occurs when data is inputted and is being used without being sanitized. This is more commonly found when the data is used for HTTP query parameters such as a form submission. As HTML files are flat in nature and structure with a mixture of control statements, formatting, and actual web content, user-inputted data needs to be validated to avoid possible code injection. For example, any web application which uses a search function typically accepts the user input and displays it once again; word-for-word, on the results web page. As such, if the user input is not properly validated and rejects HTML keywords, it is very likely to be injected as HTML. This is typically done from a neutral website or an email which is typically a URL that looks harmless and leads to a trustworthy website. Unfortunately, however, somewhere on the website will have the script and if the website suffers from this XSS flaw, the unsuspecting user will execute the script the moment they open the URL.
Some other notable mentions of XSS flaws are Self-XSS and Mutated XSS. In the case of the former, this is done through social engineering to trick a victim into executing the malicious script on their own. It's technically not an XSS vulnerability as it relies on tricking an individual through social engineering, it still carries with it the same risk as the aforementioned XSS vulnerabilities. Mutated XSS (mXSS) is when the attacker's code injection looks safe to the browser but is then changed in some way by the browser. This method is difficult to identify and therefore; sanitize, and could be something as simple as the browser adding closing quotation marks to an unclosed parameter.
There also exists measures that do not focus on content-filtering such as adding additional security when using cookie-based user authentication. As session cookies are the primary use of many web applications for verification between HTTP requests, many web applications tie the user's IP Address to a cookie so that only that person can access the cookie. This process mitigates the threat of an XSS attack; especially if the attacker is only after that cookie; however, this becomes less effective in scenarios of the attacker being behind the same network address translated (NATed) IP Address or web proxy as the target, or if the victim changes their mobile IP Address (MIP).
Share this post
Leave a comment
All comments are moderated. Spammy and bot submitted comments are deleted. Please submit the comments that are helpful to others, and we'll approve your comments. A comment that includes outbound link will only be approved if the content is relevant to the topic, and has some value to our readers.