[WASC-WAFEC] WAFEC 2 outline

Ofer Shezaf ofer at shezaf.com
Thu Nov 15 15:21:38 EST 2012


Hi Erwin,

The document I shared is only an outline. I included some text to make the sections intention more clear but there are in no way comprehensive. The people volunteering to write the different sections will fill them in and I am sure would take into consideration your input.

To that end: do you want to take one of the remaining chapters to write? Should I list you on the contributors page (http://projects.webappsec.org/w/page/54150727/WAFEC%202)

I do have a few of your remarks outside of the context of a specific chapter:

* We regard to your additions to the use cases chapter: we had a discussion about what to include in the definition and use cases for a WAF . This is not an easy subject and also prone to vendor bias (for each vendor the functionality they provide is a WAF). The decision was to be restrictive to application protection as described in chapter 3 (which itself is still not written). As other features can be very beneficial to the customer as well, even for security, we decided to include all those in an appendix (6.1, "Integrated functionality"). In this framework, each of the additional features you suggest (Authorization and Authentication, DLP, Architecture masking, load balancing and application monitoring are those I notices) should find their place in either section 3.3 if they offer a protection technique or in section 6.1 if they are complementary and of value but do not cover a threat.

* Minimum requirements is indeed a challenging section, however I think it is important. Otherwise you will find that any IPS or network firewall can be labeled as a WAF (or an Espresso Machine :-))

* Section 4.3 address compatibility with web applications rather than addition features for application delivery.


~ Ofer

-----Original Message-----
From: Erwin Huber [mailto:erwin.huber at ergon.ch] 
Sent: Thursday, November 15, 2012 11:58 AM
To: Ofer Shezaf
Cc: wasc-wafec at lists.webappsec.org
Subject: WAFEC 2 outline

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