search

OWASP / owasp-java-encoder

The OWASP Java Encoder is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. This project will help Java web developers defend against Cross Site Scripting!
https://owasp.org/www-project-java-encoder/
BSD 3-Clause "New" or "Revised" License
483 stars 112 forks source link

Support for input canonicalization #43

Closed forgedhallpass closed 3 years ago

forgedhallpass commented 3 years ago

"Please note that with sufficient feedback from the user base, the above mentioned methods may be implemented in future releases of the OWASP Java Encoders, if/when that happens, this shim class will be updated to call out to the new methods.)"

With regards to the quote copied from the org.owasp.encoder.esapi.Encoder class: It would be nice if this project would support such functionality, independently from the EASPI project.

Use-case: Contextual encoding is not always possible, especially in case of big legacy projects that use the same database to serve both browser and non-browser clients. To (somewhat) minimize the risk, I have created some pluggable filters that among other things, verify every request (headers, body, cookies) against common XSS payloads (tested against the OWASP XSS cheatsheet). In order for such validations to be successful, the canonicalization of the input is a pre-requisite.

jmanico commented 3 years ago

There is no plans to add validation or canonicalization to the OWASP Java Encoder library. It’s not likely ever to appear in the Java Encoder Library even if donated. Our library is a single-purpose library for contextual output encoding. Validation strategies like you describe are doomed to fail in out opinion. If you can’t get your developers to focus on proper encoding and HTML sanitization and other necessary user interface security techniques then I recommend you look into CSP.

You can also move your developers to react and angular were much of the encoding is done automatically.

If you still want canonicalization and validation routines I recommend you build a separate library for those needs.

Respectfully,

Jim Manico @Manicode

On Dec 9, 2020, at 3:52 AM, forgedhallpass notifications@github.com wrote:

 "Please note that with sufficient feedback from the user base, the above mentioned methods may be implemented in future releases of the OWASP Java Encoders, if/when that happens, this shim class will be updated to call out to the new methods.)"

With regards to the quote copied from the org.owasp.encoder.esapi.Encoder class: It would be nice if this project would support such functionality, independently from the EASPI project.

Use-case: Contextual encoding is not always possible, especially in case of big legacy projects that use the same database to serve both browser and non-browser clients. To (somewhat) minimize the risk, I have created some pluggable filters that among other things, verify every request (headers, body, cookies) against common XSS payloads (tested against the OWASP XSS cheatsheet). In order for such validations to be successful, the canonicalization of the input is necessary.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

forgedhallpass commented 3 years ago

Hello Jim,

Thank you for your answer. I agree with your points about contextual encoding, but as I said it is not always that trivial (e.g. large legacy code base). I've created my own small pluggable WAF library as an additional layer of security and I want to get rid of ESAPI because I am only using its canonicalization feature. Since I've seen the above quoted comment in the code I thought it was worth asking.

p.s. I also know that creating your own WAF is not ideal, but it's a "better than nothing option" for clients who can't set up or do not want to invest into dedicated WAF solutions.

All the best.

kwwall commented 3 years ago

@jmanico - What @forgedhallpass hall pass is saying is remove that blatant lie in the comment from your Java Encoder source code. ;-)

@forgedhallpass - Seriously, the beauty of FOSS is that you can take its source code and change it to whatever you want. The ESAPI license is one of the most liberal FOSS licenses out there (BSD 3), so the better approach (instead of building a WAF) is to just use the ESAPI WAF and canonicalization and rip out all the parts that you don't need. (Or maybe consider OWASP AppSensor, which is WAF-like). Or use a real WAF; if you want a free one, mod_security and the OWASP Core Rules Set works for a lot of people.

forgedhallpass commented 3 years ago

I've tried to be subtle, but indeed that comment from the code could be removed :-)

@kwwall as I wrote in the other ESAPI issue, I have already extracted the logic I need, but wanted to have a short discussion to see what other (maybe better) options are out there and to know whether I could make my changes in a way that would potentially benefit the OSS community as well.

Currently for SaaS we have commercial WAF from CloudFlare and reverse proxies with custom rules, but I also wanted to provide at least some basic, embedded, "self-defense" measures for the other deployment strategies.

I haven't heard of the OWASP AppSensor, but I will look into it, thanks for the tip.

jmanico commented 3 years ago

We do not wish to add validation or canonizalization to our Encoding library. But if you want to fork our code and use it to build your own canonizalization lib, I totally support that!

Aloha, Jim

On 12/9/20 5:18 PM, Kevin W. Wall wrote:

@jmanico https://github.com/jmanico - What @forgedhallpass https://github.com/forgedhallpass hall pass is saying is remove that blatant lie in the comment from your Java Encoder source code. ;-)

@forgedhallpass https://github.com/forgedhallpass - Seriously, the beauty of FOSS is that you can take its source code and change it to whatever you want. The ESAPI license is one of the most liberal FOSS licenses out there (BSD 3), so the better approach (instead of building a WAF) is to just use the ESAPI WAF and canonicalization and rip out all the parts that you don't need. (Or maybe consider OWASP AppSensor, which is WAF-like). Or use a real WAF; if you want a free one, mod_security and the OWASP Core Rules Set works for a lot of people.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OWASP/owasp-java-encoder/issues/43#issuecomment-742210159, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBYCJZ355T5UUFSU54GDDSUA4Z7ANCNFSM4UTQSF5Q.

-- Jim Manico Manicode Security https://www.manicode.com

jmanico commented 3 years ago

The main tech I suggest you consider is a strict-dynamic CSP policy!

On 12/9/20 6:04 AM, forgedhallpass wrote:

Hello Jim,

Thank you for your answer. I agree with your points about contextual encoding, but as I said it is not always that trivial (e.g. large legacy code base). I've created my own small pluggable WAF library as an additional layer of security and I want to get rid of ESAPI because I am only using its canonicalization feature. Since I've seen the above quoted comment in the code I thought it was worth asking.

p.s. I also know that creating your own WAF is not ideal, but it's a "better than nothing option" for clients who can't set up or do not want to invest into dedicated WAF solutions.

All the best.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OWASP/owasp-java-encoder/issues/43#issuecomment-741871551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBYCIEPQBV7GX352EM72TST6N2TANCNFSM4UTQSF5Q.

-- Jim Manico Manicode Security https://www.manicode.com