50

There is a great list of XSS vectors avaliable here: http://ha.ckers.org/xss.html, but It hasn't changed much lately (eg. latest FF version mentioned is 2.0).

Is there any other list as good as this, but up to date?

Anders
  • 64,406
  • 24
  • 178
  • 215
naugtur
  • 1,095
  • 2
  • 12
  • 15
  • 4
    We need less cheatsheets/tools and more in-depth methodology manuals for findings issues such as XSS. It should also be noted that manual code review and control-based gap analysis are easier methods to find and eradicate XSS issues, especially over extremely large codebases and across a large number of applications. – atdre Nov 14 '10 at 12:55
  • 1
    @atdre, I agree - in principle. However, a missing control is often not enough for a business to decide to commit the resources to fix the lack. Indeed, risk management would require you to show if the flaw is exploitable, or just best-practice/defense-in-depth. – AviD Nov 14 '10 at 23:53
  • 1
    @AviD: Hahahahaha, XSS is always exploitable. I completely disagree with you. Demonstrating risk management issues through risk assessments is a total waste of time for application security! Does an organization need to practice the fine art of stealing their own trucks at gunpoint in order to prove the risk management issues with drivers going through bad neighborhoods, at night, with PR all over their location and truck contents? – atdre Nov 15 '10 at 01:27
  • I just noticed that my commentary here is a polemic argument. Please don't mark it as offensive – atdre Nov 15 '10 at 04:42
  • Heh, @atdre, I think that's a fair point - but not the one I was trying to make. Not that risk management should be done via risk assessments - but if you've done risk assessment/pentest/control analysis and found certain issues, how do you know if this is high risk, or low risk? If it's exploitable, thats how. Quite simply, if its not exploitable it does not affect the risk. Also, so called "cheat sheets" CAN be used as a form of (lightweight) methodology, since one of the main parts is the different vectors that should be tested - it's not just a question of payload. – AviD Nov 15 '10 at 07:02
  • And, more specifically - not that XSS is always exploitable, but lack of XSS prevention or finding a lack of validation/encoding in the code, does not automatically mean there is exploitable XSS. – AviD Nov 15 '10 at 07:17
  • 1
    Looks like I missed out a lot through the weekend :) A word from me - I consider such cheat-sheets useful for `learning what should I look out for when coding`. And I don't have to be a blackhat to want to try and exploit an app without code review. (eg. an app written in my company, but in a language I'm not familiar with) – naugtur Nov 15 '10 at 09:55
  • @ AviD: Missing a data or risk classification, you might want to assign risk ratings. But aren't data and risk classifications usually present? And if they are not, perhaps other kinds of risk management information should be available (another gap analysis project) such as incident history, or proper app forensics? – atdre Nov 15 '10 at 10:01
  • @ AviD: I would define exploitable XSS as any HTMLi, Script injection, or even CSSi -- doesn't matter if it's HTTP layer or not – atdre Nov 15 '10 at 10:02
  • @atdre, the issue I was drawing your attention to, is that a missing XSS-prevention control does NOT necessarily mean that there IS XSS. Same thign with code review, you might find unvalidated input, but that does NOT mean that there is in fact XSS. Why not? Because there are many different contexts, where injected script might not be executable, or its mistranslated, or or... On the other hand, an EXISTING control, or finding anti-XSS validation methods in the code, STILL might not mean there is NOT xss. Why not? Again, there are many ways to bypass this, depending on the context. – AviD Nov 21 '10 at 07:02
  • @AviD: any user controllable HTML element attribute is XSS, even if it's only HTMLi or CSSi. If content from input is being reflected, you need anti-XSS controls -- and to me at least, pen-testing and code review is a waste of time following this finding -- go straight to appsec controls, do not collect $200 – atdre Nov 22 '10 at 00:44
  • @atdre, what about user-controllable data that is NOT an HTML element? what about meta tag, using data: scheme? What about *partially* controllable data (i.e. there is an incomplete filter)? In short there are many edge cases where it is not so clear. – AviD Nov 22 '10 at 05:44
  • @AviD: Well that's exactly my point. You are making my argument for me. Thanks! I win! Where's my score.ly points? – atdre Nov 22 '10 at 06:08
  • Every app has XSS. Whois has XSS – atdre Nov 22 '10 at 06:09
  • No, @atdre, its the other way round. Whether you have the control or not, is not the deciding factor if it is exploitable or not. You might **not** have the control, and yet *not* be exploitable; or you might **have** the control, but because of *implementation*, it **is** exploitable. Simply having a checkmark next to "XSS Control" on a some checklist is not going to protect you. – AviD Nov 22 '10 at 06:11
  • Never said that an XSS control would work. Just said that it's the best place to start. Of course you have to verify that the control works. You test your controls, right? – atdre Nov 22 '10 at 06:37
  • Well, of course its a good idea to gather information ahead of time. But the XSS cheatsheet is used exactly for that - *to verify that the control works*. DING! I win, you made **my** point :) – AviD Nov 22 '10 at 07:48
  • And @atdre, NOT every app has XSS, only MOST of them. – AviD Nov 22 '10 at 07:48
  • So worry about that 30 years from now when you've eradicated XSS via appsec controls. You may win the war, but I win the battle. Oh wait, we're fighting the RBN? – atdre Nov 22 '10 at 08:28
  • Also: every app has XSS that could be displayed as HTML, XML, or a future markup language. Do you seriously want to have that argument? – atdre Nov 22 '10 at 08:29
  • How do I vote to cloce comments to this question? ;) – naugtur Nov 22 '10 at 15:00
  • 1
    Actually, @naugtur, I think the comments here are extremely helpful, possibly even more than the answers themselves - but then again, I might be biased. I think the back'n'forth I had with @atdre was topical, and of high value - but probably deserved its own question/discussion. But again, I'm probably biased :) – AviD Dec 06 '10 at 13:17
  • @AviD I posted it as a joke. It'd be nice if somebody could summarize it in an usable form ;) Most people will just skip the comments. – naugtur Dec 06 '10 at 14:34

