[Esapi-user] encodeForHTMLAttribute the value of an <input>

Rod Widdowson rdw at steadingsoftware.com
Fri Mar 23 10:29:07 UTC 2012


This seems so obvious a question that I spent some time searching the archives.  My apologies if this has been touched and I missed
it - pointer to the solution is a great answer.

One of the stages of a web application I maintain has the simple task of constructing a form based on user's input and several other
parameters passed in (from a form or pseudo form on the previous stage).

That is to say when approached as:

https://host/app/page1?return=returnValue

I need to redirect to:

https://host/app/page2?return=returnValue&param=param

returnValue is URLEncoded on 'input' and that encoding has to be preserved on 'output'

So the pseudo HTML for my constructed web pages looks like this: (I'm using JSP but the principal is the constant)

<form>
  <input type="hidden" name="return" value="<bean:write name="returnParam" />" />
  <select name="param">
    <option> [...]

So far so good.  But since returnValue is (for the sake of this question) untrusted we need to harden this using RULE2 in the XSS
cheat sheet:

  <input type="hidden" name="return" value="<esapi:encodeForHTMLAttribute><bean:write name="returnValue"
/><e/sapi:encodeForHTMLAttribute>" />

Or do we, because this is where the wheels begin to fall off.

The trouble is that returnValue is in the form of a URL = which we will eventually dispatch to (after significant policing against a
white list I should say).  To make things exciting that URL is garnished with a parameter - for instance the URL (*after* decoding)
might be https://site.com/Shibboleth.sso/initiator?SAMLDS=1&target=cookie%3A6eafc6f2) 

So I am given

https://host/app/page1?https%3A%2F%2Fsite.com%2FShibboleth.sso%2initiator%3FSAMLDS%3D1%26target%3Dcookie%253A6eafc6f2

And I need to produce 

https://host/app/page2?https%3A%2F%2Fsite.com%2FShibboleth.sso%2initiator%3FSAMLDS%3D1%26target%3Dcookie%253A6eafc6f2&param=param

Because of form encoding I therefore have to create the pseudo-html

<form>
  <input type="hidden" name="return" value="https://site.com/Shibboleth.sso/initiator?SAMLDS=1&target=cookie%3A6eafc6f2" />
  <select name="param">
    <option>
[...]

But the trouble here is that pesky '&' - if I feed that string into encodeForHTMLAttribute the '&' is going to be rendered as
'&' which will then cause brokenness downstream.

I can construct numerous arguments as to why it's OK, for instance "it is going to be policed afterwards"; but just dropping that
encoding flies too closely in the face of RULE2 to be acceptable to me off hand and I am not prepared to accept "well it works like
that and it doesn't if I escape", that is the sound of doom to me.

So I'm coming to the experts here:
 - Are attributes to <input/> somehow special (because of forms encoding)?
 - I read somewhere in this list that encoding can destroy data.  Is this one such case?  
 - Is another alternative to make the data "trusted" (and hence remove the need to encode by RULE2).  How do I do that, absent
encoding it (which we see doesn't work)?

It actually turns out that I do the white list testing prior to generating the webpage (as well as afterwards) - would this be
sufficient?  

I apologise for the obvious question, but I am extremely careful where this stuff is concerned.  Because I do not do this every day
I need to spend a lot of time making sure I understand the principals, it makes my brain bend and I am never going to be confident
enough to call myself an expert and make a call like this.  But the readership of this list is expert.

Thanks in advance

Rod Widdowson






More information about the Esapi-user mailing list