Has anyone been able to make Form Hardening and Cookie Hardening work?

To elaborate on how I though it was supposed to work, in pseduocode:

• Real webserver sends one cookie, which is intercepted by UTM:
  • "server="www.example.com", cookiename="SecretStuff", cookievalue="Bill loves Susie"
• UTM sends two cookies
  • server="www.example.com", cookiename="SecretStuff", cookievalue="Bill loves Susie"
  • server="www.example.com", cookiename="UTM$Signaturefor_SecretStuff", cookievalue="AQB3&699bbb"

UTM may ask for the signature cookie if hardening is enabled.   Whether hardening is enabled or not, UTM should detect and remove any signature cookies before passing the cookie list to the real webserver.

Form Hardening should work in roughly the same way:   UTM adds hidden fields with signature information, and removes those hidden fields when the data is returned.

So how can these features break a real webserver using data that the real webserver never sees?  

How can there ever be a form signature verification problem, other than when a client constructs a deliberately malicious form submission?

To elaborate on how I though it was supposed to work, in pseduocode:

• Real webserver sends one cookie, which is intercepted by UTM:
  • "server="www.example.com", cookiename="SecretStuff", cookievalue="Bill loves Susie"
• UTM sends two cookies
  • server="www.example.com", cookiename="SecretStuff", cookievalue="Bill loves Susie"
  • server="www.example.com", cookiename="UTM$Signaturefor_SecretStuff", cookievalue="AQB3&699bbb"

UTM may ask for the signature cookie if hardening is enabled.   Whether hardening is enabled or not, UTM should detect and remove any signature cookies before passing the cookie list to the real webserver.

Form Hardening should work in roughly the same way:   UTM adds hidden fields with signature information, and removes those hidden fields when the data is returned.

So how can these features break a real webserver using data that the real webserver never sees?  

How can there ever be a form signature verification problem, other than when a client constructs a deliberately malicious form submission?

Or maybe form field signatures are implemented as cookies rather than hidden fields.   Either technique should produce the same (transparent) result.

Which also begs the question, "Why are cookie hardening and form hardening interdependent?"  

Presumably, the answer is that the actual implementation is nothing like the one I described, which is also why it does not work the way I expect, if it works at all...

In Cookie Signing, Doug, I think this is a cookie sent to the client from the server and then intercepted by WAF.  WAF the creates a duplicate of the cookie, adds a "signature" and then presents the pair to the client.

Also in Form Hardening, I think this is the form requested by a client from the protected server.  WAF keeps a copy of the form to compare to confirm that the content of the original form was not changed.

I've had spotty luck and found that some sites are coded in such a way that neither hardening nor signing works.  Outside of sites that are required by compliance audits to "fix" their code so that it can be protected, I've not had much luck getting people to spend the money on their programmers.

I think they appear to be interdependent because of the underlying tool used to create the site and the programmers that produced the site.  In other words, they're just coincidental.

Again, this all is just my understanding, and I would welcome knowing what I've missed.

Cheers - Bob

Let me begin by noting that I talked to Support about these problems back when they first occurred, and the answer was that if form hardening or any other defense does not work, just turn it off.   There was no channel offered for pursuing the question, "but why does it not work?"   I have not gone back to them on this issue, but I have a hard time getting them interested in any topic that cannot be explained using TCPDUMP.

In your answer, you seem to have confirmed my statement of the problem.   WAF should be independent of, and transparent to, the real webserver.  The real webserver should not need to be custom-coded to make the WAF happy.   But even if one wanted to rewrite a real webserver to make the WAF happy, there is no design document from Sophos to guide the process.

When I was introduced to the idea of WAF during the sales cycle, Form Hardening was an easy idea to grasp:   If the form asks for a 5-character field, the WAF should ensure that the form submission receives no more than 5 characters in that field.   A classic attack vector seems to be "send 1500 characters in that field and see what breaks!"   Defending against that type of attack seemed like a conceptually feasible piece of code.

At this point, it seems like UTM WAF is good at URL hardening, but only that.   I see evidence of port scanners hitting my websites by IP address instead of host name.   If I get by WAFs into Reject mode, it will block those snoopers. It will also protect against path bypass attacks.    Other defenses, like SQL injection and Email injection, appear to be based on rules that are too simplistic, and therefore unusable.   Some defense is better than nothing, but UTM WAF is a lot less than I expected.

DouglasFoster said:

How can there ever be a form signature verification problem, other than when a client constructs a deliberately malicious form submission?

JavaScript for example. When JavaScript modifies a form request or adds new cookies, then for WAF that's indistinguishable from a maliciously tampered request.