Notes:
- This is only a draft.
- Little formatting was done for now when copying from MS-Word
- MS-Word comments are listed at the bottom and are not easy to follow
- If you prefer the original MS Word format, you can find it here.
3 Security
3.1 Threat landscape coverage
Evaluation guidelines: For each one of the threats listed below evaluate the WAF detection and mitigation capabilities using the following methods:
- ·
- ·
- · List the detection and mitigation techniques (from those listed in section ### or others) used by the WAF to detect and mitigate each theat[AS1] .
Since many of the threats below address a broad array of attacks, note that the WAFs coverage for a specific threat may be partial, for example limited to specific types of applications.
A WAF main function is to protect web applications from attacks. To do so, it has to detect and potentially mitigate attacks. Therefore a key criterion for WAFs is their ability to detect and mitigate attacks.
WAFEC uses the Web Application Security Consortium Threat Classification[1] (WASC-TC) as the base list of threats that a WAF should detect and mitigate. Some threats cannot be effectively detected or mitigated by a WAF and therefore are omitted (see appendix ### for a list of those). Note that WAFEC does not provide descriptive text of threats and the reader is encourages using the original WASC TC description.
You may find the WASC TC Taxonomy cross reference[2] useful if you would like to establish a WAF threat coverage with regard to other taxonomies such as CW, the OWASP top 10 and SANS top 25.
The threats against which the WAF should be evaluated are:[AS2]
3.2.1 Passive Response
Passive response actions are ones that a WAF may take in response to detected attacks or application errors that do not disrupt the transaction in an perceivable way.
|
A.
|
Increasing Client Anomaly Scores
|
WAF may track anomaly scoring for the client over multiple transactions and then apply an active response action at a later time.[AS14]
|
|
B.
|
Increase Logging for Client
|
WAF may mark the client as suspicious and log full transactions for a period of time regardless of whether the client triggers any alerts.
|
|
C.
|
Email Alerts
|
WAF may send out email alerts to notify security personnel.[AS15]
|
|
D.
|
Request Header Tagging
|
WAF may export alert meta-data and alter the transaction to add new request headers. This data may be used to share data with the back-end web application or fraud detection systems.[AS16]
|
|
E.
|
Notify Network Infrastructure
|
WAF may notify networking infrastructure components such as a Firewall and make policy changes to temporarily block further access from the client source IP address.[AS17]
|
3.2.2 Active Response
Active response actions are ones that a WAF may take that apply disruptive actions to either the current or future transactions. Your security policy may require specific responses once an attack is detected. Those responses depend on the deployment mode used and attack detected as described in the table.
|
A.
|
TCP Reset
|
WAF will send spoofed TCP RST/FIN packets in an attempt to forcefully terminate the connection.
|
Network placement is critical for effectiveness.[AS18]
|
|
B.
|
Block the Client Source Address
|
WAF may temporarily block the client IP address from accessing the application.
|
Blocking based on client IP address may deny legitimate users who are using the same IP address. Attackers may also easily use a different IP address.
|
|
C.
|
GeoLocation Restrictions
|
WAF may utilize GeoLocation data to either deny or allow access to the application under certain situations.
|
May decide to block access from locations with high fraud rates or to only allow certain locations when under heavy attack.[AS19]
|
|
D.
|
Redirection to Error Pages
|
WAF may issue HTTP Redirection response that will send the user to an informative web page describing the reason for the blocking.
|
Error pages could provide detailed data for resolution by contacting support or helpdesk.[AS20]
|
|
E.
|
Forcing Transaction Delays
|
WAF may apply transaction delays to slow down attacker traffic.
|
May allow more time for incident response personnel to respond.
|
|
F.
|
Spoofing Successful Attack Responses
|
WAF may alter response data to simulate a successful attack.
|
May allow more time for incident response personnel to respond.
|
|
G.
|
Proxying Traffic to Honeypots
|
WAF may selectively proxy attacker traffic to an isolated honeypot system.
|
May allow more time for incident response personnel to respond.[AS21]
|
|
H.
|
Forcing an Application Logout
|
WAF may use the active SessionID to spoof an application logout request.
|
May not work well if the application does not properly invalidate the SessionID witin the application.[AS22]
|
|
I.
|
Temporarily Blocking User Access
|
WAF may temporarily deny access to the application for a specifc user.
|
WAF must be configured to track the proper user logon parameter value.
|
3.2.3 Intrusive Response[AS23]
Under certain circumstances, it may be necessary for the WAF to interact directly with the end user or their browser rather than the HTTP connection. Here are a few options:
|
A.
|
Forcing CAPTCHA Test
|
WAF will redirect user to a CAPTCHA testing page.
|
Helps to identify automated tools.
|
|
B.
|
Javascript Cookie Testing
|
WAF may send Javascript to the client that will create a new Cookie.
|
Helps to identify automated tools.
|
3.3 Protection techniques[AS24]
Evaluation guidelines:
While the key to the effectiveness of WAF is the end result: which threats it protects from, protection techniques and their implementation do affect the quality of the protection provided. Use this section to evaluate the quality of the implementation of the different protection methods.
3.3.1 Protocol Validation[AS26]
3.3.2 Positive Security
Positive security model is a comprehensive security mechanism that provides an independent input validation envelope to an application. By defining rules of allowed user input for every parameter in every page in the application the application is protected by an additional security envelop independent from its code.
3.3.3 Learning
The limitation of this a positive security model is that it requires deep knowledge of the application and a considerable on going effort to maintain the rule set. The maintainer needs to define such rules for each parameter and page in the application. Essentially the rules have to follow closely the application and every change in the application requires a modification to the rule set as well.
In order to reduce the effort required, different learning mechanisms have been implemented. In a session based learning approach rules are dynamically created based on previous transactions in the session. Specifically, based on forms returned by the web server the WAF generates validation rules for input submitted using this form by a user, validating field existence, length and special attributes such as "hidden" or "read-only". Other dynamic validation rules include rules limiting the allowed URLs only to those appearing in links in previous pages and rules limiting cookie values. However, this approach is limited since the information sent by the server does not convey all the information required to generate a rule. For example, the type of a parameter is not available. Furthermore, this method became nearly obsolete with the major shift to client side scripting, interactive web front ends such as AJAX [find] and web services. In all these technologies the client sends requests that are not based on previous server responses or are hard to determine from the responses.
More recently anomaly based learning approach was suggested. In anomaly based approach an input validation profile is created for an application based on observing real usage traffic and determining normal usage patterns. As with most anomaly based detection techniques, the key challenges are differentiating between attacks and non malicious abnormal traffic, not including in the normal usage profile information derived from attacks and compensating for time based variability in the usage profile.
Differentiating attack traffic from non malicious abnormal traffic is a major challenge for monitoring systems, but is less severe for protection only systems as many non attack abnormal requests can be blocked as they would not generate useful results. The problem can be further reduced by using a detected anomaly only as an indicator and determining an attack only based on multiple indicators, both anomaly based and other.
3.3.4 Virtual Patching[AS27]
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:
- · URL rewrite and REST interface support
3.3.5 Signatures[AS28]
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:
- · Used defined signatures[AS29]
- · Granularity of signatures[AS30]
- · Frequency of vendor update
- · Are updates automated?[AS31]
- · Complexity supported by signatures[AS32]
- · Exceptions supported[AS33]
- · Learning supported[AS34]
- · Anti-Evasion techniques[AS35]
- · URL rewrite and REST interface support[AS36]
3.3.6 Session Tracking[AS37]
<Please add description>
<Please add criteria. For an example of writing criteria refer to the “deployment option” section>
Example Criteria:
- · Automated session identification
- · User defined session identification
[1] WASC Threat Classification: http://projects.webappsec.org/w/page/13246978/Threat%20Classification
[2] WASC Threat Classification Taxonomy Cross Reference: http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%20View
[AS1]What for? How does it help with evaluation?
[AS2]Seems to me that granularity of mitigation techniques is too high. We need to probably classify techniques into a two dimensional matrix: Positive Security / Negative Security and Reactive / Proactive mitigation (this is different than active / passive response). Abuse of functionality (WASC-42)? Format string? (WASC-06)? Open redirect? Insecure indexing?
[AS3]Many attacks are missing here – session hijacking, cookie poisoning, parameter tampering
[AS4]RFI? LFI? General injection? Header injection?
[AS5]Negative security model is not necessarily signatures. A negative security model looks for patterns of the attack rather than abnormal behavior.
[AS6]What is virtual patching and how is it different than “negative security model input validation”
[AS7]Scraping? Scalping? Scanning?
[AS8]This is by far not the only method. What about CAPTCHA, anti-scraping? Anti Scanning?
[AS9]This is BS. Ultimately this is Improper Input Handling. You may suggest scrubbing output. Also, I can think of many other techniques.
[AS10]Forceful browsing?
[AS11]Huh?
[AS12]One MUST make the distinction between two issues here. One is leakage through an exploit (e.g. SQL injection) – in which case passive signature based mitigation is (to some extent) reasonable. The other is where the leakage itself is a vulnerability – comments, internal IP addresses, etc. in which case passive signatures are useless and a more proactive masking solution is required.
[AS13]What is the evaluation method? What is the evaluation criteria?
[AS14]This is a bit odd and seem out of context. Especially with respect to the security threats listed above.
[AS15]This is to some extent similar to E and should fall probably under the integration with other systems (which has a section of its own)
[AS16]This can hardly be considered passive. I also find it a bit awkward that the WAF delegate security back to the application when the first and foremost reason for having a WAF is to take security out of the application and remove the need for adding more security code to the application.
[AS17]This should either be delegate to integration with other systems (a section of its own). Alternatively I think that we should put forward a number of mechanisms including SYSLOG, SNMP and execution of arbitrary OS scripts.
[AS18]Should be “drop the connection”. The technique of sending RST/FIN and how should be left to implementation.
Also, I fail to understand the role of this column
[AS19]This is an instance of the above.
[AS20]I think that the general issue is “display a customized error page”. Whether this is done through redirection or otherwise is immaterial. We can further break this capability into more granular ones such as: ability to redirect, ability to include information about the alert, etc.
[AS21]I personally believe that this is a waste of time and resources both for the device and the incident response personnel.
[AS22]I think that the more general requirement here is to drop the session. Whether this is achieved by invoking logout functionality or just dropping any request for the same session is left to implementation
[AS23]This is not necessarily a response but part of the detection
[AS24]Seems to be very raw. I think this is in general “detection mechanism” and they should be split into reactive and proactive. Mechanisms like “IP reputation” or “GeoLocation” are missing. No “proactive” mechanism is mentioned (CAPTCHA, Anti-Automation, Anti-bot). These appear above in the “intrusive response” but actually belong here.
[AS25]I’m not sure this is helpful + I’m not sure the process is clear from the description
[AS26]Should we list the basic ones? All of them?
[AS27]Virtual patching is not a technique but rather a deployment model!
[AS28]Pattern matching? What about other negative security rules?
[AS29]Probably a topic of its own about user defined security
[AS30]What do you mean here?
[AS31]I think that vendor updates is a topic of its own
[AS32]??????
[AS33]Management and GUI?
[AS34]????????
[AS35]This is a topic of its own.
[AS36]????????
[AS37]We should probably add a list of items that should be tracked under “session” – cookies, read-only parameters, user name, etc.
Comments (0)
You don't have permission to comment on this page.