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

Erlend Oftedal erlend.oftedal at owasp.org
Sun Oct 27 16:40:41 UTC 2013

  Great article, Dave. I'm all for going forward with this terminology. Now
that you mention it, I remember you talking about client and server side
XSS in Germany.

Best regards,

Fra: Dave Wichers <dave.wichers at owasp.org>
Sendt: 27.10.2013 16:56
Til: owasp-leaders at lists.owasp.org
Emne: Re: [Owasp-leaders] OWASP DOM based XSS definition, which looked a
little off


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:

2012 AppSec Europe:

2012 AppSec USA:

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:
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

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:

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/69be0d95/attachment.html>

More information about the OWASP-Leaders mailing list