19-May-2021 09:54
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?
19-May-2021 11:20
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
24-May-2021
14:29
- last edited on
04-Jun-2023
20:53
by
JimmyPackets
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.
25-May-2021
23:19
- last edited on
04-Jun-2023
20:53
by
JimmyPackets
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
26-May-2021 05:56
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? 🙂