5

I am going through the WebGoat exercises, to refresh my knowledge of XSS attacks.

Specifically, I am doing the Stage 1 XSS exercise. This exercise has a form that deliberately does not sanitize input. The solution video shows using the JavaScript alert function to put out a message and the session cookie.

Stage 3 has a built in XSS code snippet, that upon viewing a profile will show the contents of 'document.cookie'.

In any modern browser, all without any add-ons, I cannot get this to execute. I can generate messages using JavaScript alert, but it never prints the contents of document.cookie

The tutorial on this page for get cookies shows that it is possible to print the contents of document.cookie in a JavaScript alert message.

What I would like to know is why I can't do the same in a very simple, deliberately vulnerable to XSS web application. Is there some XSS detection in all modern browsers preventing this? I've tried with he options to disable web security on IE, Firefox and Chrome and it makes no difference.

enter image description here

edit: Things I have tried for both WebGoat 5.4 and WebGoat 6.0.1:

  • Accessing via Firefox with a new, default profile and no addons
  • Chrome with the --disable-web-security and/or –disable-xss-auditor arguments
  • Accessing via Mantra
  • Setting the X-XSS-Protection header to 0 in my requests.

Is WebGoat trying to teach about an XSS attack that is no longer a threat?

2nd edit:

Per Martin's answer, I tried setting the header manually as seen in the screenshots below. I modified the lesson title so it is obvious fiddler is correctly intercepting the page.

enter image description here enter image description here

The cookie is not set as secure3 or httponly, but refuses to be read from any browser via JavaScript, via bookmarklet or Scratchpad. The cookie is set correctly in the browser and is viewable in the browsers cookie dialogs.

What property of this cookie is preventing it from being read?

  • Do you use the developer version of webgoat? I ask since there is this blue text that states that it won't work with any other version. – Denis Mar 2 '15 at 5:37
  • @Denis, that text is for the Stage 4 lessons, not the stage 3 lesson which it says I completed, and does not have the blue warning text. However, I have tried with both the stable and developer versions, and there was no difference in how the javascript alert behaved. – Sonny Ordell Mar 2 '15 at 5:50
  • Ah I see, my fault. Have you tried to put an "alert(document.cookie)" into the JavaScript browser console directly. That would show if the cookie or the application is responsible. – Denis Mar 2 '15 at 7:36
  • 1
    Looks like there are no cookies to display. Check this with a browser add-on for viewing cookies. Also, X-XSS-Protection is a response header, not a request header, IIRC. – Mints97 Mar 2 '15 at 8:14
5
+50

Setting the X-XSS-Protection: 0 header is the correct solution, but you have to add this header in the response, not in your request. Steps:

  • Make sure you have an actual cookie which is not secured with the HTTP-only flag. (You can edit the JSessionID cookie for example)
  • Use a correct JS command to retrieve the cookie (test it first in console), for example: var a=document.cookie;alert(a) (note: if you have multiple cookies, you will have to split them, I assume you only have the JSESSIONID cookie)
  • Store the command in the street field, with script tags: var a=document.cookie;alert(a) (Stackoverflow hides the script tags, make sure you add them)
  • Fire up Fiddler before saving. We will intercept the response and add the X-XSS-Protection:0 header in the response (if you have the developer version, you could probably add it in the source)
  • Intercept the response, edit the response headers, add the X-XSS-Protection:0 header, hit CTRL+S just to make sure, then hit 'run to completion'.
  • Et voilà

Update: screenshots for clarification.

  • Fiddler

*: Fiddler header

  • Webgoat result Webgoat
  • Did you try this? WebGoat simply gives an error when I itnercept and append this header. I tried with Fiddler, Burp and TamperData for Firefox – Sonny Ordell Mar 2 '15 at 9:44
  • Interestingly, I used a bookmarklet to view cookies on the webgoat page, which shows no cookies stored for the session. This bookmarklet to view cookies works on other sites such as stack exchange and amazon. The WebGoat JSESSIONID cookie is the only cookie and is not set to secure or httponly, so I don't see why the bookmarklet could not read it. – Sonny Ordell Mar 2 '15 at 9:45
  • @SonnyOrdell, yes I tried this with version 5.4. I'll add a screenshot of how I appended the header. – Michael Mar 2 '15 at 9:46
  • that is odd to me. Even using a bookmarklet to view the cookie doesn't show it. I have to wonder if it is a local issue I am having. – Sonny Ordell Mar 2 '15 at 9:48
  • By the way, I don't even need the header if I logout as Jerry and login again => view tom's profile.. Could you just create a cookie yourself? With some cookie add-on – Michael Mar 2 '15 at 9:48
4

Correct, the majority of mainstream browsers have now included built-in XSS protections. With regards to possible workarounds:

You can disable this feature in Chrome by starting the browser with the "disable-xss-auditor" switch. (i.e. C:\<PATH>\chrome.exe --args --disable-xss-auditor)

Another option is to set a header in the hosting web-server to disable such protections (Apache example below):

Header set X-XSS-Protection: 0

Finally, you could look to utilize a web application pen testing browser such as OWASP Mantra.

https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework

  • Ahh, nope. I tried each of those, to no avail. Maybe it is an error in WebGoat? – Sonny Ordell Feb 27 '15 at 16:43
  • I'd argue that this simple XSS case is still a prevalent issue. The XSS protections are just a safety-belt, not a real security control – says also a Google Security Engineer. – freddyb Mar 2 '15 at 14:45
0

Could you mention the XSS payload you used to print the contents of the cookie?
Also, generally speaking, in addition to the X-XSS headers, if a web application has the cookie flag set to HTTP-only, the contents of the cookie aren't available to client-side scripts such as a JavaScript snippet or your XSS payload, thereby printing an empty alert message like the screenshot you posted above.

  • The XSS payload is whatever WebGoat is using. The WebGoat lessons are designed to teach how XSS atacks, so the application is deliberately vulnerable so as to allow XSS attacks. The cookie is not set to HTTPOnly, as it is designed to be insecure. – Sonny Ordell Mar 2 '15 at 3:55
  • Well, reading the comments u most recently made, i was right about the cookie being HTTP-only and the first one to suggest it, right? Bounty? lol – Aatif Shahdad Mar 2 '15 at 16:03
  • Aatif you were the first to suggest it and I do appreciate your answer but I feel that Michael deserves it for delving into the issue as he did, and his comprehensive answer. If I could split the bounty up I would. – Sonny Ordell Mar 2 '15 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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