General questions - Core java library
Opened this issue · 10 comments
Deleted user commented
Hey Guys - Awesome work, keep it work!
-
[1] Rule#1 suggests that we also need to encode "/" character as it can be used to end HTML entity but it doesn't seem like java encoder does it any HTML context encoders. Is there a reason why you guys decided not to encode this specific character? If it is not necessary don't we need to update OWASP wiki?
-
[1] Rule#2 suggests that we need to encode characters like "%,*,......." for non-attributed characters but again I don't see them in forHtmlUnquotedAttribute function. IMO they don't break the context, so don't we need to change the OWASP wiki if it's not needed? or am I missing something here?
-
Why can't we just encode ( and ) characters in cssURL context and have only 1 function for CSS encoding? I don't see a reason why we need to have non-encoded ( and ) characters in cssURL?
Are you guys aware of any other enterprises using this library?
A quick response will be highly appreciated :) ..
[1] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
jmanico commented
vikxcoder,
I just wanted to not that we got your requests and will respond in more
detail at a later time.
Aloha, Jim
…On 3/2/18 5:00 PM, vikxcoder wrote:
Hey Guys - Awesome work, keep it work!
1.
[1] Rule#1 suggests that we also need to encode "/" character as
it can be used to end HTML entity but it doesn't seem like java
encoder does it any HTML context encoders. Is there a reason why
you guys decided not to encode this specific character? If it is
not necessary don't we need to update OWASP wiki?
2.
[1] Rule#2 suggests that we need to encode characters like
"%,*,......." for non-attributed characters but again I don't see
them in forHtmlUnquotedAttribute function. IMO they don't break
the context, so don't we need to change the OWASP wiki if it's not
needed? or am I missing something here?
3.
Can you help me in getting a couple of strong "code examples" on
why context sensitive based encoding needs to be done? and why
HTML encoding alone won't help in those cases?
I know that it can help for unquoted attributes but for now let us
assume that entire world is using quoted attributes [I know its
impossible but just let's assume :/], can you help me in providing two
more examples where HTML encoding will not help and lead to XSS
attacks which would be protected if we had used context-sensitive
encoding?
4. Why can't we just encode ( and ) characters in cssURL context and
have only 1 function for CSS encoding? I don't see a reason why we
need to have non-encoded ( and ) characters in cssURL?
We are evaluating to see if we can use this library at our enterprise
(you all know it :)) and any help regarding these questions will be
helpful. Are you guys aware of any other enterprises using this library?
A quick response will be highly appreciated :)
[1]
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
<https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAgcCca8MHCdO2m_YWZFa6vGrRH-uGWWks5tagdQgaJpZM4Sav-P>.
Deleted user commented
Hey Jim - Did you get a chance to look at my questions?
jmanico commented
I don't have a quick answer to any of your questions. Dr. Ichnowski
would need to answer those.
Please keep in mind this library was designed for performance and to
achieve that goal we encode only what is necessary.
And while we encode less than other libraries suggest no one has
reported a bypass against his library being used correctly.
That's the best I can answer quickly. We do not have published research
regarding your other questions.
- Jim
…On 3/6/18 10:09 AM, vikxcoder wrote:
Hey Jim - Did you get a chance to look at my questions?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgcCRn57lz1pfGdIE_X5kUsB6C-kAbEks5tbu0KgaJpZM4Sav-P>.
jmanico commented
[1] Rule#1 suggests that we also need to encode "/" character as it
can be used to end HTML entity but it doesn't seem like java encoder
does it any HTML context encoders. Is there a reason why you guys
decided not to encode this specific character? If it is not necessary
don't we need to update OWASP wiki?
The wiki suggests very aggressive rules. This library takes a different
approach and only encodes what we think is necessary.
[1] Rule#2 suggests that we need to encode characters like
"%,*,......." for non-attributed characters but again I don't see them
in forHtmlUnquotedAttribute function. IMO they don't break the context,
so don't we need to change the OWASP wiki if it's not needed? or am I
missing something here?
I don't full understand your question can you provide more detail?
1. Can you help me in getting a couple of strong "code examples" on
why context sensitive based encoding needs to be done? and why
HTML encoding alone won't help in those cases?
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet shows XSS
attacks using a wide variety of attacks. Other wiki resources on OWASP
explain contextual escaping. We do not have exact code examples asking
for what you are looking for right now.
I know that it can help for unquoted attributes but for now let us
assume that entire world is using quoted attributes [I know its
impossible but just let's assume :/], can you help me in providing two
more examples where HTML encoding will not help and lead to XSS
attacks which would be protected if we had used context-sensitive
encoding?
In an attribute context that is properly quoted, you need to encode very
few characters, less that HTML entity encoding. I do not have the exact
characters but that is the general principle.
4. Why can't we just encode ( and ) characters in cssURL context and
have only 1 function for CSS encoding? I don't see a reason why we
need to have non-encoded ( and ) characters in cssURL?
I am not sure. Dr. Ichnowski might be able to answer that.
We are evaluating to see if we can use this library at our enterprise
(you all know it :)) and any help regarding these questions will be
helpful. Are you guys aware of any other enterprises using this library?
I'm sorry we do not have the info you are looking for. If you find it
elsewhere from other libraries, we would love to know about it.
Aloha, Jim
Deleted user commented
Thanks for your quick response Jim. Appreciate it :)
jmanico commented
I am fine with other answers but just surprised that you guys have no
examples on why should people use this library instead of just HTML
encoding. People know that context-sensitive escaping is required but
why? how are these library functions helping me? and why don't I just
use HTML escaping?
From
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F
Why Can't I Just HTML Entity Encode Untrusted Data?[edit
<https://www.owasp.org/index.php?title=XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet&veaction=edit&vesection=3> | edit
source
<https://www.owasp.org/index.php?title=XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet&action=edit§ion=3>]
HTML entity encoding is okay for untrusted data that you put in the body
of the HTML document, such as inside a <div> tag. It even sort of works
for untrusted data that goes into attributes, particularly if you're
religious about using quotes around your attributes. But HTML entity
encoding doesn't work if you're putting untrusted data inside a <script>
tag anywhere, or an event handler attribute like onmouseover, or inside
CSS, or in a URL. So even if you use an HTML entity encoding method
everywhere, you are still most likely vulnerable to XSS. *You MUST use
the escape syntax for the part of the HTML document you're putting
untrusted data into.* That's what the rules below are all about.
…On 3/6/18 11:01 AM, vikxcoder wrote:
Thanks for your quick response Jim. Appreciate it :)
I am fine with other answers but just surprised that you guys have no
examples on why should people use this library instead of just HTML
encoding. People know that context-sensitive escaping is required but
why? how are these library functions helping me? and why don't I just
use HTML escaping?
I feel its good to add a section about this topic on this library wiki
page which talks about few examples where HTML encoding is not helping
but using the context-escaping functions within this library are
helping in preventing XSS attacks. Only with those examples people can
know the importance of context sensitive escaping and why this library
should be used instead of plain HTML escape functions. Wiki you
pointed is a generic XSS cheatsheet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgcCWhYG8FMSTKD_FQDNCIlzCdW2hN0ks5tbvkZgaJpZM4Sav-P>.
--
Jim Manico
Manicode Security
https://www.manicode.com
jmanico commented
Another note, this is an open source project and the research you are
suggesting sounds reasonable and important. We could use your help!
If you want to dedicate some time to help dig into these issues, I'm
happy to help guide and ask other experts for help, especially around
attack research.
- Jim
…On 3/6/18 11:01 AM, vikxcoder wrote:
Thanks for your quick response Jim. Appreciate it :)
I am fine with other answers but just surprised that you guys have no
examples on why should people use this library instead of just HTML
encoding. People know that context-sensitive escaping is required but
why? how are these library functions helping me? and why don't I just
use HTML escaping?
I feel its good to add a section about this topic on this library wiki
page which talks about few examples where HTML encoding is not helping
but using the context-escaping functions within this library are
helping in preventing XSS attacks. Only with those examples people can
know the importance of context sensitive escaping and why this library
should be used instead of plain HTML escape functions. Wiki you
pointed is a generic XSS cheatsheet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgcCWhYG8FMSTKD_FQDNCIlzCdW2hN0ks5tbvkZgaJpZM4Sav-P>.
Deleted user commented
I will surely be interested in it. I will let you know once I get some free time.
Also, why are there two TLD files under [1], which one should I be using?
jeremylong commented
99.9% of users should use the java-encoder.tld. The advanced version
contains functions that can be used dangerously (see the descriptions in
each tag for more information).
…--Jeremy
On Thu, Mar 8, 2018 at 10:50 PM, vikxcoder ***@***.***> wrote:
I will surely be interested in it. I will let you know once I get some
free time.
Also, why are there two TLD files under [1], which one should I be using?
[1] https://github.com/OWASP/owasp-java-encoder/tree/
82d874d/jsp/src/main/resources/META-INF
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0qwjSB3Pf9xB9xb38rnhx0BO6e8h96ks5tcfvvgaJpZM4Sav-P>
.
Deleted user commented
I see that advanced one exposes additional tags of JS(attribute etc.) and XML encoder which we anyway are exposing in core by default.