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

Colin Watson colin.watson at owasp.org
Sun Nov 3 09:32:05 UTC 2013


Dave

Apologies for the delay in replying.

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

I am sorry, my interjection was brief and not well explained. I meant
JavaScript injection on the server that affects web servers executing
themselves:

   node.js in http://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_Slides.pdf
   A1 on http://erlend.oftedal.no/blog/?blogid=126

I meant these are not XSS, and shouldn't be mixed up.

Colin





On 27 October 2013 15:55, Dave Wichers <dave.wichers at owasp.org> wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>


More information about the OWASP-Leaders mailing list