[WEB SECURITY] CSRF and Header Forging - your thoughts needed

Jim Manico jim at manico.net
Sun May 16 21:22:02 EDT 2010

Yes, there are situations where saving the CSRF token state in a  
session is a pain - and computing the CSRF token value on-the-fly is  
preferable. Hashing the session using a known salt is an acceptable  
way to generate an 'on the fly' CSRF token value.

Jim Manico

On May 15, 2010, at 5:13 AM, travis+ml-webappsec at subspacefield.org  

> On Fri, May 14, 2010 at 09:50:56AM -0700, Michael Coates wrote:
>> I'm looking for thoughts on CSRF attacks that result in forged  
>> headers
>> from the victim user to the target site. Are there modern attacks  
>> that
>> work here? If not, could we implement a CSRF protection that uses a
>> custom header and avoid the cost of computing random numbers?
> I always figured you could use a HMAC'd tuple of (session ID,
> timestamp), optionally encrypting it, and stuffing it in a hidden
> input field.  Not sure why you'd need random numbers; am I missing an
> assumption or attack here?
> Anyway...
> HMAC is a tad slow (two hashes), encryption is fast, and random
> numbers... well, technically you can't compute those :-) but spitting
> them out is generally pretty fast.  Linux /dev/{u,}random is
> _relatively_ slow since it does a hash of the entire kernel entropy
> pool to spit out a measly 160 bits, but still fast.  Yarrow is
> especially fast; fast as a block cipher encryption of one input block
> per output which is practically superliminal :-)
> Openssl gives these times on my desktop (AMD64 x2)...
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes    
> 8192 bytes
> md5              35821.69k   117040.09k   295250.71k   471794.47k    
> 576431.86k
> hmac(md5)        38888.63k   128923.38k   311725.46k   483936.92k    
> 579062.07k
> sha1             35674.71k   103026.99k   226427.56k   325065.89k    
> 371546.93k
> rc4             179971.94k   189020.22k   192764.15k   193822.31k    
> 194161.36k
> blowfish cbc    105218.04k   114303.49k   117271.72k   117627.22k    
> 118257.96k
> aes-128 cbc     110266.68k   117700.69k   119623.92k   121031.66k    
> 121348.45k
> aes-192 cbc      96369.50k   102035.22k   103774.95k   104849.38k    
> 104704.68k
> aes-256 cbc      87228.91k    90767.43k    91989.79k    92345.00k     
> 92876.46k
> sha256           23360.86k    57895.93k    96665.00k   121016.59k    
> 130017.96k
> sha512           16078.82k    67234.70k   114632.52k   169827.49k    
> 197849.13k
> (Collisions don't matter in HMAC constructions, so hmac(md5) is
> actually kosher.  Really odd that the HMAC is faster than the
> underlying hash in this case, no idea what is up with that)
> Slowest speed based on conveniently available timings and input sizes:
> Doing aes-256 cbc for 3s on 8192 size blocks: 33899 aes-256 cbc's in  
> 2.99s
> Fastest (e.g. something like OpenBSD /dev/arandom over a small seed):
> Doing rc4 for 3s on 16 size blocks: 33632256 rc4's in 2.99s
> Typical bandwidth of Linux /dev/urandom is about 8MB/s.  If your
> random values are 512 bits each (64 octets, extreme paranoia level),
> you still get 131072 per second.
> My suspicion is that crypto & CSPRNG speeds simply don't matter enough
> to worry about them.  A form submission probably takes orders of
> magnitude more CPU time.
> One possible caveat is if you're using /dev/random, which depends on
> injected entropy rate from kernel variables, and blocks if the pool
> gets empty.  That can drop your RNG bandwidth to near zero on a busy
> web server with no keyboard/mouse input or HWRNG to feed the pool.
> Why HMAC?  Answer here:
> http://www.subspacefield.org/security/web_20_crypto/web_20_crypto.pdf
> -- 
> A Weapon of Mass Construction
> My emails do not have attachments; it's a digital signature that  
> your mail
> program doesn't understand. | http://www.subspacefield.org/~travis/
> If you are a spammer, please email john at subspacefield.org to get  
> blacklisted.

Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn

More information about the websecurity mailing list