[Owasp-leaders] OWASP DOM based XSS definition, which looked a little off

Dave Wichers dave.wichers at owasp.org
Sun Oct 27 15:55:08 UTC 2013


All,

 

Thanks everyone for the great discussion on this on topic. I had a crazy week this week so haven’t had a chance to jump in until now. I’ve been thinking really hard about exactly this terminology problem since early last year, which is why this email is so long. And for those of you who don’t care about XSS terminology, you can stop reading now :-)

 

Last year, I was able to deliver three versions of my talk:  “Unraveling some of the Mysteries around DOM Based XSS”

 

At 3 different OWASP Conferences:

 

2012 AppSec DC: https://www.owasp.org/images/f/f4/ASDC12-Unraveling_some_of_the_Mysteries_around_DOMbased_XSS.pdf 

2012 AppSec Europe: https://www.owasp.org/images/3/30/AppSecEU2012_DOM-based_XSS.pdf 

2012 AppSec USA: https://www.owasp.org/images/c/c5/Unraveling_some_Mysteries_around_DOM-based_XSS.pdf

 

In my first talk, I talked about ‘traditional’ vs. DOM based XSS, and acknowledged there could be both Stored and Reflected versions of both. But the use of ‘Traditional’ seemed like a weak term to me.

 

So, I started an email discussion in early summer 2012 with Amit Kline, Mario Heiderich, Stefano DiPaolo, Arshan Dabirsiaghi, and other XSS researchers and proposed a new term: Server XSS – where ‘Server XSS’ occurs when untrusted user supplied data is included in an HTML response generated by the server. In that discussion, I asked Amit (who coined the original term DOM Based XSS) if he thought it reasonable to adjust the definition of DOM Based XSS to consider any Client Side XSS issue, where client side XSS means: Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript (or other browser side scripting language) call.

 

Amit said that he considers it DOM XSS only when the data comes from, and never left, the browser, e.g., the classic DOM XSS example of: http://www.some.site/page.html#name=xss_attack_here?name=safe_input_here), but this would not be considered a DOM XSS: http://www.some.site/page.html?name=xss_attack_here, since the attack script goes to the server. According to Amit, DOM XSS doesn’t include situations where data goes from the browser to the server, and then back to the browser (e.g. via an AJAX call), and then JavaScript grabs that data, and updates the DOM with it unsafely, introducing an XSS. I originally didn’t agree, but who am I to redefine a term invented by someone else J. I then realized that trying to redefine an existing term might be confusing anyway, so it is probably actually better not to try. So, instead, I proposed using the term Client Side XSS to define the general case where JavaScript was being used to update the DOM unsafely, and that term doesn’t care about the source of the data, or what it passed through, so it encompasses both DOM Based XSS, and XSS where the data comes from the server.

 

I made this proposal back to the people participating in my email discussion in mid-2012 and also started using the terms Client XSS and Server XSS in my next 2 DOM Based XSS presentations at OWASP AppSec EU and USA. But, then I got distracted by other things and it wasn’t until OWASP AppSec EU 2013 in Germany that I got a chance to sit down (actually standing up drinking beer with J) Mario and Eduardo Alberto Vela Nava (who is another XSS research guru, who works for Google) and we agreed to move forward with these new terms. In August, I wrote a short article pulling all this together, but then never pulled the trigger on actually publishing it. So now I have (see below).

 

I wanted to respond to some of the specific comments on this thread first:

 

·         Serg – THANKS!! For bringing this topic up, and starting the discussion. I absolutely agree that XSS terminology today is confusing, hence my proposal.

·         Most of the discussion has generally aligned with my proposal so I’m not going to specifically comment on most responses.

·         Erlend – I believe the terminology you heard regarding Server side vs. Client side XSS from Stefano is based on the email discussions we have had on this topic starting in mid 2012. Your chart: http://erlend.oftedal.no/blog/research/xss/index.html is almost identical to what I propose except DOM based XSS is a subset of both Stored and Reflected Client Side XSS. You can have Client Side XSS that is NOT DOM based, because the data came from the server, rather than staying only in the DOM.

·         Tobias – You have used the same terms as I have, but not all client side XSS is DOM based, per above.

·         Colin Watson – Colin, I have only the deepest respect for you, so it hurts me to disagree with your suggestion: “For completeness, are we happy that JavaScript injection into server-side application code (e.g. node.js) is best described as "command injection" and not any sort of XSS?” I think any time we are seeing JavaScript injected into the web app environment, and it ultimately gets executed in the victim’s browser, it should be called XSS, to avoid confusion. It’s possible that I don’t properly understand your scenario here. I think you are indicating that the attacker uploaded .js files or code to the server, and then the server served that .js? I know that’s not traditional XSS where we are injecting snippets, but why wouldn’t we still call that XSS?

·         Giorgio Fedon’s comment about focusing on defenses around the sink, rather than the source of the data is SPOT ON! We don’t ignore the source (stored or reflected) because that has a significant impact on the likelihood of a successful attack, but it generally doesn’t have much to do with the easiest/most straightforward ways to defend against the problem.

 

Anyway, I have finally published my article on suggested terminology for XSS that is inclusive of the existing definitions of Stored, Reflected, DOM Based XSS without redefining or changing them, and adds two new terms, Server XSS and Client XSS that focuses on where the actual code that is running introduces the XSS problem.

 

This article is now at: https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting

 

The article is long enough that I thought repeating it in this email, was unnecessary. I included some acknowledgements in there to give people a sense that a significant portion of the research community agrees with this to help it get critical mass/adoption. I’m happy to remove that section once we feel we are all good with this and want to adopt/use these terms at OWASP going forward.

 

Once we do agree, there are lots of places on the OWASP wiki to update to match, like most/all of the other XSS articles it references, as well as the OWASP Top 10, probably all the guides, etc.

 

Please review and let me know what you think.

 

Thanks, Dave

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20131027/8500ba27/attachment.html>


More information about the OWASP-Leaders mailing list