5 Answers5

25

The best new one I've seen recently is here http://html5sec.org/ good list of vectors with browser support noted and has quite a few of the more obscure ones.

freddyb
  • 521
  • 3
  • 9
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 2
    Mario Heiderich is also releasing a book next month that should explore this and related topics more in-depth. Here is a link to the book: http://isbn.nu/1597496049 – atdre Nov 14 '10 at 12:53
  • I read the book. While some of its parts are already outdated, it's definitely a must-read if someone is into XSS, though it also covers other areas. – Krzysztof Kotowicz Sep 19 '11 at 13:19
12

If you really want to understand XSS, I strongly recommend OWASP's XSS Prevention Cheat Sheet. It's not focused on hacking, it's focused on helping developers prevent these problems in the first place. http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

planetlevel
  • 335
  • 1
  • 7
9

Yes, grab fuzzdb from http://code.google.com/p/fuzzdb/:

fuzzdb helps identify security flaws in applications by aggregating known attack patterns, predictable resource names, and server response messages to create a comprehensive, repeatable set of malformed input test cases.

fuzzdb has a great list of attack payloads.

Tate Hansen
  • 13,714
  • 3
  • 40
  • 83
3

RSnake's XSS cheatsheat (that you linked to) is still pretty much the definitive reesource, and it is even referenced in OWASP's secure coding guide (which is in turn referenced by PCI:DSS).
True, since RSnake is taking a step back from that stuff, going forward this might change, but as of now thats the place to go.

UPDATE: RSnake has officially retired from blogging, and declared that he won't be making any updates. So while this may have been up-to-date up until last month, apparently it's not anymore.

AviD
  • 72,138
  • 22
  • 136
  • 218
  • 2
    I think fuzzdb may supersede rsnake's xss cheatsheet given it is one of the primary sources for fuzzdb in addition to many other sources – Tate Hansen Nov 14 '10 at 23:50
1

There has been a newly available xss cheat sheet, it contains massive amount of vectors that work on all modern browsers.

LINK: http://packetstormsecurity.com/files/download/124419/WAF_Bypassing_By_RAFAYBALOCH.pdf

Danish
  • 11
  • 1