Replacing the standard JspWriter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing the standard JspWriter

Adam Rauch-2
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.)

Thanks,
Adam




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Replacing the standard JspWriter

markt
On 12/09/2020 00: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?

How about using an include-prelude mapped to all JSPs to wrap the
default JspWriter with the custom writer?

Mark


> (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.)
>
> Thanks,
> Adam
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Replacing the standard JspWriter

Christopher Schultz-2
In reply to this post by Adam Rauch-2
-----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 <c:out value="{stuff}" /> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Replacing the standard JspWriter

Adam Rauch-2
In reply to this post by markt
On 9/12/2020 2:15 AM, Mark Thomas wrote:

> On 12/09/2020 00: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?
> How about using an include-prelude mapped to all JSPs to wrap the
> default JspWriter with the custom writer?
>
> Mark
>
This works great... much cleaner than my previous approach. Thanks for
the suggestion, Mark!

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [OT] Replacing the standard JspWriter

Adam Rauch-2
In reply to this post by Christopher Schultz-2
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 <c:out value="{stuff}" /> 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: [hidden email]
For additional commands, e-mail: [hidden email]