Today's meeting covered the basics of XSS (Cross-Site Scripting), a web vulnerability that occurs when an attacker injects malicious scripts into a website via user input that is not properly sanitized. We explored how browser implementations of HTML and JavaScript can be exploited to execute code on a server machine, effectively bypassing the security boundaries of the web.

How the Web Works

To understand XSS, we first looked at the standard communication model of the web. When you visit a website, your browser (the Client) sends a request to a Server. The server responds with HTML code, which the browser then renders into the visual page you see. Modern webpages include JavaScript (JS), a programming language that runs directly in the client's browser to provide interactivity. The main takeaway is that the browser usually implicitly trusts the code sent by the server and executes it automatically.

The Same-Origin Policy

Since they often handle personal data (like login cookies), most browsers implement a "Sandbox" to keep sites isolated. This security level revolves around the Same-Origin Policy, which ensures that a script running on some site-a.com cannot access data or cookies belonging to an external site-b.com. While this prevents one tab from spying on another, XSS is dangerous because it tricks the browser into thinking the malicious script is coming from the trusted site itself, thereby potentially granting the attacker access to that site's cookies, session data, or other sensitive information.

How XSS Works

Websites often take user input in the form of search queries, comments, or profile names, and display them back on the page. HTML uses specific tags (like <script>) to define where code begins. If a website takes your input and places it directly into the HTML without sanitizing it, an attacker can input their own tags in place of intended input data. For example, instead of searching for a "laptop," an attacker might search for:

If the server reflects this string back into the page's HTML, the browser sees a valid script tag and executes it.

Types of XSS

• •Stored XSS: The malicious script is permanently implanted on the target server (e.g., in a database, a comment field, or a user profile). Every user who views the affected page will automatically execute the script in their browser.
• •Reflected XSS: The malicious script is "reflected" off a web application to the victim's browser. It is usually delivered via a link (e.g., in an email or chat). When the victim clicks the link, the script is sent to the vulnerable website and immediately bounced back to the user's browser.
• •DOM-based XSS: The entire vulnerability exists in the client-side code rather than the server-side code. The attack happens when the page's legitimate JavaScript takes data from an unsafe source (like the URL fragment) and writes it to the Document Object Model (DOM) in an unsafe way.