Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Response status code block information

Was wondering how someone has handled keeping disallowed http response status codes away from hacker eyes yet allowed internal support to know what it was at a glance?

We use the rapid deployment template defaults which block "Illegal HTTP status code in response" and the default six Allowed Status Response Codes in our policies. While this is good security practice because it hides server errors from hackers trying to do recon on a site, this causes the ASM team many support calls because of the generic block response page when it's really a problem with the application and should be directed to the application team.

One possible solution we thought might be helpful would be to have a response page that included information not decipherable by a hacker, but that the app team would know it was a server error. Even better if they knew which status code was returned. We don't know if that kind of logic is allowed in the block response page or how to create such logic, if it is. Or, can this sort of thing only be accomplished with an iRule?

Thanks,

Chris

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Here is an Irule that I used to provide a way to correlate error codes with actual violations while not specifying the actual violation on the response page. In this Irule, I was handeling http response codes, but you could build on this to handle additional violations. The inside testers would know what error code correlated to which http response code. Ex. Error code 666 is actually a HTTP response code of "500" which is a violation


when HTTP_RESPONSE {
  set responsecode [HTTP::status]
#  log local0. "Response code is $responsecode"
}


when ASM_RESPONSE_VIOLATION
{
  set x [ASM::violation_data]
  #Set error code to 100/unknown
  set errorcode 100
  set supportid [lindex $x 1]
   
   switch $responsecode {
     "404" { set errorcode 777 }
     "500" { set errorcode 666 }
     "403" { set errorcode 888 }
   }
   
#      log local0. "Response code $responsecode "  
#      log local0. "Error code set to: $errorcode "  
  
   if {([lindex $x 0] contains "VIOLATION_HTTP_STATUS_IN_RESPONSE")}
    {
#      HTTP::header remove Content-Length
#      HTTP::header insert header_1 value_1

      log local0. "VIOLATION_HTTP_STATUS_IN_RESPONSE detected, modify response, support id : $supportid "
      set response "<html><head><title>Violation Page</title></head><body>We are sorry, but their is a problem with you request: $errorcode <br><br>Your support ID is: [lindex $x 1] .</body></html>"

      ASM::payload replace 0 [ASM::payload length] ""
      ASM::payload replace 0 0 $response  


     }  
}

0
Comments on this Answer
Comment made 14-Jan-2016 by cdjac0bsen 60
Hi Nathan, thanks for the input. I see where you're going with this. Since the response page would be different for http status violations, it would still give the hacker a clue that their input caused a server error, but this could probably be modified to be less obvious. Do you know if this kind of logic can be used in the custom response page rather than an iRule?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

The response page interface in the GUI allows you to put specific HTML, but in our scenario, we need to customize the response page based upon the violation. The Irule above, which produces a customized response page gives us the flexibility and scalability that we dont have in the GUI interface.

0