DOM XSS - Documentation

Question

DOM XSS - Documentation

Opened this issue 7 years ago · 5 comments

I think we need to make clear somewhere in the documentation clear that customers need to take additional steps for preventing DOM based XSS when using this library. Current documentation says about how to encode in direct CSS/HTML contexts but does not talk about how to encode when inserting Untrusted Data into HTML Subcontext within the Execution Context.

There are many such examples in [1] and I think its worth it to make a note of it somewhere in the documentation of this document.

[1] https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_then_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_HTML_Subcontext_within_the_Execution_Context

Answer 1 · 2018-03-29T20:25:38.000Z

This library is for encoding only. It does not do HTML sanitization. Also, DOM XSS is best defended against buy using safe JS API’s like .textContent (not escaping). You also need CSP. You should also consider HTTPOnly cookies. And the X-XSS-Protection header. So we’re not trying to address any of those other defenses; just encoding. Where do you propose we make it (more) clear this is for encoding only? Aloha, — Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

…

On Mar 29, 2018, at 12:44 PM, vikxcoder ***@***.***> wrote: I think we need to make clear somewhere in the documentation clear that customers need to take additional steps for preventing DOM based XSS when using this library. Current documentation says about how to encode in direct CSS/HTML contexts but does not talk about how to encode when inserting Untrusted Data into HTML Subcontext within the Execution Context. There are many such examples in [1] and I think its worth it to make a note of it somewhere in the documentation of this document. [1] https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_then_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_HTML_Subcontext_within_the_Execution_Context — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Answer 2 · 2018-03-29T21:01:04.000Z

Yup, I get that.

I am just thinking that people would assume that using this library properly (ie.., using right encoding function) would help them in mitigating against all sorts of XSS attacks including DOM. In fact, home page [1] says - "This project will help Java web developers defend against Cross Site Scripting!". Even you use all the context sensitive functions correctly, you might still be vulnerable to XSS according to OWASP DOM based prevention wiki as we need to encode for HTML first and then for JS next for few situations. I propose we make this clear either on the homepage.

[1] https://www.owasp.org/index.php/OWASP_Java_Encoder_Project

Answer 3 · 2018-03-29T22:07:17.000Z

I’ll add some notes to the wiki about this topic over the weekend. Good call. Aloha, -- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

…

On Mar 29, 2018, at 2:01 PM, vikxcoder ***@***.***> wrote: Yup, I get that. I am just thinking that people would assume that using this library properly (ie.., using right encoding function) would help them in mitigating against all sorts of XSS attacks including DOM. In fact, home page [1] says - "This project will help Java web developers defend against Cross Site Scripting!". Even you use all the context sensitive functions correctly, you might still be vulnerable to XSS according to OWASP DOM based prevention wiki as we need to encode for HTML first and then for JS next for few situations. I propose we make this clear either on the homepage. [1] https://www.owasp.org/index.php/OWASP_Java_Encoder_Project — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Answer 4 · 2018-04-09T09:59:00.000Z

Warning has been added! https://www.owasp.org/index.php?title=OWASP_Java_Encoder_Project&type=revision&diff=239490&oldid=236044

…

On 3/29/18 10:01 PM, vikxcoder wrote: Yup, I get that. I am just thinking that people would assume that using this library properly (ie.., using right encoding function) would help them in mitigating against all sorts of XSS attacks including DOM. In fact, home page [1] says - "This project will help Java web developers defend against Cross Site Scripting!". Even you use all the context sensitive functions correctly, you might still be vulnerable to XSS according to OWASP DOM based prevention wiki as we need to encode for HTML first and then for JS next for few situations. I propose we make this clear either on the homepage. [1] https://www.owasp.org/index.php/OWASP_Java_Encoder_Project — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAgcCaDwxECGgbWfGaSlr2VG_CanyZKYks5tjUuQgaJpZM4TA4fa>.

Answer 5 · 2018-04-09T10:07:48.000Z

Assuming the warning is enough, I'm closing this out for now.