EvaluWAF can check which features a WAF provides. This page shows the currently supported feature tests.
To prevent the exposure of a web application structure,
a WAF can replace all internal URLs in an outgoing HTML document. For example,
the URL /invoice/42.pdf could be changed into something like this:
/618aa387071a615a869aee49. The WAF internally stores the original URL,
so it can request the original resource from the web application.
EvaluWAF checks this feature by requesting a page with an internal link. If this link is included in the response, then the WAF doesn't support this feature.
To prevent the exposure of cookies, a WAF can encrypt cookies so that external clients never see its original value. If a request contains an encrypted cookie, the WAF decrypts it before forwarding the request to the web application.
EvaluWAF checks this feature by requesting a page which sets a known cookie. If the response has this known cookie unchanged in the header, then the WAF doesn't support this feature.
To prevent cookie tampering, a WAF can sign outgoing cookies and check incoming. Modified cookies should be rejected.
EvaluWAF checks this feature in two steps. In the first step, a script is requested which sets a cookie in its response. EvaluWAF then requests another script with a modified cookie in the request. The second script returns the cookie's value in the response. If the modified value is in the response, then the WAF didn't rejected the modified cookie and therefore doesn't support this feature.
To prevent that a cookie is transferred via an unencrypted HTTP connection, the secure
attribute can be added to a Set-cookie header. Then, a browser should send such a cookie
only in HTTPS requests.
EvaluWAF checks this feature by requesting a script which sets a cookie without this attribute. If the response contains the secure attribute, then the WAF added it and supports this feature.
To prevent that a script can access a cookie in the browser, the attribute HttpOnly can be set. Then, a browser only uses such a cookie for HTTP request but not allows scripts to access it.
EvaluWAF checks this feature by requesting a script which sets a cookie without this attribute. If the response contains the HttpOnly attribute, then the WAF added it and supports this feature.
To prevent that an attacker includes new cookies in the request, a WAF can reject unknown cookies which weren't been set before.
EvaluWAF checks this feature by requesting a script with a random cookie. The script includes the received cookies in the response. If the response contains the random cookie value, then the WAF doesn't supports this feature.
To prevent that users upload malware or viruses, some WAFs uses virus scanners to inspect uploaded data.
EvaluWAF checks this feature by uploading the EICAR Anti-Malware/Virus testfile. This "test virus" should be detected from every anti virus software. If the WAF detects the virus, it should reject the upload. Else, the script will return the virus test file to the client and EvaluWAF note that the WAF doesn't support this feature.