Cross-Site Scripting (XSS)
- Jen C
- 7 days ago
- 2 min read
Updated: 6 days ago
No, XSS isn't a shirt size. It stands for Cross-Site Scripting. These are attacks when an attacker injects a malicious script into a trusted website in a user-provided input. They might use a web application to inject the malicious code. This frequently happens when a web application uses input from a user but generates without validating or encoding the data passed. They can also launch an attack by modifying a request. In summary, XSS is a vulnerability that can enable the execution of unauthorized JavaScript code in users' browsers, posing serious security threats such as session theft, display of malicious content, or unauthorized redirects.
How does this impact the unsuspecting user? The malicious script is sent to the browser but the browser doesn't know that it can't be trusted, thus the script is executed. Oh no! Cookies, session tokens and other sensitive information can be retained. XSS can even rewrite the content of an HTML page!
There are three XSS approaches. Let's dive in.
Stored XSS: Malicious code is stored on the server and displayed later to users. This happens when an injected script is stored in a database. It can also be in a message forum, visitor log, comment field, and so on. When the script is accessed from the server and boom! Now the user is compromised.
Reflected XSS: Malicious code is reflected back to the user through entry points like URLs. This happens when an injected script is reflected off of the web server. They are delivered to victims in an e-mail or on another website. They are tricked into clicking on the link (or browsing to a site or even entering data into a bad form) and boom! Code gets injected, the user's browser executes the code because it appears to be a trusted site.
DOM-based XSS: Malicious code affects the client-side Document Object Model (DOM). This happens when the attacker injects a script into a response and crafts a malicious URL. The user is tricked into clicking it and boom! The attacker has all active session information such as keystrokes, etc. This all happens within the user's browser.
Wow! So how can we protect our users and prevent XSS attacks?
We can architect our systems to perform input validation and sanitization on data from untrusted sources.
Input Validation: Ensure that all user data is validated before processing.
Data Sanitization: Use dedicated libraries to sanitize and escape special characters.
Content Security Policy (CSP): Implement a content security policy to restrict script execution to trusted sources.
Special Character Escaping: When displaying dynamic data, escape special characters to avoid misinterpretation.
Follow secure development guidelines by building in security every step of the way.
Consider incorporating additional sanitization libraries like, for instance, DOMPurify (Library dedicated to sanitize and escape special characters, used in cases of client-side XSS)
Additional subcategories and examples include:
Persistent vs. Non-Persistent XSS: Reflects whether injected code is stored on the server (Persistent) or reflected directly (Non-Persistent).
Server-side vs. Client-side XSS: Indicates whether malicious code is executed on the server or in the client's browser.
Helpful links:
Comments