XFF and sleep

[Dave_Pisarek]

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?

[Daniel_Wolf]

Hi Dave,

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

Another 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...

KR

Daniel

[JRahm]

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 1.2.3.4 1.2.3.4 % 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.

[Daniel_Wolf]

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 awaf.mydomain.de 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 awaf.mydomain.de info tmm3[11286]: Rule /Common/rule_verify_xff <HTTP_REQUEST>: Invalid XFF Header: 10.200.200.1000

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

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

[JRahm]

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 10.10.10.0/23, the IP 10.10.10.255 is completely valid because the broadcast is 10.10.10.11.255. (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? 🙂