Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have been a developer and now I am trying to look at XSS from the point of view of a developer. I was thinking of a particular case of reflected XSS . Let us say we have a vulnerable website and if an attacker can trick the users to click on a malicious link he can get their session tokens by using document.cookie

I was wondering that if the website starts to use http-only cookies (I suppose this will make it impossible to access the session tokens by the use of JavaScript. Am I missing out a point?) but still remains vulnerable to script injection in such a case what are the options left for the attacker? What are the other ways of exploiting this vulnerability?

share|improve this question

1 Answer 1

up vote 9 down vote accepted

There are two major attack patterns that can be explored by an attacker armed with an XSS vulnerability that affects an application that uses HTTPOnly cookies.

First and foremost an attacker can use an exploitation method similar to the Sammy worm. In this attack pattern the XSS payload uses an XMLHttpRequest to read a CSRF token and perform an action as if they where the victim. Common actions would be, adding a new administrative user, changing your password (or email address to perform a password reset) or even transfer funds. Any action that the authenticated session can perform, you should be able to perform with JavaScript by reading CSRF tokens.

The second attack is leveraging a trusted domain. Lets say the target is https://sometrustedbank.com. That HTTPS looks pretty shinny to informed users, but an attacker can modify any content on this page by assigning document.body.innerHTML to any value. An attacker could conduct a very convincing phishing attack where by a helpless victims are directed to https://sometrustedbank.com and asked to divulge personal information (and deep dark secrets). In this case the content is king, and a user is unaware that this content originates from an attacker.

In short enable HTTPOnly Cookies, but know that this security feature was never indented to stop XSS.

share|improve this answer
    
Besides that, I believe you can bypass HTTPOnly attribute if you forget to remove 'TRACE' HTTP method. jeremiahgrossman.blogspot.com.es/2007/04/… –  dgarcia Jul 25 '13 at 7:28
    
@dgarcia There was also a bypass that involved overly long cookies, which caused Apache to throw an error, and the error message contained the entire cookie. I think all of these issues have been fixed. –  Rook Jul 25 '13 at 16:54
1  
This issue maybe? –  dgarcia Jul 25 '13 at 17:11
1  
@dgarcia Yeah, that is the exploit I was thinking of. Looks like it was patched last year. Anyway, you should be able to perform any action using JS, that you would perform using a hijacked session token. –  Rook Jul 25 '13 at 17:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.