1. TOPIC: Web Application Firewall & Fuzzers
Course : WEB ENGINEERING
Paper Code: ETCS-308
TOPIC: Web Application Firewall & Fuzzers

2. Web Application Firewalls
A software or hardware solution that protects your web enabled applications from threats/attacks.
The solution must understand web protection at the application layer (HTTP and HTTPS conversations to your web applications, XML/SOAP, and Web Services).
Detect/prevent OWASP Top Ten Threats.
A Web Application Firewall (a.k.a. WAF), by contrast, is like placing an eavesdropping agent right next to the Web server.
WAFs are an important building block in every HTTP network.

3. Web Application Firewalls
Database Server
Web Client
Web Server
Application
HTTP Traffic
Port 80

4. WAF Features Full support for HTTP:
Access to individual fields (field content, length, field count, etc).
Entire transaction (both request and response).
Uploaded files.
Anti-evasion features (also known as normalisation/canonicalisation/transformation features).

5. WAF Features Blocking features: Transaction Connection IP Address
Session
User
Honeypot redirection
Blocking via external device

6. Protection Techniques
Cookie protection
Sign/encrypt/virtualise
Hidden field protection
Session management protection
Enforce session duration timeout, inactivity timeout.
Prevent fixation.
Virtualise session management.
Prevent hijacking or at least warn about it.

7. Protection Techniques
Brute-force protection
Link validation
Signing
Virtualisation
Request flow enforcement
Statically
Dynamically

8. Performance Metrics Performance: New connections per second.
Maximum concurrent connections.
Transactions per second.
Throughput.
Latency.

9. Signatures and Rules Signatures Rules
Simple text strings or regular expression patterns matched against input data.
Not very flexible.
Rules
Flexible.
Multiple operators.
Rule groups.
Anti-evasion functions.
Logical expressions.
Custom variables.

10. Three Protection Strategies
External patching
Also known as "just-in-time patching" or "virtual patching”.
Negative security model
Looking for bad stuff.
Typically used for Web Intrusion Detection.
Easy to start with but difficult to get right.
Positive security model
Verifying input is correct.
Usually automated, but very difficult to get right with applications that change.
It's very good but you need to set your expectations accordingly.

11. Web Intrusion Detection
Detection is so old.
Prevention is better.
The problem with prevention is that it is bound to fail given sufficiently determined attacker.
Monitoring (logging and detection) is actually more important as it allows you to independently audit traffic, and go back in time.

12. Monitoring Requirements
Centralisation.
Transaction data storage.
Control over which transactions are logged and which parts of each transaction are logged, dynamically on the per-transaction basis.
Minimal information (session data).
Partial transaction data.
Full transaction data.
Support for data sanitisation.

13. Fuzzers
A Security fuzzer is a tool used by security professionals (and professional hackers :) to test a parameter of an application.
Fuzzing is to execute a program on many abnormal inputs, look for badness.
Goal: Prevent attackers from encountering exploitable errors
Automatically generate test cases
Many slightly anomalous test cases are input into a target interface
Application is monitored for errors
Inputs are generally either file based (.pdf, .png, .wav, .mpg)
Or network based
http, SNMP

14. Mutation Based Fuzzing (Dumb Fuzzing)
Little or no knowledge of the structure of the inputs is assumed
Anomalies are added to existing valid inputs
Anomalies may be completely random or follow some heuristics (e.g. remove NUL, shift character forward)

15. Dumb Fuzzing In Short Strengths Weaknesses
Super easy to setup and automate
Little to no protocol knowledge required
Weaknesses
Limited by initial corpus
May fail for protocols with checksums, those which depend on challenge response, etc.

16. Generation Based Fuzzing
Test cases are generated from some description of the format.
Anomalies are added to each possible spot in the inputs
Knowledge of protocol should give better results than random fuzzing

17. Generation Based Fuzzing In Short
Strengths
completeness
Can deal with complex dependencies e.g. checksums
Weaknesses
Have to have spec of protocol
Often can find good tools for existing protocols e.g. http, SNMP
Writing generator can be labor intensive for complex protocols
The spec is not the code

18. Fuzzing Tools- Input Generation
Existing generational fuzzers for common protocols (ftp, http, SNMP, etc.)
Mu-4000, Codenomicon, PROTOS, FTPFuzz
Fuzzing Frameworks: You provide a spec, they provide a fuzz set
SPIKE, Peach, Sulley
Dumb Fuzzing automated: you provide the files or packet traces, they provide the fuzz sets
Filep, Taof, GPF, ProxyFuzz, PeachShark

19. Input Inject Simplest Modify existing program/client
Run program on fuzzed file
Replay fuzzed packet trace
Modify existing program/client
Invoke fuzzer at appropriate point

20. Problem Detection See if program crashed
Run program under dynamic memory error detector
Catch more bugs, but more expensive per run.
See if program locks up
Roll your own checker

21. Workflow Automation
Sulley, Peach, Mu-4000 all provide tools to aid setup, running, recording, etc.
Virtual machines can help create reproducable workload
Some assembly still required

22. Example: PDF I have a PDF file with 248,000 bytes
There is one byte that, if changed to particular values, causes a crash
This byte is 94% of the way through the file
Any single random mutation to the file has a probability of of finding the crash
On average, need 127,512 test cases to find it
At 2 seconds a test case, thats just under 3 days...
It could take a week or more...

23. Code Coverage
Some of the answers to these questions lie in code coverage
Code coverage is a metric which can be used to determine how much code has been executed.
Data can be obtained using a variety of profiling tools. e.g. gcov

24. Types of Code Coverage Line coverage Branch coverage Path coverage
Measures how many lines of source code have been executed.
Branch coverage
Measures how many branches in code have been taken (conditional jmps)
Path coverage
Measures how many paths have been taken

25. Fuzzing Rules of Thumb Protocol specific knowledge very helpful
Generational tends to beat random, better specification make better fuzzers
More fuzzers is better
Each implementation will vary, different fuzzers find different bugs
The longer you run, the more bugs you find
Best results come from guiding the process
Code coverage can be very useful for guiding the process

26. THANK YOU