xss injection vulnerabilities
DESCRIPTION
This presentation explores on how to test Cross site scripting Injection Vulnerabilities, prevention, Best practice, small lab(introduction to web goat) etc.TRANSCRIPT
XSS
Cross site scripting
Pankaj Dey,Mindfire
Who knows XSS?
What is cross site scripting
XSS is a vulnerability that allows an attacker to run arbitrary
JavaScript in the context of the vulnerable website
Traditional XSS
Is XSS Dangerous?
Big Yes.(OWASP Top 2)Just think, any JavaScript
you want will be run in the victim’s browser in the context
of the vulnerable web page
what can you do with JavaScript?
what can you do with JavaScript?
Pop-up alerts and prompts
1. Access/Modify DOM
2. Access cookies/session tokens
3. “Circumvent” same-origin policy
Virtually deface web page
Detect installed programs
Detect browser history
Capture keystrokes (and other trojan functionality)
Port scan the local network
Induce user actions…………………So on..
Types of XSS
• Reflected XSS
• Stored XSS (a.k.a. “Persistent XSS”)
• DOM Based XSS
Reflected XSS
Exploit URL:
http://www.nikebiz.com/search/?q=<script>alert('XSS')
</script>&x=0&y=0
HTML returned to victim:
<div id="pageTitleTxt"> <h2><span
class="highlight">Search Results</span><br />
Search: "<script>alert('XSS')</script>"</h2>
Stored XSS
JavaScript supplied by the attacker is stored by the website (e.g. in a
database)
Doesn’t require the victim to supply the JavaScript somehow, just visit the
exploited web page
More dangerous than Reflected XSS
Has resulted in many XSS worms on high profile sites like MySpace and
DOM Based XSS
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS
attack wherein the attack payload is executed as a result of modifying the
DOM “environment” in the victim’s browser used by the original client side
script, so that the client side code runs in an “unexpected” manner
https://www.owasp.org/index.php/DOM_Based_XSS
Webgoat
Tools we need..
XSS-Proxy - http://xss-proxy.sourceforge.net/
ratproxy - http://code.google.com/p/ratproxy/
Burp Proxy - http://portswigger.net/proxy/
OWASP Zed Attack Proxy (ZAP) - OWASP_Zed_Attack_Proxy_Project
HackVertor - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
PHP Charset Encoder(PCE) - http://h4k.in/encoding [mirror: http://yehg.net/e ]
https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework
DOM Based XSS tools
Limitations
Often fail to test a substantial fraction of a web
application’s logic ..
Especially when this logic is invoked from pages that can
only be reached after filling out complex forms that check
the correctness of the provided values.
Testing guide
Black Box testing
1. Detect input vectors.
2. Analyze each input vector to detect potential vulnerabilities. XSS Filter
Evasion Cheat Sheet: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
3. For each test input attempted in the previous phase, the tester will
analyze the result and determine if it represents a vulnerability that has a
realistic impact on the web application's security.
Gray Box testing
Gray Box testing is similar to Black box testing with partial knowledge of the
application.https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP-DV-001)
Script. Where it can be executed..!!
<a href="javascript#[code]">
<div onmouseover="[code]">
<img src="javascript:[code]">
[IE] <img dynsrc="javascript:[code]">
[IE] <input type="image" dynsrc="javascript:[code]">
[IE] <bgsound src="javascript:[code]">
&<script>[code]</script>
[N4] &{[code]};
[N4] <img src=&{[code]};>
<link rel="stylesheet" href="javascript:[code]">
[IE] <iframe src="vbscript:[code]">
[N4] <img src="mocha:[code]">
[N4]<img src="livescript:[code]">
<a href="about:<script>[code]</script>">
<meta http-equiv="refresh"
content="0;url=javascript:[code]">
<body onload="[code]">
<div style="background-image:
url(javascript:[code]);">
[IE] <div style="behaviour: url([link to code]);"> [Mozilla] <div style="binding: url([link to code]);">[IE] <div style="width: expression([code]);">[N4] <style type="text/javascript">[code]</style>[IE] <object classid="clsid:..."
codebase="javascript:[code]"><style><!--</style><script>[code]//--></script><![CDATA[<!--]]><script>[code]//--></script><!-- -- --><script>[code]</script><!-- -- --><<script>[code]</script><img src="blah"onmouseover="[code]"><img src="blah>" onmouseover="[code]"><xml src="javascript:[code]"><xml d="X"><a><b><script>[code]</script>;
</b></a> </xml><div datafld="b" dataformatas="html"
datasrc="#X"></div>[UTF-8; IE, Opera] [\xC0][\xBC]script>[code][\xC0][\xBC]/script>
Developer Guide
Validate OutputEncode HTML Output
If data came from user input, a database, or a file
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));
Not 100% effective but prevents most vulnerabilities
Encode URL Output
If returning URL strings
Response.Write(HttpUtility.UrlEncode(urlString));
How To: Prevent Cross-Site Scripting in ASP.NET http://msdn.microsoft.com/en-us/library/ms998274.aspx
XSS Prevention Cheat Sheet:http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_
Cheat_Sheet
How to safely render untrusted data
Conclusion
XSS vulnerabilities are bad.
Don’t satisfy with black box scanner.. Hacker
don’t.
Avoid introducing XSS vulnerabilities in your
code.
Beware while clicking on a phishing link..
