I would check profiles on your VS .. you need HTTP profile to parse [HTTP::query] info, and if this HTTPS traffic you also need a clientSSL profile in order to see unencrypted data.
when HTTP_REQUEST {
if { [class match -- [URI::query [HTTP::uri -normalized] "func"] equals data-group-1] } then {
log local0. "Denied query: [IP::client_addr] - param func=[URI::query [HTTP::uri -normalized] "func"]"
HTTP::respond 403 content "Access Denied" "Content-Type" "text/html"
}
}
It applies HTTP::uri -nomalization to the request URI, then extracts the URI parameter “func” and then checks the value based on your Data-Group. If the func param is listed in the blacklist, it sends a HTTP 403 Access Denied to the client (slightly better than using a TCP reject).
Thanks for testing this. I have typically always used “string tolower”, but what I did not realize or had not noticed is the string in the data-group needs to be lowercase as well. Makes total sense! The string in my data-group is not all in lowercase, so I will fix that.
Thanks for your feedback @Kai_Wilke . Interesting way of writing the iRule, and thanks for the tip on sending the 403 back I will add this to my notes!
Happy to help!
I typically use that syntax if I need to normalize some data, but with URI’s /login and /LOGIN would be two different pages and you might have unexpected matches..