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?

Sonny Ordell
  • 3,476
  • 9
  • 33
  • 56
  • 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 02 '15 at 05: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 02 '15 at 05: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 02 '15 at 07: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 02 '15 at 08:14

3 Answers3

5

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
Michael
  • 5,393
  • 2
  • 32
  • 57
  • 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 02 '15 at 09: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 02 '15 at 09:45
  • @SonnyOrdell, yes I tried this with version 5.4. I'll add a screenshot of how I appended the header. – Michael Mar 02 '15 at 09: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 02 '15 at 09: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 02 '15 at 09:48
  • Michael, the tom and jerry users are used in stage 1, which works for me without the header is well. It is the Stage 3 lesson, 'Stored XSS revisited" which refuses to display a cookie for me. When you log in on the Stage 3 screen as Bruce, and view Bruce's profile, do you get an alert? – Sonny Ordell Mar 02 '15 at 09:53
  • So I just double checked. The cookies is definitely there, but It appears impossible to access, even using scratchpad in firefox. it isn't set to httponly or secure, so this is very strange. – Sonny Ordell Mar 02 '15 at 10:00
  • Yes, stage 3 works as well. I'll add the screenshots now. – Michael Mar 02 '15 at 10:07
  • After adding the header in Fiddler, be sure to hit CTRL+S, just to be sure, before running to completion. However, if you think it is a problem with your cookie, try adding another fake cookie.. – Michael Mar 02 '15 at 10:09
  • Strange, it isn't working for me, and I've done exactly as you describe. Intercepting HTTP requests isn't something new to me (I have Burp Pro), but this is stumping me. I made sure to set and save the header with Fiddler, and it still didn't work. The fact that it doesn't work even with a bookmarklet is strange as well. – Sonny Ordell Mar 02 '15 at 10:27
  • Michael, please see my updated screenshots in the question. – Sonny Ordell Mar 02 '15 at 10:30
  • It seems the cookie doesn't exist. Have you tried adding a dummy cookie? – Michael Mar 02 '15 at 10:38
  • The cookie does seem to exist though, there must be a bug somewhere. Setting a dummy cookie worked, but the webgoat cookie still shows in the browser and on the webgoat page which lists cookies (which also now lists my dummy cookie). – Sonny Ordell Mar 02 '15 at 10:42
  • And you are sure the cookie is not HTTP-only? Could you take a screenshot of the resources tab in chrome developer tools, with cookies localhost open? – Michael Mar 02 '15 at 10:45
  • Well, that is interesting. Looking at cookies.localhost in chrome, the cookie is marked as httponly. However, when monitoring traffic, the httponly tag does not seem to be set on cookie creation. Firefox also does not consider the cookie to be httponly, while Chrome does. I guess this looks like a question for stack overflow. – Sonny Ordell Mar 02 '15 at 10:54
  • @SonnyOrdell In my webgoat version, the HTTPONLY flag is set on cookie creation when opening the application: Set-Cookie: JSESSIONID=CADEDA114DCF2E29119DD39EDF832B9D; Path=/WebGoat/; HttpOnly – Michael Mar 02 '15 at 11:01
  • Yes, it definitely is. Well, that solves that. Thanks Michael. – Sonny Ordell Mar 02 '15 at 11:37
  • I'm not sure who to award the bounty to, as the actual issue is simply that the cookie was set to httponly, which is why the webgoat lesson fails. I'm unsure how you completed stage 3, since for me setting the header did not change anything. – Sonny Ordell Mar 02 '15 at 14:02
  • In my first step, I edited the cookie to be HTTP-only. – Michael Mar 02 '15 at 14:12
  • The header seems irrelevant, from what I can tell. If I prevent the cookie from being httponly, then the lessons work as intended without me having to set the header. The header does not allow the cookies to be accessed it the httponly flag is set. – Sonny Ordell Mar 02 '15 at 14:18
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

Schism
  • 107
  • 4
vaughank
  • 99
  • 4
  • 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](https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0419.html). – freddyb Mar 02 '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.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
racec0ndition
  • 581
  • 4
  • 10
  • 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 02 '15 at 03: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 – racec0ndition Mar 02 '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 02 '15 at 17:57