Blocking insecure log-in page

Hey Joel,

 

 

The ASM should be aware of HTTP versus HTTPs objects depending upon which port the request arrives on. With this you could use a few possible solutions.

 

 

a) Create a parameter for the HTTP object (perhaps even flow parameters with 'Mandatory Parameter' checked. This could be a static parameter with an obscure (totally random?) single value in the static list and would mean that unless someone knew the (hopefully) obscure/random parameter name *and* value that they would be blocked when accessing this page. This would probably get you by the auditor evaluation, but there is a possibility, no matter how remote, that somebody would either know, guess, or fuzz the parameter name and value and access the page. The cleaner solution is (probably):

 

 

b) Assuming that you use two different virtual servers for this traffic (a port 80 and a port 443) you could create an HTTP Class for the port 80 virtual server that matched this URI and then redirected the traffic to its HTTPS equivalent, while the normal class with a more broad match remains to process all other traffic.

 

 

c) I suppose, though I haven't tested this, that depending on what your current HTTP objects look like, you could create a wildcard HTTP object that would also match this page. Either '*' or even "/store/user/*" and then apply an attack signature that would block on uricontent of "/store/user/login.jhtml". Since you (presumably) have this object specifically defined as an HTTPS object, the object would take precedence over the signature and *should* only trigger for the HTTP objects that it matches.

 

 

I could _probably_ keep going, but one of these should get things going for you. Let me know how it goes! =]

 

 

// Ben