Downloaded 50 times
Uploaded byBrian A. McHenry
Death of WAF - GoSec '15
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.
More Related Content
![Carlos García - Pentesting Active Directory [rooted2018]](https://cdn.slidesharecdn.com/ss_thumbnails/carlosgarcia-slides-180312234839-thumbnail.jpg?width=640&height=640&fit=bounds)
![Carlos García - Pentesting Active Directory Forests [rooted2019]](https://cdn.slidesharecdn.com/ss_thumbnails/carlosgarcia-rooted2019-pentestingactivedirectoryforests-public-190403185357-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Death of WAF - GoSec '15
Death of WAF - GoSec '15
- 1. The Death ofWebApp Firewall Brian A. McHenry Sr. Security Solutions Architect, F5 @bamchenry ( as we know it )
- 2. Agenda • Brief primeron 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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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 aWAFwork?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
- 17. That sounds reallygood, but…
- 18. Who Owns theWAF? NetworkTeamApp DevTeamSecurityTeam
- 19.
- 20. My kingdom foraWAF admin! WAFAdministrator
- 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
- 22.
- 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 Headerscan 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
- 28.
- 29. What’s a HeavyURI? • Any URI inducing greater server load upon request • Requests that take a long time to complete • Requests that yield large response sizes
- 30. © F5 Networks,Inc 30CONFIDENTIAL • Attackers are proficient at network reconnaissance • They obtain a list of site URIs • Sort by time-to-complete (CPU cost) • Sort list by megabytes (Bandwidth) • Spiders (bots) available to automate • Though they are often known by the security community • Can be executed with a simple wget script, or OWASP HTTP Post tool Tools and Methods of L7 DoS Attacks
- 31. Exploiting POST forFun & 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
- 32. © F5 Networks,Inc 32CONFIDENTIAL • Drag through existing relevantWAF features • Understand your risk factors and have the proper tools • WAF placement can enhance other aspects of the App Long Live theWeb App Firewall
- 33.
Editor's Notes
- #4 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
- #5 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
- #6 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
- #7 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
- #8 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
- #9 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
- #10 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
- #11 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
- #12 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
- #13 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
- #14 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
- #15 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
- #16 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
- #17 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
- #19 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.
- #20 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.
- #21 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.
- #25 Java code resends request
- #29 Chrome Machine 1 IE Machine 1 Chrome Machine 2 logged into same account Chrome ios logged in to same acocunt
- #31 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).
- #32 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!
- #33 Protocol Compliance, broad spectrum signatures BOT/Heavy URL/Brute Force/Scraping TLS and TCP