The document describes how traditional web application firewalls (WAFs) work by checking requests against rules for things like RFC compliance, URL and parameter validation, length limits, and attack signatures. However, the document argues this approach will become outdated as applications evolve and new attacks emerge. A new approach is needed for WAFs to stay relevant and enhance application security.
1. The Death ofWeb App Firewall
Brian A. McHenry
Sr. Security Solutions Architect, F5
@bamchenry
( as we know it )
2. Agenda
• Brief primer on traditional WAF approach
• Why this approach will (and should) die
• HowWAF can stay relevant and enhance your AppSec practice
• Why a new approach is valuable
3. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
4. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1rn
Host: foo.comrnrn
Connection: keep-alivernrn
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9rn
Referer: http://172.29.44.44/search.php?q=datarnrn
Accept-Encoding: gzip,deflate,sdchrnrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rnrn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rnrn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226rn
5. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
6. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
7. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
8. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
9. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.asp?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
10. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.do ?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
11. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
12. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /login.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
13. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /logout.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
14. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
15. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
16. How does aWAF work?Start by checking RFC compliance1
Then check for various length
limits in the HTTP
2
Then we can enforce valid types
for the application
3
Then we can enforce a list of valid
URLs
4
Then we can check for a list of
valid parameters
5
Then for each parameter we
will check for max value length
6
Then scan each parameter,
the URI, the headers with
attack signatures
7
GET /search.php?name=Acme’s&admin=1 HTTP/1.1
Host: foo.comrn
Connection: keep-alivern
User-Agent: Mozilla/5.0 (Windows NT 6.1)rn
Accept:text/html,application/xhtml+xml,application/xml;q=0.9r
Referer: http://172.29.44.44/search.php?q=datarn
Accept-Encoding: gzip,deflate,sdchrn
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6rn
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3rn
Cookie: SESSION=0af2ec985d6ed5354918a339ffef9226
21. With Great Power…
• Each web application is a snowflake!
• Application deploys can be too frequent forWAF policy tweaks
to keep up.
• In DevOps environments, continuous delivery enables rapid vuln
fixes in code.
WAFAdministrator
23. What’s left forWAF?
• Focus on non-snowflake problems
• Extend and enrich web applications where possible
• Behavioral analysis
24. WAF-based Bot Detection
• WAF injects a JS challenge with obfuscated
cookie
• Legitimate browsers resend the request with
cookie
• WAF checks and validates the cookie
• Requests with valid signed cookie are then
passed through to the server
• Invalidated requests are dropped or terminated
• Cookie expiration and client IP address are
enforced – no replay attacks
• Prevented attacks will be reported and logged
w/o detected attack
1st time request
to web server
Internet
Web
Application
Legitimate browser
verification
No challenge
response from bots
BOTS ARE
DROPPED
WAF responds with
injected JS challenge.
Request is not passed
to server
1
JS challenge placed
in browser
2
WAF verifies
response
authenticity
Cookie is signed,
time stamped and
finger printed
4
Valid requests are
passed to the
server
5
Browser
responds to
challenge &
resends request
3
Continuous invalid bot
attempts are blocked
Valid browser requests
bypass challenge w/
future requests
25. Headers!
• HTTP Headers can force browser to take more secure actions
• Application agnostic
• Examples:
• HTTP StrictTransport Security
• HTTP Public Key Pinning
• Content Security Policy
• X-Frame-Options
OR
26. Protocol Compliance Checks
• HTTP Protocol compliance, of course.
• Mitigates attacks like SlowLoris, and other timing attacks.
• But also,TLS protocol and cipher enforcement
• Centralized control of allowed ciphers and protocols
• Protection from vulnerabilities like Heartbleed, FREAK, LogJam, Poodle
• TCP handshake enforcement
• Full proxyWAF should be able to detect idleTCP sessions, reducing load on web app servers
27. Behavioral Analysis & Fingerprinting
• Detect GET flood attacks against Heavy URI’s
• Identify non-human surfing patterns
• Fingerprinting to identify beyond IP address
• Track fingerprinted sessions
• Assign risk scores to sessions
• Identify known malicious browser extensions
• https://PanOpticlick.eff.org for a primer on the topic
29. What’s a Heavy URI?
• Any URI inducing greater server load upon request
• Requests that take a long time to complete
• Requests that yield large response sizes
31. Exploiting POST for Fun & DoS
•Determine:
• URL’s accepting POST
• Max size for POST
•Bypass CDN protections (POST isn’t cache-able)
•Fingerprint both TCP & app at the origin
Attackers work to identify weaknesses in
application infrastructure
Network Reconnaissance Example
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
This is a high level overview… I thought we could highlight each area in the request when explaining what we do…
Start by checking RFC compliance – for example, that there is a method like GET/POST in the beginning of the message, or that every line ends with \r\n , or that the protocol version is valid (HTTP/1.1), that there is HOST header, that the straucture of the header is good (every header has a value).
Then we check for various Length limits on the HTTP message, for example, the full HTTP message length , or the URI length (/search.php) or the query string length (name=Mc’donalds&admin=1), we count the number of headers, we check for cookie max size and header max size
Then we can enforce valid types for the application, for example, only php, jpeg, doc and pdf.
Then we can enforce a list of valid URLs (/search.php)
Then we can check for a list of valid parameters (name and admin)
Then for each parameter we will check for max value length (data and 1 in this case) valid metacharacters in the value for each paramater (in this example the ‘ metacharacter needs to be allowed in the name parameter. We could also scan the
Then before we serve the request to the web server, we will scan each parameter , the URI, the headers with attack signatures
Network team doesn’t have intimate knowledge of the application, and lacks the confidence to make policy tweaks for fear of false positive.
Security team often lacks the necessary personnel to support the full-time task of tweak WAF policy for every application change.
App dev team lacks the network skills for managing the appliance aside from the WAF policy.
Network team doesn’t have intimate knowledge of the application, and lacks the confidence to make policy tweaks for fear of false positive.
Security team often lacks the necessary personnel to support the full-time task of tweak WAF policy for every application change.
App dev team lacks the network skills for managing the appliance aside from the WAF policy.
Network team doesn’t have intimate knowledge of the application, and lacks the confidence to make policy tweaks for fear of false positive.
Security team often lacks the necessary personnel to support the full-time task of tweak WAF policy for every application change.
App dev team lacks the network skills for managing the appliance aside from the WAF policy.
Java code resends request
Chrome Machine 1
IE Machine 1
Chrome Machine 2 logged into same account
Chrome ios logged in to same acocunt
Remember the 2012 attacks against the US banks? Well, attackers have become even more sophisticated in their network reconnaissance. Not only that, while the sophistication has sharply increased, the tools and coordination required to do this type of profiling have become well-automated and easily accessible. These types of activities are no longer the domain of the Fully Targeted, state-sponsored attacker. The so-called script kiddies and Hacktivists have latched onto these tools, and these types of attacks are in the arsenal of the low-level Opportunistic attacker.
This is a new mitigation method intended to protect heavy URLs from DoS attacks. Heavy URLs are a small number of site URLs that might consume considerable server resources per request. This type of DoS attack is different from the existing URL mitigation because it takes only a low rate of requests to heavy URLs in order to cause DoS attacks. In addition to configuring heavy URLs, you can view latency information about web application URLs on the new URL Latencies screen (navigate to Security > Reporting > DoS > Application > URL Latencies).
A CDN exceeds at delivering cached content from global datacenters. Attackers know that unless they can force resource consumption at the origin server[DWH3] they will be unlikely to succeed in their attack. Typically a CDN will not process HTTP POST methods – these will be forwarded to the origin servers of the targets. In fact, in the DDoS Playbook mentioned above, the number one step in the pre-attack recipe is “Check whether a site accepts POST method…in the Web form”. Once a URL that accepts POSTs has been found, the attackers will test it to see how much data it will accept (say, 9999 bytes) before the POST is rejected. When they find the boundary, they know exactly how much data they can send during the real attack per connection.
The vulnerability of the POST method goes further. Because it acts as a “hole” in the CDN, the attackers know that they can use POST to determine the nature of the origin devices, including:
the TCP established state timeout value
the TCP first PSH/ACK timeout value
the TCP continuous ACK timeout value
the TCP first FIN_WAIT1 timeout value
the TCP last ACK timeout value
In this example, the attackers are performing network reconnaissance for layer 4 threat surfaces by using a layer 7 attack vector!