Cross-Site Scripting

1. Cross-Site Scripting CSCD 498/539 Secure Coding Principles Amazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith Allen Greaves Zach Moore Rebecca Long

2. Introduction & Overview Amazing Legion of Fuzzy Backdoor Intruder Worms Zachary Moore

3. Cross-Site Scripting (XSS): • Abbreviation: XSS stands for cross-site scripting rather than CSS to avoid confusion with Cascading Style Sheets. • Definition:A computer security vulnerability typically found in web applications which allows code injection by malicious web users into the web pages viewed by other users. • Code Injection: A technique to introduce code into a computer program or system by taking advantage of the unenforced and unchecked assumptions the system makes about its inputs.

4. A Note on the Term 'XSS': • The term 'Cross-Site Scripting' is actually a technically incorrect name for this vulnerability. • This is for two reasons: • The issue is not just dependent on scripting. It is dependent on the browser settings, the level of privilege, malicious social engineering, etc. It may not even be script but rather plain HTML that is injected. • It's not even typically cross-site based. Some versions of this exploit depend on injected code only, not another site.

5. The XSS Scenario: • One or more browser windows are open by a user. • A client-side scripting language (i.e. JavaScript) can successfully run. • The access-control policies (i.e. same-origin policy) used by either the browser or language can be bypassed by a malicious user. • This scenario leads to an XSS 'hole' in the web page. • The malicious user can inject script into pages served by other domains. This gains elevated access privileges to sensitive page content, session cookies, and a variety of other objects.

6. Security Bypassed via 'XSS': • The Sandbox: the restricted environment that limits the executing code of a web page to a limited amount of resources. • Limits include making data non-persistent and disabling reading from input devices. • A JavaApplet or a scratch disk are both sandboxes. • The same-origin policy: this policy allows any interaction between objects and pages, so long as these objects come from the same domain and over the same protocol. • (Other policies may also need to be bypassed.)

7. Types of XSS: • There are three types of XSS. Type 1 is most common. • Each type is based off the origin of exploit and the resulting vulnerability : • Type 0: aka DOM-based or Local • Origin: Client-side. ==> Socially engineered! • Vulnerability: Remote (delayed) execution via local zone privilege. • Type 1: aka Non-Persistent or Reflected • Origin: Client-side. ==> Socially engineered! • Vulnerability: Affects immediate results for only this client. • Type 2: aka Persistent or Stored • Origin: Server-side. • Vulnerability: Affects all results for all clients. • The names of the types are not necessarily industry standard nomenclature.

8. Type 0: Local • Mallory sends a URL to Alice (via email or another mechanism) of a maliciously constructed web page. • Alice clicks on the link. • The malicious web page's JavaScript opens a vulnerable HTML page installed locally on Alice's computer. • The vulnerable HTML page contains JavaScript which executes in Alice's computer's local zone. • Mallory's malicious script now may run commands with the privileges Alice holds on her own computer. ** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scripting

9. Type 1: Non-Persistent • Alice often visits a particular website hosted by Bob where Alice can log in and store sensitive information. • Mallory observes Bob's website contains an XSS vulnerability. • Mallory crafts a URL to exploit the vulnerability and sends Alice a spoofed email which looks as if it came from Bob. • Alice visits Mallory's malicious URL while logged into Bob's website. • The malicious script embedded in the URL executes in Alice's browser as if it came directly from Bob's server. • The script steals sensitive information and sends this to Mallory's web server without Alice's knowledge. ** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scripting

10. Type 2: Persistent • Bob hosts a web site which allows users to post messages to the site for later viewing by other members. • Mallory notices that Bob's website contains an XSS vulnerability. • Mallory posts a message, controversial in nature, which may encourage many other users of the site to view it. • Other site users viewing the posted message can then have their session cookies or other credentials taken and sent to Mallory's webserver without their knowledge. • Later, Mallory logs in as other site users and posts messages on their behalf. ** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scripting

11. History of Exploits Amazing Legion of Fuzzy Backdoor Intruder Worms Rebecca Long

12. HotmailOctober 2001 • Allowed an attacker to steal a user’s Microsoft .NET Passport session cookie. • How? • Malicious code containing malformed HTML would be sent to a Hotmail user. • Hotmail’s filters would not recognize the HTML and fail to parse it out. • Internet Explorer was more than happy to read the malicious code.

13. GmailNovember 2004 • Gmail had an XSS vulnerability that gave a possible route for an attacker to gain full access to a user’s email account by just knowing their username. • Attacker can steal the user’s cookie file by using a hex-encoded XSS link who could then use it to identify him/herself as the original owner of the email account. • References: • http://www.securityfocus.com/news/9843 • http://net.nana.co.il/Article/?ArticleID=155025&sid=10

14. MySpace.comOctober 2005 • A XSS worm spread through MySpace.com affecting millions of users. • How? • MySpace user “Samy” placed JavaScript code in his profile. • When other users viewed the profile, the script initiated a background request (via AJAX) to add Samy to their friend’s list, bypassing the normal approval process. • Self-replicated itself into the other user’s profile. Thus, repeating the process on the newly infected profile. • Reference: • http://www.securityfocus.com/brief/18 • http://news.zdnet.com/2100-1009_22-5897099.html

15. CBS & BBC NewsAugust 2006 • A Russian site reported President Bush appointed a 9 year old boy to be the chairperson of the Information Security Department. • Claim was backed up by links to CBS News and BBC News which were both vulnerable to XSS holes allowing articles of the attackers choosing to be injected. • Reference: • http://www.securitylab.ru/news/extra/272756.php

16. Acrobat ReaderJanuary 2007 • Adobe Acrobat and Acrobat Reader 7 and prior on both Internet Explorer and Firefox are vulnerable to XSS allowing for JavaScript injection. • User interaction required by clicking on a link or just visiting a page that has a XSS PDF exploit. • Attacker can gain access of your session IDs for other sites (i.e. social networking sites such as MySpace). • Attacker is able to then tamper with your profile page to insure future access to your page and your friends’ pages. • Reference: • http://www.securityfocus.com/brief/401 • http://www.gnucitizen.org/blog/universal-pdf-xss-after-party/

17. Google DesktopFebruary 2007 • Vulnerability in Google Desktop could allow an attacker to use JavaScript to search and steal data from a user’s system. • Malicious JavaScript could be installed on the user’s computer that Google Desktop repeatedly will run giving the attacker ability to search the computer using terms most likely to dig up interesting information. • Reference: • http://www.securityfocus.com/news/11443

18. XSS for President • XSS Blog that shows XSS vulnerabilities on Presidential candidate websites. • http://xssblog.com/?p=4

19. In-Class Example Amazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith

20. Mitigation Amazing Legion of Fuzzy Backdoor Intruder Worms Allen Greaves

21. Mitigating • Filter characters • Convert evil characters to HTML • Authentication scripts • Check for malicious code

22. Mitigating • Client side mitigation • The client can turn off JavaScript • This limits the user

23. Mitigating • Noxes • Personal firewall application • Other firewalls are useless • All web connections pass through Noxes • Noxes allows user to block filth

24. Noxes • Allows user to create rules for filter • Manual Creation • Firewall Prompts • Snapshot mode • User has knowledge of every connection • Theoretical

25. Noxes • All statically embedded links are safe • No cookie being sent back • All local links are safe • Why steal a cookie for your own site? • Every link is given a temporary rule

26. Noxes • Evil server can still steal • Request cookie one byte at a time • Limit the number of domain requests • User specified • Pop-up attacks • Noxes injects it’s own JavaScript • Warns user if parent domain is different