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

travis+ml-webappsec at subspacefield.org travis+ml-webappsec at subspacefield.org
Sat May 15 08:13:34 EDT 2010


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20100515/ba2f24b5/attachment.bin>


More information about the websecurity mailing list