This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project. My notes are below:
WAF Fallacies (at least in regards to OWASP ESAPI WAF)
- WAFs add attack surface
- WAFs can create culture problems
- WAFs can't fix business logic vulnerabilities
- WAFs are way too expensive
- WAFs complicate networks
Why fix in ESAPI WAF vs Fix in code?
- Changing in ESAPI WAF is just a text file
- Shorter gap between time discovered and WAF fix vs code fix
Advantages of WAF
- Performance - Only your rules are checked, plus state is already managed by the app server
- Capability - being closer to the app lets us do more
- Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time
Principle: Make common tasks easy, uncommon tasks possible
General virtual patching functionality is easy to understand
Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy
Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)
Can add "outbound" security as well
- Add anti-clickjacking header
- Set uniform content-type
- Add HttpOnly flag
- Add secure flag
- Detect outbound information
- Replace outbound information
Takes advantage of early failing to make rules as optimized as possible
Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):
- Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
- Unchecked Redirect
- Add HttpOnly
- Add anti-clickjacking header
- Privilege escalation
3 Different WAF Modes
Latency with all of the rules turned on is about 5%. With selected rules is closer to 0%. Basically an order of n magnitude where n is the number of rules enabled. Comes out to milliseconds.
This presentation was by Michael Coates, the AppSensor Project Lead. Michael works as a Senior Application Security Engineer at Aspect Security. AppSensor is a real time defense system with the goal being to protect an application by detecting who is bad and getting rid of them before they do bad things. My notes from this session are below:
- AppSensor Project
- Malicious Attackers
- Application Worms
Detecting Attacks the Right Way
- Detect INSIDE the application
- Understand business logic
- Minimal false positives
- Immediate response
- Automatic detection
- No manual work required
Detection Outside the Application (WAF)
- Application context not available
- No concept of access violations
- Custom application + Generic Solution != success
- Ex: Changing the account ID in /viewAccount?id=1002
Inside the Application is Best
- Understand application & business context
- Integration with authentication & user store
How Does AppSensor Protect the App?
- Take many requests for an attacker to find a vulnerability
- Takes fewer requests by AppSensor to determine that the user is malicious
AppSensor is Faster than Attacker
- User identified as malicious and blocked before a vulnerability is found
Categories of Detection
- Access Control
- Command Injection
- File IO
- User Trend
- System Trend
Attack Detection: Real vs Cyber World
- Why do bank robbers get caught?
- Why don't hackers get caught?
Let's Change Things - Applications Should...
- Detect attacks
- Understand normal use vs suspicious use
- Instantly identify attackers
- Shutdown attackers in real time
- Modify application accessibility for defense
Detecting Malicious Users
- Many malicious attacks are obvious and not "user error"
- POST when expecting GET
- Tampering with headers
- Submissions of XSS attack
Detecting Malicious Users
- Bypassing client side input validation
- Transaction using functionality not visible to user role
- Multiple access control violations
- Change of user agent midsession
- Double encoded data
- Leverages ESAPI!
- 3 lines to setup AppSensor
- 2 lines per AppSensor detection point
Setting up AppSensor
- Configure response action object (log logout, account lock)
- Create AppSensorIntrusionDetector with response action object
- Set ESAPI intrusion detector
Defining Response Policies
- ESAPI.properties file
- Threshold count
- Interval of events
- Response action
- Per exception type or aggregate
2 Lines to Use AppSensor
- Check for "maliciousness"
- Create new AppSensorException
Understanding the Intrusion Exception
new AppSensorIntrusion Exception(
- "User Message",
- "Direct object tampering with ..."
AppSensor vs Scanners
- Tools attempt 10,000s of generic attacks
- AppSensor stops automated scans nearly instantly
AppSensor vs Human Attackers
- Very difficult for attacker
- Requires advanced obfuscation for each attack
- Multiple probes == detection
Application Worms on the Rise
- Twitter Worm
- MySpace Samy WOrm
- Huge damages for site
- Bad PR
- Infected Users
- Leverage XSS and CSRF
Detecting/Preventing an Application Worm
- Can you find/fix all XSS?
- Pattern matching easily foiled
- Block the common factor!
- Worms use XSS and CSRF for propagation
- 1000% usage increase -> problem
- Our example: updateProfile, updateStatus, updateName
Case Study: Samy
- MySpace Application Worm
- XSS worm embedded in User Profile
- Exponential Growth of Samy's friends
Samy vs AppSensor
- AppSensor detects uptick in addFriend usage
- Compares against trended info
- Automatic response initiated
- Alert admin +200% add friend usage
- Alerts admin 2nd time +500% add friend usage
- Automatically shuts down add friend feature
- Worm contained
- Add friend temporarily disabled
- Site stays up
Benefits of Trend Monitoring
- Detection of
- Application worms
- Scripted attacks/probing
- CSRF attacks
- Alerting of excessive activity
- Selective feature shutdown for overall stability
AppSensor in Action
- Demo social networking app
- Defended with AppSensor trend monitoring
What's Under the Hood?
- REST communication between AppSensor & App
- Support Response Actions (warn user, logout user, disable user, etc)
- Drools - Rule Based System
- Support for complex rule sets - much more than just counting feature usage
- Evaluates objects in Drools memory
- XSS infects victim's "Status" with worm
- CSRF adds victim as friend of Charlie
Defend with AppSensor
- AppSensor Policy
- Notify admin if events > 5
- Disable service if events > 10
- AppSensor notices anomaly - alerts admin
- After 10 events AppSensor disables just that feature of the site
- Users protected, worm contained, site stays up
Trend Monitoring Benefits
- Auto detection of attacks
This presentation was by Alexander Meisel and is from a paper that was put together by the Germany OWASP chapter. He began by introducing the problem being online businesses having HTTP as their "weak spot". Then talked about the definition of the term "Web Application Firewall". It's not a network firewall and not only hardware. The targeted audience of the paper is technical decision makers, people responsible for operations and security, and application owners. Next he talked about some of the characteristics of web applicatons with regard to security. Prioritize web applications in regard to their importance (access to personal customer data, access to confidential company information, certifications). Some technical aspects include test and quality assurance, documentaiton, and vendor contracts.
Where do WAFs fit into the web application security field? WAFs are part of a solution. Create a table with wanted functionality (CSRF, session fixation, *-Injection). Do a rating/evaluation with "+" meaning it can be very well implemented using a WAF, "-" meaning it can not be implemented, "!" meaning depends on the WAF/application/requirement, and "=" meaning it can partly be implemented with a WAF.
Looks at the benefits and risks of WAFs. Good baseline security. Compliance. Just-in-time patching of problems. Additional benefits (depending on functionality) could be central reporting and error logging, SSL termination, URL encryption, etc.
Some risks involved in using WAFs are false positives, increased complexity, having yet another proxy, and potential side effects if the WAF terminates the application.
Protection against the OWASP Top 10. App vs WAF vs Policy. Three types of applications: web application in design phase, already productive app which can easily be changed, and productive app which cannot be modified or only with difficulty. Table of OWASP Top 10 in regards to work required with the 3 types of applications to fix the problem in the application itself, using a WAF, and using a policy.
Criteria for deciding whether or not to use WAFs. Company wide criteria includes the importance of the application for the success of the company, number of web applications, complexity, operational costs, and performance and scalability. Criteria with regard to the web application includes changeability of the application, documentation, maintenance contracts, and time required fixing bugs in third-party products. Consideration of financial aspects includes avoidance of financial damage via successful attacks and teh costs of using a WAF (license, update, project costs for eval and WAF introduction, volume of work required/personnel costs).
He started going pretty fast here since he was already running over on time. The gist was a bunch of best practices for introduction and operation of web application firewalls. He talked about technical requirements, job requirements, and an iterative procedure for implementation.
This presentation was mostly just an overview of what is in the paper and he didn't get into too much specifics. Go check out the paper at https://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls to get the details!
This presentation is by Jacob West in the Security Research Group and Taylor McKinsley in Product Marketing from Fortify software. I'd like to note that Fortify is a developer of a source code analysis tool and so this presentation may have a bias towards source code analysis tools.
56% of organizations fail PCI section 6. Poorly coded web applications leading to SQL injection vulnerabilities is one of hte top five reasons for a PCI audit failure. Section 6 is becoming a bigger problem: #9 in 2006 reason for failure, #2 in 2007.
PCI Section 6 has to do with guidelines to "Develop and maintain secure systems and applications". Section 6.6 reads "Ensure that all web-facing applications are protected against known attacks by either of the following methods: Having all custom application code reviwed for common vulnerabilities by an organization that specializes in web application secure" or by using a web application firewall. Further clarifications say that automated tools are acceptable, web application penetration testing is allowed, and vulnerability assessments can be performed by an internal team.
Comparing Apples, Oranges, and Watermelons
- Setup: Source code analysis (+2) is good because it works on existing hardware, but must live where your source code lives. Penetration testing (+3) is good because you only need one to assess everything and works on existing hardware, but needs to talk to a running program. Application firewall (+1)is good because it lives on the network, but you must model program behavior.
- Optimization: Source code analysis (+2) is good because you can specify generic antipatterns in code, but you must understand vulnerability in detail. Penetration testing (+2) is good because tests are attacks, but you must successfully attack your application. Application firewalls (+1) are good because they share configuration across programs, but must differentiate good from bad.
- Performance: Source code analysis (+3) is good because it simulates all application states and is non-production, but scales with build time and not the number of tests. Penetration testing (+2) is good because you get incremental results and is non-production, but you must exercise each application state. Application firewall (+1) is good because it's a stand-alone device and scales with $$$, but impacts production performance and scales with $$$.
- Human resources: Source code analysis (+1) is good because it enables security in development and reports a root cause, but makes auditors better and does not replace them. Penetration testing (+2) is good because it is highly automatable, but reports symptoms and not the root cause. Application firewall (+2) is good because once it's configured it functions largely unattended, but requires extensive and ongoing configuration.
- Security know-how: Source code analysis (+3) is good because it gives code-level details to an auditor, but you must understand security-relevant behavior of APIs. Penetration testing (+1) is good because it automates hacks, but a hacker is required to measure success and optimize. Application firewall (+2) is good because it identifies common attacks out of the box and is a community effort, but a hacker is required to measure success and customize.
- Development expertise: Source code analysis (+1) is good because it focuses attention on relevant code, but you must understand code-level program behavior. Penetration testing (+2) is good because basic attacks ignore internals, but advanced attacks require internal knowledge. Application firewalls (+2) are good because they live on the network, but you must understand the program to tell good from bad.
- False positives: Source code analysis (+1) is good because it gives auditors details to verify issues, but reports impossible application states. Penetration testing (+2) is good because results come with reproduction steps, but it is difficult to oracle some bugs. Application firewalls (+1) are good because it is attacks instead of vulnerabilities, but there is an evolving definition of valid behavior.
- False negatives: Source code analysis (+3) is good because it simulates all program states and models the full program, but it must be told what to look for. Penetration testing (+1) is good because it is good at finding what hackers find, but is difficult to oracle some bugs and has missed coverage. Application firewalls (+1) are good because it uses attacks instead of vulnerabilities, but there is an evolving attack landscape.
- Technology support: Source code analysis (+2) is good because parsing is separable from the analysis and is interface-neutral, but it must adapt to new program paradigms. Penetration testing (+2) is good because it is independent from program paradigms, but is tied to protocols and is limited to network interfaces. Application firewalls (+2) are good because they are independent from program paradigms, but are tied to protocols and are limited to network interfaces.
Working Towards a Solution
- Assessment: Proving the problem or meeting the regulatory requirement. Recurring cost that does not "fix" anything
- Remediation: Fixing security issues found during assessments. Lowering business risk at a single point in time.
- Prevention: Get security right hte first time. Minimizing business risk systematically.
Do your own comparison and fill out the scorecard yourself (presenters ratings are noted in parentheses above).
Taylor did interviews with three companies to get their experiences deploying each (source code analysis, penetration testing, and application firewall) and had them evaluate based on the nine criteria both before and after buying. Not going to list each company's results in the blog, but it was just a basic table with each criteria and a number rating for both before purchase and after deployment. To sum it up, Source Code Analysis was a 14 rating before purchase and a 17 rating after deployment. Penetration testing was a 21 rating before purchase and a 21 rating after deployment. Application firewalls were a 21 rating before purchase and a 16 rating after deployment. It seems like the first organization had a large amount of developers and that factored into their decision to purchase a source code analysis tool. The second organization had a far fewer number of developers and was more of an IT shop and chose the penetration testing tool. The last organization was a smaller shop in general (still fairly large) and went with the WAF because they wanted something they could just put in place and manage.
Analysis: All three solutions required more effort than expected. All three solutions produce reasonably accurate results. Varying levels of expertise needed.
How do you demonstrate that your application is protected against known attacks?
- Verification that the application was analyzed
- A report showing no critical security issues identified
- Document showing how the tool fits into your architecture
How do you show that the user is appropriately trained?
- Document explaining prior experience or an informal interview
How do you show that you have configured the tool appropriately?
- Document explaining how the tool was configured and what new rules had to be added.
Summary: PCI section 6 is evolving to become increasingly precise. Compare technologies in your environment along nine criteria. Demonstrating compliance is an art, not a science.