Presentation on theme: "Cross-Site Scripting CSCD 498/539 Secure Coding Principles Amazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith Allen Greaves Zach Moore Rebecca."— Presentation transcript:
Cross-Site Scripting CSCD 498/539 Secure Coding Principles Amazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith Allen Greaves Zach Moore Rebecca Long
Introduction & Overview Amazing Legion of Fuzzy Backdoor Intruder Worms Zachary Moore
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.
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: 1) 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. 2) It's not even typically cross-site based. Some versions of this exploit depend on injected code only, not another site.
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.)
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.
Type 1: Non-Persistent 1) Alice often visits a particular website hosted by Bob where Alice can log in and store sensitive information. 2) Mallory observes Bob's website contains an XSS vulnerability. 3) Mallory crafts a URL to exploit the vulnerability and sends Alice a spoofed email which looks as if it came from Bob. 4) Alice visits Mallory's malicious URL while logged into Bob's website. 5) The malicious script embedded in the URL executes in Alice's browser as if it came directly from Bob's server. 6) 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_scriptinghttp://en.wikipedia.org/wiki/Cross_site_scripting
Type 2: Persistent 1) Bob hosts a web site which allows users to post messages to the site for later viewing by other members. 2) Mallory notices that Bob's website contains an XSS vulnerability. 3) Mallory posts a message, controversial in nature, which may encourage many other users of the site to view it. 4) 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. 5) Later, Mallory logs in as other site users and posts messages on their behalf. ** Example adapted from:http://en.wikipedia.org/wiki/Cross_site_scriptinghttp://en.wikipedia.org/wiki/Cross_site_scripting
History of Exploits Amazing Legion of Fuzzy Backdoor Intruder Worms Rebecca Long
Hotmail October 2001 Allowed an attacker to steal a users Microsoft.NET Passport session cookie. How? Malicious code containing malformed HTML would be sent to a Hotmail user. Hotmails filters would not recognize the HTML and fail to parse it out. Internet Explorer was more than happy to read the malicious code.
Gmail November 2004 Gmail had an XSS vulnerability that gave a possible route for an attacker to gain full access to a users email account by just knowing their username. Attacker can steal the users 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
CBS & BBC News August 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
XSS for President XSS Blog that shows XSS vulnerabilities on Presidential candidate websites. http://xssblog.com/?p=4
In-Class Example Amazing Legion of Fuzzy Backdoor Intruder Worms Bryan Smith
Mitigation Amazing Legion of Fuzzy Backdoor Intruder Worms Allen Greaves
Mitigating Filter characters Convert evil characters to HTML Authentication scripts Check for malicious code
Mitigating Noxes Personal firewall application Other firewalls are useless All web connections pass through Noxes Noxes allows user to block filth
Noxes Allows user to create rules for filter Manual Creation Firewall Prompts Snapshot mode User has knowledge of every connection Theoretical
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