Forum Discussion
Nimbostratusrandom header to avoid HEIST attack
Could I reduce the effectiveness of the HEIST https attack, by adding a random length noise header to every https response? The attack works by launching hundreds of queries, and comparing their response lengths. If an iRule were injecting a random length, random content header into every response, that might disrupt the attack. A random length cookie should have the same effect. Do you think this will help? Will this use too much cpu? Is there a risk of running out of entropy in the LTM?
http://arstechnica.com/security/2016/08/new-attack-steals-ssns-e-mail-addresses-and-more-from-https-pages/
11 Replies
doke_23794https://tom.vg/papers/heist_blackhat2016.pdf Section "4.3.2 Apply random padding (inadequate)" on page 24 says my length padding idea in extra headers isn't good enough.
On the other hand, I think it's easier to apply than the others. It's one of the few mitigations I could apply in the f5, to protect existing applications. I'm not sure I could do the 3rd party cookie blocking in an iRule?
Yann_Desmarest_Nacreous
Hi,
You can add headers with random length of chars. But At the end, I think that this is not a solution that can effectively prevent HEIST attack because many things : compression, cipher by blocks, etc. that may lead to the same encrypted size.
Today, the only way to really prevent HEIST attack is to disable the use of Third party cookies option in your browser. Disabling this feature may have many other unwanted side effect on the JS apps running.
You should consider a technology like Websafe to prevent this attack.
- Yann_Desmarest_
If you want to generate a random header, you can use the code below :
 
when RULE_INIT { Number of random letters to generate set static::count 100 Create a list of the letters indexed 0 through 25 set static::letters [ list a b c d e f g h i j k l m n o p q r s t u v w x y z ] } when HTTP_RESPONSE { Initialize a variable to store the random letters in set random "" Loop through X times where X is the number of random letters to generate for { set i 1 } { $i < $static::count } { incr i } { Generate a random number between 0 and 1, using rand() Multiply that by 26 to get a number representing a letter Use int to trim off the decimal value set rand [expr { int (rand() * 26) }] append random [lindex $letters $rand] Or in one command: append random [lindex $static::letters [expr { int (rand() * 26) }]] } HTTP::header insert "RandomHeader" $random }code taken from : random letter generator
 
You can customize values to increase/decrease header value length
 
Yann_DesmarestCirrus
Hi,
You can add headers with random length of chars. But At the end, I think that this is not a solution that can effectively prevent HEIST attack because many things : compression, cipher by blocks, etc. that may lead to the same encrypted size.
Today, the only way to really prevent HEIST attack is to disable the use of Third party cookies option in your browser. Disabling this feature may have many other unwanted side effect on the JS apps running.
You should consider a technology like Websafe to prevent this attack.
- Yann_Desmarest
If you want to generate a random header, you can use the code below :
when RULE_INIT { Number of random letters to generate set static::count 100 Create a list of the letters indexed 0 through 25 set static::letters [ list a b c d e f g h i j k l m n o p q r s t u v w x y z ] } when HTTP_RESPONSE { Initialize a variable to store the random letters in set random "" Loop through X times where X is the number of random letters to generate for { set i 1 } { $i < $static::count } { incr i } { Generate a random number between 0 and 1, using rand() Multiply that by 26 to get a number representing a letter Use int to trim off the decimal value set rand [expr { int (rand() * 26) }] append random [lindex $letters $rand] Or in one command: append random [lindex $static::letters [expr { int (rand() * 26) }]] } HTTP::header insert "RandomHeader" $random }code taken from : random letter generator
You can customize values to increase/decrease header value length
- Yann_Desmarest
Third party cookie can be disabled on the client side only. From F5 system point of view, the cookie present in the request give no indication if the request was done from a third party javascript code.
- Kai_Wilke
MVP
Hi Doke,
there isn't much room to protect against HEIST on the F5 level...
-
Adding a random length HTTP::header value to each HTTP response, or using dynamic windows sizes will "just" slow down the HEIST attack. The lenght differences of your responses must be very huge to make this technique even effective (e.g. a 1 to 50kbyte header padding makes the attack just ~50.000 times slower but still not impossible).
-
Disabling GZIP and SSL compression will mitigate the most feared attack vectors of the HEIST technique (aka. defending the Crime and BREACH style attacks).
In the end its far more effective to...
-
Pentest your web applications and keep an eye on external accesible functions without CSRF protection or function that can be used for request reflections.
-
Disalow 3rd Party Cookies in your internal users browser and/or recommend your customers to secure their systems (as always :-)
Cheers, Kai
-
- Yann_Desmarest
Hi,
You can find an article from F5 regarding that attack : Security Sidebar: Hands Up…This is a HEIST
- Kai_Wilke
Thanks Yann for providing the official link... ;-)
Cheers, Kai
- Yann_Desmarest_
Hi,
You can find an article from F5 regarding that attack : Security Sidebar: Hands Up…This is a HEIST
- Kai_Wilke
Thanks Yann for providing the official link... ;-)
Cheers, Kai
