XSS Filter in IE 8.0

Finally Microsoft has come up an anti XSS security control in IE 8.0 (seen the news), which makes little tough for an attacker to exploit Reflected XSS (type 1), one of the most prominent vulnerability in the web based application. The feature I termed as “The XSS Filter”.

To give you a little brief about the type -1 XSS (reflected XSS)
Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a ‘trusted’ server.

Impact
Typical XSS exploits target the victim's cookies, transmitting them to the attacker so that the attacker can impersonate the victim on the vulnerable site. In general XSS allows attackers to execute script in the victim’s browser, which can Hijack user sessions Deface web sites, Insert hostile content, Conduct phishing attacks Take over the user’s browser One of the security software engineer (XSSFilter in IE8.0) who is working with IE 8.0 team has explained in detail about the functionality of XSS filter. XSS Filter -- How it Works The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing. With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following:









The page has been modified and the XSS attack is blocked. In this case the XSS Filter has identified a cross-site scripting attack in the URL. It has neutered this attack as the identified script was replayed back into the response page. In this way the filter is effective without modifying an initial request to the server or blocking an entire response.

Breaking a Visual CAPTCHA

It appears that spammers have found a way of automatically creating Hotmail and Yahoo email accounts, having already created more than 15,000 bogus Hotmail accounts, according to security company BitDefender.

Both Microsoft and Yahoo use “captcha” systems to stop email accounts from being automatically generated; accounts aren’t created until a new user correctly identifies letters depicted in an image. CAPTCHA systems are designed to ensure that the letters are not easily recognized by machines.

I came across a very good article which talks about the ways to break CAPTCHA by Greg M and Jitendra M

Summary
This is the homepage of the Shape Contexts based approach to break Gimpy, the CAPTCHA test used at Yahoo! to screen out bots. Our method can successfully pass that test 92% of the time. See EZ-Gimpy in action at Yahoo! The approach we take uses general purpose algorithms that have been designed for generic object recognition. The same basic ideas have been applied to finding people in images, matching handwritten digits, and recognizing 3D objects.

Background
A CAPTCHA is a program that can generate and grade tests that: Most humans can pass, but
Current computer programs can't pass.CAPTCHA stands for "Completely Automated Public Turing test to Tell Computers and Humans Apart". See the CAPTCHA site for more details. The concept of a CAPTCHA is motivated by real-world problems faced by internet companies such as Yahoo! and AltaVista. These companies offer free email accounts, intended for use by humans. However, they found that many online vendors were using "bots", computer programs that would sign up for thousands of email accounts, from which they could send out masses of junk email. By requiring the user to solve a CAPTCHA, in the case of Yahoo the word-based one called EZ-GIMPY shown above, the "bots" could be screened out.

EZ-Gimpy and Gimpy, the CAPTCHAs that we have broken, are examples of word-based CAPTCHAs. In EZ-Gimpy, the CATPCHA used by Yahoo! the user is presented with an image of a single word. This image has been distorted, and a cluttered, textured background has been added. The distortion and clutter is sufficient to confuse current OCR (optical character recognition) software. However, using our computer vision techniques we are able to correctly identify the word 92% of the time.

Gimpy is a more difficult variant of a word-based CAPTCHA. Ten words are presented in distortion and clutter similar to EZ-Gimpy. The words are also overlapped, providing a CAPTCHA test that can be challenging for humans in some cases. The user is required to name 3 of the 10 words in the image in order to pass the test. Our algorithm can pass this more difficult test 33% of the time.

Our Approach
The fundamental ideas behind our approach to solving Gimpy are the same as those we are using to solve generic object recognition problems. Our solution to the Gimpy CAPTCHA is just an application of a general framework that we have used to compare images of everyday objects and even find and track people in video sequences.

The essences of these problems are similar. Finding the letters "T", "A", "M", "E" in an image and connecting them to read the word "TAME" is akin to finding hands, feet, elbows, and faces and connecting them up to find a human. Real images of people and objects contain large amounts of clutter. Learning to deal with the adversarial clutter present in Gimpy has helped us in understanding generic object recognition problems. Our related work on finding people and generic objects.
A high-level description of our method can be found here.
If you would like more details, see our paper from CVPR 2003.

