XSS Flashcards

A web vulnerability that allows attackers to inject malicious scripts into pages viewed by other users. XSS exploits the browser's trust in websites — when code appears to come from a trusted domain, the browser executes it. The attack targets the user (client-side), not the server. Abbreviated XSS because CSS was already taken by Cascading Style Sheets.

The trust a browser places in the websites it visits. When a script appears to originate from a trusted domain, the browser executes it without suspicion. Attackers exploit this by getting their script embedded in — or delivered through — a legitimate site the victim already trusts, so the browser runs the attacker's code as if it were the site's own code.

The script is embedded in a URL, sent to a specific victim via email or message, and reflected back by the server in its response. Not stored on the server — it only executes when the crafted link is clicked. Targets individual victims. The server "reflects" whatever is in the URL parameter back into the HTML response without encoding it.

The script is permanently saved on the server (database, forum, comment field). Every user who views the infected page has the script execute automatically — no crafted link required. Affects all page viewers, not just a specific target. Can propagate like a worm on social networks where script can automatically re-post itself to viewers' profiles.

JavaScript is enabled in virtually every browser by default. Running in the browser, it has access to session cookies (document.cookie), can make authenticated requests, capture keystrokes, inject HTML, and redirect the page — all silently. The attacker's malicious JavaScript runs with the same permissions as the legitimate site's own scripts because the browser sees it as coming from the trusted domain.

The most common XSS goal. The script reads document.cookie and sends the session token to the attacker's server. With the stolen cookie, the attacker can impersonate the victim on the target site — fully authenticated, no password needed. The victim never sees anything abnormal. The only indication is the unauthorized request to the attacker's server in the background.

The primary developer defense against XSS. Converts special HTML characters in user content to their entity equivalents before rendering — < becomes &lt;, > becomes &gt;. The browser displays the encoded characters as visible text and never interprets them as HTML tags or script. Even if a user submits <script>, the page shows <script> as text rather than executing it as code.

An HTTP header that tells the browser which script sources are authorized to execute on the page. A well-configured CSP blocks inline scripts and limits script loading to specific trusted domains. Even if an attacker injects a script tag, the browser refuses to execute it if it violates the CSP. A defense-in-depth layer that complements — but does not replace — output encoding.

June 2017: researcher Aaron Guzman found that Subaru's web portal issued never-expiring authentication tokens that allowed any service request — including adding email addresses to other users' accounts (giving full vehicle management access). An XSS vulnerability in the front-end let attackers steal tokens via a malicious link. Stolen token + no expiry + overpowered permissions = permanent access to any targeted vehicle.

Both are code injection attacks, but they target different environments. SQL injection: injected code is executed by the database server (targets the back end). XSS: injected code is executed by the victim's browser (targets the client side). The fix reflects the difference — parameterized queries stop SQL injection; output encoding stops XSS. Same vulnerability category, completely different execution environment and defense.