[WASC-WAFEC] WAFEC 2 outline

Erwin Huber erwin.huber at ergon.ch
Thu Nov 15 04:57:59 EST 2012


Dear WAFEC readers and contributors

I'm Erwin Huber - Head of R&D Web Application Security at Ergon Informatik AG.
Ergon is the vendor of the web application firewall Airlock. WAFs have been the
core of my professional life for the last 10 years.

My post comes in the last minute - since I didn't realize, that wafec 2 was
growing. Sorry for that.

I appreciate the new approach for the document a lot. To focus on benefits 
rather than internas is a userfriendly approach.

In chapter 2.2 I suggest the following new Use Cases:
2.2.5 Authorization and Authentication
2.2.6 Architecture Masking
2.2.7 Data Leakage Prevention

Authorization and authentication is a relevant part of the "swiss-style" WAFs.
This is not only Airlock but also Nevis Proxy from Adnovum and Secure Entry
Server from United Security Providers. Its a good filtering technique to check
the users first if you know that only well known users are allowed on a system.
Airport security does the same thing.

Architecture masking is a benefit that reverse proxy are bringing. There is
no information about what logic is implemented on which back-end system.

Today's WAFs (including Airlock) are not good in Data Leakage Prevention. But I 
think an organisation has an interest in defining types of data which must not 
leave the perimeter (e.g. unmasked credit card numbers).
Web applications are not the only path infromation can leave a system - so I'm
not sure but it's at least worth discussing the issue.

2.3 Minimum Requirement
I don't think this is very useful. The minimum highly depends on the needs and
the use case. As a common minium I see "do something more than a traditional 
firewll on http/https checks". I just don't see the point.


3.3.1 Positive Security
What is the meaning of "URL rewrite and REST interface support"?

I propose as additional content in the paragraph "generic positive security" - 
this might include automated general protection techniques such as cookie
protection, form parameter signatures, url encyrption/signing (workflow 
binding, anti forceful browsing, anti csrf), declarative whitelisting (the 
back-end application defines characteristics of parameters - such as pattern 
in web forms 2.0).

3.3.5 Session Tracking
I propose the additional content "client fingerprinting".

I propose the additional paragraphs:
3.3.6 Content Modification
for DLP, hiding of error pages, ...
3.3.7 Upstream Authentication


4.3.2 Authentication Support
I'm astonished about the mention of NTLM. For me its a bug not a feature to 
allow NTLM authentication on a public accessible server. NTLM relaying is a
known real problem for more than 10 years. Even MS says "do not use NTLM".
Zack Fasel presented his "ZackAttack" Tool on BlackHat 2012:
https://github.com/zfasel/ZackAttack
A good WAF must have the ability to prevent NTLM authentication - not allow
it.

I propose the additional paragraphs:
4.3.3 Application Monitoring and Load Balancing
Monitor the health state of a back-end server and take measurements
(display not-available page, switch to another server instance, ...)

Defining more than one back-end host providing the same content allows an
SSL endpoint (such as reverse proxy) session-aware load balancing. All requests
for the same user session are reliable on the same back-end system.


5.1 Managment
Why is there no mention for "web interface"?


6.1 Non-technical Criteria
(just a typo in the title)


I'd be more than happy to provide content for the additional sections I propose
above.


Any thougths / comments on my propositions?

best regards
erwin




More information about the wasc-wafec mailing list