Application Security: Internet Explorer and Cross Site Scripting

Cross site scripting (aka XSS) is one of the most prevalent web application security issue. In OWASP top 10 for 2010, cross site featured prominently in number 2.

Considering the damage that a successful cross site scripting attack is capable of doing, almost all the successful commercial browsers have tried to provide security features that makes it difficult to execute a successful cross site scripting attack. One of the main ways this attack is carried out is by exploiting the browser’s capability for executing scripts.

Starting Internet Explorer 6 SP1, a new attribute is introduced to the cookies to counter the menace of XSS.

This attribute makes the cookie inaccessible to the scripts, thus stopping malicious script code from executing. The cookies with this attribute set are called HTTP only cookie.

A cookie is set on the client with an HTTP response header.

Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]

The HttpOnly attribute is not case sensitive and it is important to be noted that this feature must be used in coordination with other XSS mitigation to effectively counter XSS, like:

1. Proper input validation.

2. Adequate output encoding whenever any possible user controlled values are rendered back to the browser.

Advertisements

Silverlight TextBlock and XSS

I am learning Silverlight, particularly the security perspective, and I created a dummy project. The project greets the user with a login screen and once the user provides the credentials he is redirected to another page and the user sees a Welcome note saying “Welcome “.

I assigned a script in the user name field and expected to see an nice little alert when the user is navigated to the next page but I saw this instead:

I am disappointed on seeing this and looked for why this text is not parsed and rendered by the browser. In the approach the syntax TextBlock.Text understands the string is to be displayed rather than parsed and run as markup/code and hence this cannot be exploited for Cross Site Scripting.
I did not know that and thought its worth noting it down here.

Cross Site Scripting – PART 1

Hi there…I have been looking around for XSS related information and most of the demos I saw are either around displaying an alert in a web page or too advanced for a beginner like me. So as a toddler in the security world I tried to create my own dummy application to see how this attack is executed. What I write below is a documentation of my learning: there may be faults as I am still learning.

So feel free to drop a comment incase anything is not correct, I will surely incorporate any suggestions.

Cross Site Scripting – A little exploit demo to help understand the basics of this attack – I

Application background:

1. We have a simple web forum that uses Form based authentication.
2. The users can comment on the topics discussed by other users.
3. New users visiting this site are required to register by creating a new user name and password.
4. A registered user can: view/write the posts, write comments on the posts and view the comments written by other users.
5. The following code snippet is added to the web.config file for this application. Please note that when request validation is disabled, any content can be submitted to a page; it is the responsibility of the page developer to ensure that content is properly encoded or processed.

Use Scenario:
1. A malicious user registers and logs in to the forum.
2. He picks a topic and clicks on Write comments. Here is what he writes and submits:

This comment will appear as below on the view comments page:


To a normal user this looks like a perfectly harmless piece of text that directs you to another location that has more information around, eh…well Cross Site scripting exploit!
So a good user (let’s call him GoodUser) logs in and clicks on the hyperlink “here” to get some more information around this type of exploits. Here is what he will see:

In our example we used a simple alert statement but in real world scenarios this can contain scripts that can steal your cookie, other important information, etc. These stolen information can be used to impersonate a user, launch a more knowledgeable attack on the application or its user and also can case loss of data that can have financial and reputational implications on both the end user as well as the web site owner.

Hope someone will find this useful to understand how XSS can be exploited. I will posting my rendezvous with XSS.

Happy Reading!