Results
For EZ-Gimpy we did experiments using 191 images. We were able to correctly identify the word in 176 of these images: a success rate of 92%! Our algorithm takes only a few seconds to process one image. If your would like to see our results on all 191 images, please click here.

The more difficult version of the Gimpy CAPTCHA presents an image in which 10 words (some repeated), overlaid in pairs. The test-taker is required to list 3 of the words present in the image in order to pass.

The clutter in these images, real words instead of random background textures, is much more difficult to deal with. In addition, we must find 3 words instead of just one. Our current algorithm can find 3 correct words and pass this Gimpy test 33% of the time. Note that even if we could guess a single word correctly 70% of the time, we would only expect to get 3 words correct approximately 0.7*0.7*0.7 = 34% of the time. Moreover, given our 33% success rate, this CATPCHA would still be ineffective at filtering out "bots" since they can bombard a program with thousands of requests.

The algorithm we use is outlined in detail in our paper linked above. Check out our results on the the harder version of Gimpy.

Reviewing Code for Session Integrity issues

1 Introduction
2 How to locate the potentially vulnerable code
3 HTTP Only Cookie
4 Limiting Cookie Domain
5 Displaying Data to user from Cookie
6 Session Tracking/Management Techniques
- HTML Hidden Field
- URL Rewriting
7 Leading Practice Patterns for Session Management/Integrity


Introduction
Cookies can be used to maintain a session state. This identifies a user whilst in the middle of using the application. Session Id's are a popular method of idenfitying an ser. A "secure" session Id should be at least 128 bits in length and sufficiently random. Cookies can also be used to identify a user but care must be taken in using cookies. Generally it is not recommended to implement a SSO (Single Sign on) solution usign cookies, they were never intended for such use. Persistent cookes are stored on a user hard disk and are valid depending on the expiry date defined in the cookie. The following are pointers when reviewing cookie related code.

How to locate the potentially vulnerable code
If the cookie object is being set with various attributes apatrt from the session ID check the the cookie is set only to transmitt over HTTPS/SSL. In java this is perfromed by the method cookie.setSecure() (Java)cookie.secure = secure; .NET

HTTP Only Cookie
This is adhered to in IE6 and above... HTTP Only cookie is meant to provide protection agains XSS by not letting client side script accessing the cookie. Its a step in the right direction but not a silver bullet. cookie.HttpOnly = true (C#)
Here cookie should only be accessable via ASP.NET

Limiting Cookie Domain
Ensure cookies are limitead to a domain such as example.com. Therefore the cookie is associated to example.com. If the cookie is associated iwth other domains the following code performs this: Response.Cookies("domain").Domain = "support.example.com (VB)Response.Cookies["domain"].Domain = "support.example.com"; (C#)
During the review if the cookie is assigned to more than one domain make note of it and query why this is the case.

Displaying Data to user from Cookie
Make sure that data being displayed to a user from a cookie is HTML encoded. This mitigates some forms of Cross Site Scripting. LabelX.Text = Server.HtmlEncode(Request.Cookies["userName"].Value); (C#)
Session Tracking/Management Techniques

HTML Hidden Field
The HTML Hidden field could be used to perform session tracking. Upon each HTTP POST request the hidden field is passed to the server identifying the user. It would be in the form of
Server-side code is used to perfrom validation on the VALUE in order to ensure the used is valid. This approach can only be used for POST/Form requests.

URL Rewriting
URL rewriting approaches session tracking by appending a unique id pertaining to the user at the end of the URL.
Leading Practice Patterns for Session Management/Integrity
HTTPOnly Cookie: Prevents cookie access via client side script. Not all browsers support such a directive.

Valid Session checking:
Upon any HTTP request the framework should check if the user pertaining to the HTTP request (vis session ID) is valid.
Successful Authentication:
Upon a successful login the user should be issued a new session identifier. The old session Id should be invalidated. This prevents session fixation attacks and the same browser also sharing the same session ID in a multi user environment. SOme times the session Id is per browser and the session remains valid while the browser is alive.

Logout: This also leads to the idea of why a logout button is so important. The logout button should invalidate the users session Id when it is selected.