Ethical Hacking
Understanding Cross-Site Scripting (XSS)
Cross-site scripting (XSS) is a security vulnerability typically found in web applications. It occurs when an attacker injects malicious scripts into web pages viewed by other users. These scripts can then execute in the browsers of unsuspecting users, leading to potentially harmful consequences.
Upon initial injection, the site is typically not controlled by the attacker. Instead, the bad actor attaches their malicious code to a legitimate website, primarily tricking browsers into executing their malware whenever the site is loaded.
JavaScript is a programming language that runs on web pages inside the browser. This client-side code adds functionality and interactivity to the web page and is employed widely on each vital application and CMS platform.
It is sandboxed to the navigator and can perform actions or activities within the browser window. While JavaScript is client-side and does not run on the server, it may interact with the server by performing background requests. Attackers can utilize these background requests to feature undesirable spam content on a web page without refreshing it, gather analytics regarding the client's browser, or perform actions asynchronously.
Types of Cross-Site Scripting
Reflected XSS: Cross-site scripting attacks occur once the payload is stored in the data sent from the browser to the server. Examples include when an attacker stores malicious scripts in the data sent from a website's search or contact form. A typical example of reflected cross-site scripting would be if a malicious actor sends a link with an injection to a victim, and therefore, the victim clicks on the link.
Stored XSS: Attacks occur when attackers store their payload on a compromised server, causing the website to deliver malicious code to other visitors. Since this technique solely needs an initial action from the attacker and can compromise many visitors afterward, this can be the foremost dangerous and most commonly utilized type of cross-site scripting.
A typical example is the Myspace XSS worm, which impacted one million users in 20 hours.
DOM-Based XSS is an XSS attack in which the attack payload is executed by modifying the DOM “environment” in the victim’s browser used by the original client-side script so that the client-side code runs unexpectedly. The page (the HTTP response) does not change, but the client-side code executes differently due to the malicious modifications in the DOM environment. <img scr = “ ”> will often load content from other websites, making a cross-origin HTTP request.
Cross-Site Scripting Attack Mitigation Strategies:
Allow-List Values: Limit user input to a selected allow-list. This practice ensures that only known and safe values are sent to the server. Limiting user input only works if one knows what data will be received, such as the content of a drop-down menu, and is not practical for custom user content.
Avoid and Restrict HTML in Inputs: While HTML could be needed for rich content, it should be restricted for trusted users. If one permits styling and formatting on input, one should consider using alternative routes to generate the content, like Markdown.
Sanitize Values: When one uses user-generated content on a page, ensure it will not lead to HTML content by substituting unsafe characters with their respective entities. Entities have the same appearance as regular characters but cannot generate HTML.
Use HTTPOnly Flags on Cookies: Session cookies enable a website to recognize a user between requests, and attackers frequently steal admin sessions by exfiltrating their cookies. Once a cookie has been stolen, attackers can log in to their accounts without credentials or authorized access. Use HTTPOnly cookies to prevent JavaScript from reading the cookie's content, making it more challenging for an attacker to steal the session.