[OWASP-ESAPI] Esapi encodeForHTMLAttribute and AntiCSRF

Jeff Williams jeff.williams at owasp.org
Mon Jul 7 22:53:25 EDT 2008


Hi Stefano!

I'll add the encodeForHTMLURI() method - I like that. But I still need to figure out the rules.

I don't understand the patch code you sent.  Why not just use HTTPUtilities.getCSRFToken()?

About the time limit on csrf tokens, you're right - I took the simplest path. Or if you want a timeout, you can use something like this...

	String token = ESAPI.randomizer().getRandomString(8, DefaultEncoder.CHAR_ALPHANUMERICS);
	long expiry = ESAPI.encryptor().getRelativeTimeStamp(seconds * 1000);
	String cryptToken = ESAPI.encryptor().seal(token, expiry);

To verify you do...

	ESAPI.encryptor().unseal( token );

Easy.  Keep 'em coming!!!

--Jeff


-----Original Message-----
From: Stefano Di Paola [mailto:stefano.dipaola at mindedsecurity.com] 
Sent: Monday, July 07, 2008 4:47 AM
To: jeff williams
Subject: Re: Esapi encodeForHTMLAttribute and AntiCSRF

Hi Jeff,

About encodeForHtmlAttribute, white listing would be good, maybe
implementing encodeForHtmlURI(), but in the meantime, it should probably
be added in the documentation that encodeForHtmlAttribute cannot be used
in href and src context without further validation (you know how
developers are dull when dealing with application security :) )

About anti Csrf, my thoughts are about an implementation of (one time)
tokens expecially on forms.

public String addCSRFToken(String href) {
  User user = ESAPI.authenticator().getCurrentUser();		
// FIXME: AAA getCurrentUser should never return null
  if (user.isAnonymous() || user == null) {
	return href;
  }
+  if(href==null ||href.equals("") ){
+   return user.getCSRFToken();
+  }else if( href.indexOf( '?') != -1 ) || ( href.indexOf( '&' ) !=
-1 ) ) {
    return href + "&" + user.getCSRFToken();
  } else {
    return href + "?" + user.getCSRFToken();
  }
}
 
so that a dev can use it in hidden fields.

This is a simple but quick fix.
Moreover, I would implement at least two kind of Tokens.
1. The one already implemented (fixed token).
2. A token tied to a time interval (aka one time token).

Well, probably you already thought if implementing one time token
against fixed tokens, and you chose the simplest one.

Anyway it's just an idea :)

Thanks,
Stefano

Il giorno lun, 07/07/2008 alle 01.08 -0400, jeff williams ha scritto:
> Hi Stefano,
>  
> Totally agree about the encode for HTML attribute method. I'll think
> about a whitelist policy for href and src attributes that will work in
> most cases.  Some of the attacks you mentioned won't work because the
> canonicalizer will eliminate any %-encoded characters.  Hopefully, the
> application would be doing some input validation on those fields as
> well, but it would be nice if the encoding also disabled any attacks.
>  
> With regard to the CSRF defenses, there is a significant amount of
> support already built into ESAPI.  Every User has a CSRF token and the
> HTTPUtilities class has several methods to enable using it.  The CSRF
> token is only good for a single login session.  To make it  a bit more
> difficult to find (and to simplify the verification code a bit), the
> token is actually the *name* of the CSRF token parameter, there is no
> value.
>  
> public String addCSRFToken(String href) {
> public String getCSRFToken() {
> public void verifyCSRFToken() throws IntrusionException {
>  
> Let me know if you had something different in mind.  Thanks!
>  
> --Jeff
> 
>  
> 
>  
> On Fri, Jul 4, 2008 at 1:20 PM, Stefano Di Paola
> <stefano.dipaola at mindedsecurity.com> wrote:
>         Hi Jeff,
>         
>         since I'm trying to push esapi into customers' solutions, I'm
>         looking at
>         esapi methods and features.
>         Now, I've got a couple of question.
>         first Q. :
>         let's suppose we want to use user input to
>         
>         <a href="<%
>         =esapi.encoder().encodeForHtmlAttribute(request.getParameter("ref"))%
>         >">user</a>
>         
>         A pattern like:
>         ref=javascript:alert(1)
>         
>         is executed (tested on ff latest) since it's encoded to:
>         
>         <a href="javascript&#58;alert&#40;1&#41;">user</a>
>         
>         Which is executed when user clicks on it.
>         
>         The problem gets harder when thinking to filter javascript
>         word.
>         As you know infact
>         ref=ja%09va%09script:alert(1)
>         
>         is interpreted as javascript:.
>         in particular any variation of:
>         ja%09va%09sc%09ript%
>         3aalert(23)/d/.toString().constructor.constructor(%
>         22alert(3)%22)()
>         
>         gets executed on Firefox.
>         I didn't checked on IE but i think it'll be executed as well.
>         
>         Do you have any idea about that?
>         Probably, at least, it should be documented that use of
>         encodeForHTMLAttribute cannot be used on href and src
>         attributes.
>         
>         
>         second Q.:
>         do you need some help for anti CSRF?
>         I mean, one time token should be implemented directly tied to
>         user
>         Session.
>         
>         In particular i think that a simple createTokenForm() and
>         checkForTokenForm() should be added in esapi (with time
>         restrictions as
>         well).
>         
>         
>         Looking forward to your reply.
>         
>         Thanks
>         Stefano
>         
>         --
>         Stefano Di Paola
>         Chief Technology Officer, Lead Auditor ISO 27001
>         Minded Security - Application Security Consulting
>         
>         Cell: +39 3209495590
>         Email: stefano.dipaola [at] mindedsecurity.com
>         
>         Minded Security S.r.l.
>         Via Duca D'Aosta, n.20 50129 Firenze (FI)
>         www.mindedsecurity.com
>         
>         _________________________________________________________________________________________________
>         
>         Pay attention, this email is confidential. If you are not
>         authorized,
>         or if you have received this message by mistake,please not
>         read,
>         use or spread any piece of the information above.
>         
>         
> 
-- 
Stefano Di Paola
Chief Technology Officer, Lead Auditor ISO 27001
Minded Security - Application Security Consulting

Cell: +39 3209495590
Email: stefano.dipaola [at] mindedsecurity.com

Minded Security S.r.l.
Via Duca D'Aosta, n.20 50129 Firenze (FI)
www.mindedsecurity.com

_________________________________________________________________________________________________

Pay attention, this email is confidential. If you are not authorized,
or if you have received this message by mistake,please not read,
use or spread any piece of the information above.





More information about the OWASP-ESAPI mailing list