In this post, I decided to dissect two common security vulnerabilities that exist on the web and along the way highlight some browser security model intricacies.

CSRF (Cross Site Request Forgery) can be explained with a simple example as follows:

1. User visits a malicious website M.

2. M embeds an image tag on its page, that invokes, say, a URL that transfers money to another account from the user’s account. If the user was logged into his bank account when he loaded M’s page, the transfer would happen.

Of course, this is a contrived example of using GET requests, usually these things are done via embedded forms and via POST requests which still works. One may ask, how can a page from one domain post to a different domain, isn’t it cross domain? Surprisingly, this is possible. What is not possible is javascript posting cross domain.

How do you prevent such a CSRF attack? One way is to embed some data in the FORMs, like a hidden parameter and verify the presence of it when the form is received on submission. This will ensure only forms generated by the site, bank – in this case, will be accepted.

XSS (Cross Site Scripting) can be explained with an example as follows:

There exists a website V which reflects the input parameters as is on the web pages. For example, V spits out any javascript that is passed as input.

1. A malicious user crafts a URL to V with javascript in the input that injects a js file from a malicious website.

2. The URL is sent to the targetted user via email or through other means.

3. When the user clicks the URL,  the reflected javascript is executed which in turn loads the js file from the malicious website. This js file executes and sends any sensitive data on the page such as authentication cookie to the malicious user who then has access to the targeted user’s account by copying the authentication cookie to his browser.

You may ask, how can a js file downloaded from a third party site have access to V’s DOM or page, isn’t it cross domain which is not allowed? No, this is allowed as the js download request was on the page downloaded from V. This is how things like optimizely or CDNs work, the script downloaded from optimizely or CDNs can modify content on the page downloaded from V.

How do we prevent XSS? Simple, clean up any suspicious input such as javascript, SQL, etc. from user supplied inputs and do not reflect them back on the rendered page.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s