Forum Discussion
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)).
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
- JRahmAdmin
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.
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
- JRahmAdmin
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? :)
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com