Technical Forum
Ask questions. Discover Answers.
Showing results for 
Search instead for 
Did you mean: 

XFF and sleep


Recently I was asked about mitigating the below XFF header:


X-Forwarded-For: (select(0)from(select(sleep(5)))v)/*'+(select(0)from(select(sleep(5)))v)+'"+(select(0)from(select(sleep(5)))v)+"*/


Basically it is an injection to sleep the request.


The question was, can we enforce that the X-Forwarded-For header contains ip data only?


Working with LTM and ASM I was thinking either an irule or a customer attack signature to mitigate any requests where wording is in the XFF header.


Before I start testing different options, has anyone encountered and implemented any protection for this type of request?



Hi Dave,


you can block this by enforcing Attack Signature ID 200000074 (SQL-INJ "end-quote select" (Headers)).

0691T00000CoRiXQAV.pngAnother approach could be to use an iRule or LTM Policy to scrub any XFF header from the HTTP Request. Unless there is a device in front of the BIG-IP that would insert such header, why would a client send a XFF header...





Community Manager
Community Manager

If you don't have ASM/Advanced WAF and would like to do this in an iRule, you could do a check to make sure the value(s) are at least numeric and then act accordingly on finding something else. For example:


% set x (select(0)from(select(sleep(5)))v)/*'+(select(0)from(select(sleep(5)))v)+'"+(select(0)from(select(sleep(5)))v)+"*/ (select(0)from(select(sleep(5)))v)/*'+(select(0)from(select(sleep(5)))v)+'"+(select(0)from(select(sleep(5)))v)+"*/ % foreach ip $x { if { [string is integer [lindex [split $ip "."] 0]] } { puts "header ok" } else { puts "header not ok" }     } header not ok % set x % foreach ip $x { if { [string is integer [lindex [split $ip "."] 0]] } { puts "header ok" } else { puts "header not ok" }     } header ok

Note that this is very rudimentary to show what's possible. If you want to verify actual valid IP addresses in the header, far more logic is required.

I took a different approach with an iRule. You can verify it the XFF header contains a valid IP address:

when HTTP_REQUEST { if { [scan [HTTP::header "X-Forwarded-For"] %d.%d.%d.%d a b c d] == 4 && 0 <= $a && $a <= 255 && 0 <= $b && $b <= 255 && 0 <= $c && $c <= 255 && 0 <= $d && $d <= 255} { #log local0. "Valid XFF Header: [HTTP::header "X-Forwarded-For"]" } else { reject #log local0. "Invalid XFF Header: [HTTP::header "X-Forwarded-For"]" } }

From my log:

May 26 08:15:16 info tmm1[11286]: Rule /Common/rule_verify_xff <HTTP_REQUEST>: Invalid XFF Header: (select(0)from(select(sleep(5)))v)/*'+(select(0)from(select(sleep(5)))v)+'"+(select(0)from(select(sleep(5)))v)+"*/

May 26 08:15:57 info tmm3[11286]: Rule /Common/rule_verify_xff <HTTP_REQUEST>: Invalid XFF Header:

May 26 08:16:06 info tmm2[11286]: Rule /Common/rule_verify_xff <HTTP_REQUEST>: Invalid XFF Header:

May 26 08:16:26 info tmm2[11286]: Rule /Common/rule_verify_xff <HTTP_REQUEST>: Valid XFF Header:




Community Manager
Community Manager

It's true that scan as written will validate a specific IP address, but it will not handle the case where an IP address is in the string with other characters, or in a list of IP addresses (as is sometimes the case with XFF), or finally, a valid IP address in a superset range where, in the case of network, the IP is completely valid because the broadcast is (Update...actually, we just need to validate that it is a possible IP address, not that it is valid in the context of a client network, so ignore this last point. And with that, just adding a foreach loop to your logic to handle multiple IP addresses might be good enough)


That's why I stayed rudimentary, because the logic is a project since we don't have the full breadth of Tcl libraries available in iRules that have already solved this problem.


Also, ASM/AdvWAF is the way to go here, if you have it. And if you don't, why not? 🙂