Re: Re: [OT] Replacing the standard JspWriter

2020-09-15 Thread Adam Rauch

On 9/14/2020 6:19 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 9/11/20 19:30, Adam Rauch wrote:

I have implemented a custom JspWriter and registered it for use by
our JSPs using the approach described here:
https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-

out-jspwriter-with-jsp-includes-to-change-the-beh



I created a custom JspFactory that returns a custom JspContext
that returns my custom JspWriter. I then replaced the standard
JspFactory by calling JspFactory.setDefaultFactory(). This works,
though it results in some undesired behavior. I also note that the
setDefaultFactory() JavaDoc seems to claim that my approach is
"illegal".

So, is there a preferred way for my web application to provide a
custom JspWriter for my JSPs to use?

(If you're curious, our JspWriter HTML encodes all strings that
aren't designated as safe-to-render, like React and other modern
JavaScript frameworks do. The usual JSP approach is too susceptible
to XSS vulnerabilities, IMO.)

Really?

Seems like  should work just fine. You prefer
this?

<%= myVar %>

How do you mark variables as being "HTML-safe"?

If you don't trust your JSP programmers to do this correctly, maybe
JSP isn't the right technology for your team. (I happen to think that
JSP needs to go away, but that's just me).

- -chris

Thanks, Chris. I don't particularly love JSPs either, and we target 
React for most UI work these days, but we maintain a large system that 
includes ~1,000 existing JSPs. We also have many third party developers 
building their own code on our platform and we like the system to 
enforce best practices as much as possible. Our JSP base class makes it 
trivial to encode Strings (<%=h(myString)%>); the challenge is 
distinguishing Strings that contain well-formed HTML (produced by helper 
methods or commonly used builders) from those that don't. We have 
introduced a SafeToRender interface to mark Objects that are allowed to 
render themselves without encoding (i.e., their toString() must render 
well-formed HTML or JavaScript). HtmlString and JavaScriptFragment are 
String wrappers that implement SafeToRender, and are used to safely 
build ad hoc content. Likewise, builders for common HTML elements and 
JSON. While I trust my developers, this approach allows for 
straightforward verification and security auditing.


Adam


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Replacing the standard JspWriter

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 9/11/20 19:30, Adam Rauch wrote:
> I have implemented a custom JspWriter and registered it for use by
> our JSPs using the approach described here:
> https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-
out-jspwriter-with-jsp-includes-to-change-the-beh
>
>
>
> I created a custom JspFactory that returns a custom JspContext
> that returns my custom JspWriter. I then replaced the standard
> JspFactory by calling JspFactory.setDefaultFactory(). This works,
> though it results in some undesired behavior. I also note that the
> setDefaultFactory() JavaDoc seems to claim that my approach is
> "illegal".
>
> So, is there a preferred way for my web application to provide a
> custom JspWriter for my JSPs to use?
>
> (If you're curious, our JspWriter HTML encodes all strings that
> aren't designated as safe-to-render, like React and other modern
> JavaScript frameworks do. The usual JSP approach is too susceptible
> to XSS vulnerabilities, IMO.)

Really?

Seems like  should work just fine. You prefer
this?

<%= myVar %>

How do you mark variables as being "HTML-safe"?

If you don't trust your JSP programmers to do this correctly, maybe
JSP isn't the right technology for your team. (I happen to think that
JSP needs to go away, but that's just me).

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fbeQACgkQHPApP6U8
pFi2gg/7BpbFf3+QXlr78ZjIHYB2C2x0+VF9mX4pKwiOmp2y6q70tWGExCOaEYId
vSNYMUjL0PwsCEVZDmX4roAT+Ep2VeqR+opvRf9JU8SuVkAlgplXg7nePRPnCRq6
hlf0NgrZ6U5WM3wxvpH8uFroarTSym6T/fEjdR3Ff7AjSE7v23VUvmW5bCxQ/M/u
1hEZPXpOfCjJZRkJynu0etF1GnhgjFPsbsvW7IPFsKLKgApYPVY5uytJSGeshtU4
/l612ZHO0618vI53jP/JmOPCQrdjLTY7YNFHwh0j+QCykSYTk7rpI46JFfD/wmJ/
/JsrUH7Dy+qrmZJzh9hCF1q4ITRddhUhK5ztNYpOiOFDAr+urz+QEaeThsSohOvt
k86X8Jivhn2TB4Mtb4vb/MEEvzRVC+Fjj3QXEzP4GY3SJpvTDB+wVIQq59IvH9Em
+iDnLeJBWHzHx1ZS/XyUUW1ZKIvNEQ1qKXqw95uHk0mvCKsVMkHThQ71h+g7Ooc2
z/ubrBy2yxJrzhELk+oDUQwd82YdEksZ9CGgXvj+JPpdNqAWpf5C2W2Sjwv2cvTj
z38bBFyk1mKC1B90KslEZjmIPCYgPFfZGV9Ro6vg7VcH/yOFIGXOvaLBh2apx4xs
m6ADTFP+PBIiAJ5glrvhfJHvYpMssy68vDnThKbjfon+vE1tu1I=
=zEGy
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org