Download as PDF, PPTX
Uploaded bySam Bowne
CNIT 129S: 12: Attacking Users: Cross-Site Scripting (Part 1 of 2)
The document discusses cross-site scripting (XSS), a prevalent web application vulnerability that can lead to session hijacking and unauthorized actions. It details different types of XSS, including reflected, stored, and DOM-based XSS, with real-world examples of attacks on platforms like Myspace and Apache. Additionally, it explores attack delivery mechanisms and the potential for serious compromises when chaining vulnerabilities together.
CNIT 129S: 12: Attacking Users: Cross-Site Scripting (Part 1 of 2)
- 1. CNIT 129S: Securing WebApplications Ch 12: Attacking Users: Cross-Site Scripting (XSS) Part 1
- 2. Attacking Clients • Vulnerabilitiesin browsers • May result in session hijacking, unauthorized actions, and disclosure of personal data, keylogging, remote code execution • XSS is the most prevalent web application vulnerability in the world
- 3. Varieties of XSS •Reflected XSS • Stored XSS • DOM-Based XSS
- 4. Reflected XSS • Example:an error message that takes text from user and displays it back to the user in its response • 75% of all XSS vulnerabilities are this type
- 9. Persistent Cookies • Ifuser has a persistent cookie, implementing "remember me" • Step 1 is not needed • User need not be currently logged in
- 10. Same-Origin Policy • evil.comcannot get your target.com cookies from your browser • Only a page in the same domain (arget.com) • But XSS lets the attacker add scripting to a page that comes from target.com • Hence the name Cross-Site Scripting
- 11. Stored XSS Vulnerabilities •A message is stored • Executed on any user who views it • May attack a large number of users
- 14.
- 15. The Vulnerability • Client-sideJavaScript can access the browser's Document Object Model • Can determine the URL used to load the current page • A script the developer put there may extract data from the URL and display it, dynamically updating the page's contents
- 16. Example: Dynamically Generated ErrorMessage • Writes message to page • Can also write script to page
- 19.
- 20. Apache (2010) • XSSin issue-tracking application • Attacker injected code, obscured it with a URL shortener • Administrator clicked the link • Attacker stole the administrator's cookie • Attacker altered the upload folder for the project and placed a Trojan login form there
- 21. Apache (2010) • Attackercaptured usernames and passwords for Apache privileged users • Found passwords that were re-used on other systems within the infrastructure • Fully compromised those systems, escalating the attack beyond the vulnerable Web application • Link Ch 12a
- 22. MySpace (2005) • Samyevaded filters intended to block XSS • Added JavaScript to his user profile, that made every viewer • Add Samy as a friend • Copied the script to the user's profile • Gained over 1 million friends within hours • Link Ch 12b
- 23. • Stored XSSin email allowed attackers to send a malicious email to the CEO • Stealing his session cookie
- 24. Twitter (2009) • LinkCh 12d
- 25. Other Payloads forXSS • Virtual Defacement • Add images, code, or other content to a page
- 27. Injecting Trojan Functionality •Inject actual working functionality into the vulnerable application • Such as a fake login form to capture credentials • Or the fake Google purchase form on the next slide, from 2004
- 29. Disadvantages of Session Hijacking •Attacker must monitor her server and collect cookies • Then carry out actions on behalf of target users • Labor-intensive • Leaves traces in server logs
- 30. Inducing User Actions •Use attack payload script to carry out actions directly • If the goal is to perform an administrator action, each user can be forced to try it until an administrator is compromised • MySpace XSS worm did this
- 31. Exploiting Trust Relationships •Browsers trust JavaScript with cookies from the same website • Autocomplete in the browser can fill in fields, which are then read by JavaScript • Some sites require being added to Internet Explorer's "Trusted Sites"; those sites can run arbitrary code like this
- 32. Exploiting Trust Relationships •ActiveX controls often contain powerful methods • They may check to see that requests came from the expected site • With XSS, that condition is satisfied
- 33. Escalating the Client-Side Attack •Website may attack users by • Logging keystrokes • Capturing browsing history • Port-scanning the local network
- 34. Delivery Mechanisms for XSSAttacks
- 35. Delivering Reflected and COM-BasedXSS Attacks • Phishing email containing a crafted URL • Targeted attack with custom email • Instant message containing a URL • Code posted on websites that allow user to post HTML
- 36. Watering Hole Attack •Attacker creates a website with content that will interest the target users • Use search engine optimization to attract viewers • Page contains content that causes the user's browser to make requests containing XSS payloads to the vulnerable application
- 37. • Purchase adspace, put malicious URL in the ad • The ad may appear in pages about the app you are attacking, because of keyword matches • Web apps often have "tell a friend" or "send feedback" features • Leverage this to deliver an XSS attack via an email that originate from the organization's server Delivering Reflected and DOM-Based XSS Attacks
- 38. Delivering Stored XSS Attacks •In-band (most common)
- 39. Delivering Stored XSS Attacks •Out-of-band (most common) • Anything other than viewing the target app • Such as email from its server
- 40. Chaining XSS • XSSvulnerability itself may be low-risk • But chaining it together with other vulnerabilities can cause serious compromise
- 41. Example • XSS allowsscript to be inserted into user's displayed name • Access control flaw lets attacker change other users' names • Add token-stealing XSS to every username • Gain administrator credentials: total control of application