Forum Discussion

cdjac0bsen's avatar
cdjac0bsen
Icon for Nimbostratus rankNimbostratus
Jan 13, 2016

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

 

ASM Advanced WAF
security

2 Replies

Sort By
  • Sec-Enabled_658's avatar
    Sec-Enabled_658
    Icon for Cirrostratus rankCirrostratus
    Jan 14, 2016

    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 "Violation PageWe are sorry, but their is a problem with you request: $errorcode 
Your support ID is: [lindex $x 1] ."

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


     }  
}
  • Sec-Enabled_658's avatar
    Sec-Enabled_658
    Icon for Cirrostratus rankCirrostratus
    Jan 14, 2016

    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.