rmannibucau commented on PR #122:
URL: https://github.com/apache/johnzon/pull/122#issuecomment-1998478259
> Yes because of the number of method I have, I prefer a global solution.
Security team don't want script injection, I don't want to change existing
behavior.
We likely aim at reaching the same goal.
> You can escape < to < but in that case you will have to ask all of your
clients to add unescapeHTML in their code (every methods, every string fields
...).
Depends how you do it but ultimately no, just at the data binding time.
> The beauty here is that this escape is not a real one for JSON ( "\u003C"
= "<" : it is just another way to write it) while for an HTML parser ("\u003C"
!= "<") it will behave differently.
Yes and why we discuss it is that you can still get injections so you just
made it harder to understand but you didn't solve the issue you PR for.
> So with that patch, REST clients have nothing to change and security team
cannot insert script tags.
Maybe not your team but I know some people and frontend apps who are able to
do it without more changes ;).
Long story short: HTML injections can only be handled in the frontend to be
safely handled, anything else is just faking a fix.
It is similar to "SQL injection can only be fixed at JDBC layer" (in java
but more generally at binding time/protocol abstraction).
All the fixes in WAF to filter SQL injections make it less likely to happen
but they can be bypassed and you still get SQL injections.
This is why originally I spoke about fixing the issue at the right layer,
JSON can look tempting and I fully understand your reasoning but it does not
fix it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@johnzon.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
