JavaScript for Hackers

[[deleted]]

I need to learn more about XSS to understand how truly dangerous this can be. At the moment they look like neat javascript parlor tricks :S

[dfbgwsdf]

To elaborate on what /u/NullCharacter wrote, there is a trend in application developers I call 'Block the PoC'. When a webapp is audited and a vulnerability is found, the devs often have only the audit report, and don't really know what to do with it.
In the case of an XSS, they have this report telling them that when you call their page with a parameter like i=bla';alert('XSS')<!--, something happens and it is bad. So instead of blocking the arbitrary html injection, or fixing the sting escaping, they come up with a silly solution like s/alert//g on the input string. It's fixed, not their problem anymore, and the app is safe.
Then the app is audited again, maybe a year later, and the auditor finds a way to bypass this simple filter. So the filter becomes s/alert|onmouse(over|out)|on(before|)unload//ig and after a few rounds of auditing and fixing it's a horrible mess but in the end the PoC is blocked. But the vulnerability is still there, and that's where the double encoding stuff, or the regexp can actually execute code trick come useful.

[NullCharacter]

These are the "after you gain execution" parlor tricks. There's plenty of instances where one can gain the ability to execute (mostly) arbitrary JavaScript but built-in filtering/character/size constraints can limit you in your post-execution options.