F5 Web Application Security

1. F5WebApplicationSecurity Radovan GibalaSenior Solutions Architectr.gibala@f5.com+420 731 137 223 2009

2. Agenda • Challenge Websecurity – What are the problems? • Building blocks of Web Applications • Vulnerabilities and protection strategies • Websecurity with a Web Application Firewall (WAF) • Security Policy Setups • Deployment Methods • Attacking the Application • How to mitigate the risk in Web Applications with ASM

3. Business-Critical Applications Advantages of Voice, Data and Video Integration Profitability Increase Mobile Applications Access and Usage of Applications from Mobile (private ?) Devices Market Trends Webalization of Critical Applications Mission-Critical Applications ERP, CRM, SCM - With access from Internet Data Centre Consolidation Centralization of Applications and Access from Internet XML-based Web Services B2B Business Processes over Web Services / XML

4. Security’s Gaping Hole Firewall Antivirus Host IDS & Secure OS Net IDS Application System Network Access Desktop “64% of the 10 million security incidents tracked targeted port 80.”Information Week DATA

5. ! ! ! Infrastructural Intelligence Non-compliant Information Forced Access to Information Buffer Overflow Cross-Site Scripting SQL/OS Injection Cookie Poisoning Hidden-Field Manipulation Parameter Tampering Web Application Security Attacks Now Look To Exploit Application Vulnerabilities Perimeter Security Is Strong PORT 80 PORT 443 But Is Open to Web Traffic High Information Density = High Value Attack

6. Why Are Web Applications Vulnerable? • New code written to best-practice methodology, but not tested properly • New type of attack not protected by current methodology • New code written in a hurry due to business pressures • Code written by third parties; badly documented, poorly tested – third party not available • Flaws in third party infrastructure elements • Session-less web applications written with client-server mentality

7. Solution Sentences for Application Security • Make Bug-free applications • Network Firewalls + Marketing • Tools in the Web Servers • Infrastructure Solutions

8. Application Patching Application Optimization Application Logic 1+1=2 Application Security Application Scalability Application Integration Application Availability Application Performance Traditional Alternative: Rely Exclusively on the Developer

9. Who is responsible for application security? Web developers? Network Security? Engineering services? DBA?

10. Challenges of traditional solutions HTTP attacks are valid requests HTTP is stateless, application is stateful Web applications are unique there are no signatures for YOUR web application Good protection has to inspect the response as well Encrypted traffic facilitates attacks… Organizations are living in the dark missing tools to expose/log/report HTTP attacks

11. Best Practice Design Methods Automated & Targeted Testing Web Application Firewall Web Application Protection Strategy • Only protects against known vulnerabilities • Difficult to enforce; especially with sub-contracted code • Only periodic updated; large exposure window Web Apps • Done periodically; only as good as the last test • Only checks for known vulnerabilities • Does it find everything? • Real-time 24 x 7 protection • Enforces Best Practice Methodology • Allows immediate protection against new vulnerabilities

12. Traditional Scan and Fix and Audits Scan and Fix Scanners can’t find all vulnerabilities Scanners can’t reverse engineer the code Scanners can’t find business logic vulnerabilities When something is detected, it requires an immediate code change Not a pro-active solution Security Code Audits Extremely expensive ($25,000 for medium to small app) Requires preparation and availability of the dev team. Requires iterations of audit and fix Each fix may add more bugs to current application or may add another vulnerability… “we only protect from what we know, we never protect from what we don’t know”

13. Web Applications Increasingly Under Attack • High information density in the core • Flaws in applications & 3rd party software • Traditional security does not protect web apps. • Gaping hole in perimeter security for web traffic SANS (November 2006) - Top Vulnerabilities in Cross-Platform Applications C1. Backup Software C2. Anti-virus Software C3. PHP-based Applications (50% of all Apache installations worldwide use php!) C4. Database Software ... C6. DNS Software ... C9. Mozilla and Firefox Browsers ...

14. Application Security Lacks Test ...or: „The Point of Truth“ • Simple Version: • Does your WAF discover that the Price of an Item on an Online Shop was changed ?

15. Support of dynamic values

16. Application Security Lacks Test ...or: „The Point of Truth“ • Simple Version: • Does your WAF discover that the Price of an Item on an Online Shop was changed ? • Technical Version: • OWASP (http://www.owasp.org/index.php/OWASP_Top_Ten_Project ) • Unvalidated Input • Broken Access Control • Broken Authentication and Session Management • Cross Site Scripting • Buffer Overflow • Injection Flaws • Emproper Error Handling • Insecure Storage • Application Denial of Service • Insecure Configuration Management

17. OWASP Top 10 / January 2007

18. n-tier Web Application Layer

19. Option 4 Application Security, Optimization & Delivery Option 2 Option 3 Option 1 Routing, ACL Network Security Application Core Functionality BIG-IP LTM Application Security Manager “A combined application delivery controller and Web application firewall, rather than stand-alone products, provides a single-vendor relationship and performance improvements. “ Gartner Research Router Firewall Application Layer Security, Acceleration, & Availability Database Web Server App. Server Network Layer Security Packet Filtering Session Layer Security Stateful Inspection • Pros: • Application Fluent • Already used as SSL proxy for applications • High performance Layer 7 processing • Stronger support for L7 protocol validation • Perfect location directly in front of applications and servers • Cons: • Less focus on Layer 2/3 security • Pros: • First point of entry • Cons: • Zero application fluency • Wrong location • No support for SSL • Too little and expensive processing power • Pros: • Experienced in • Network security • Has some session & app protocol awareness • Cons: • No application fluency • Out in DMZ / wrong location • Not optimized for L7 • processing • Cannot filter encrypted • content • Less focus on SSL • Pros: • Very specific to each application type and vendor • Cons: • Complex to manage • Costly to implement • inside each application • Error-prone • In-efficient and re-active Where does Application Security make Sense ?

20. Traditional Security Doesn’t Protect Web Applications Looking at the wrong thing in the wrong place IPS Application Firewall Network Firewall Known Web Worms Unknown Web Worms Known Web Vulnerabilities Unknown Web Vulnerabilities Illegal Access to Web-server files Forceful Browsing File/Directory Enumerations Buffer Overflow Cross-Site Scripting SQL/OS Injection Cookie Poisoning Hidden-Field Manipulation Parameter Tampering              Present Present Present Present Present Present Present Present Present Present Present Present Present Present Present Present Present Present Present Present X X X X X X

21. Negative vs. Positive Security Model • Negative Security Model • Lock Known Attacks • Everything else is Allowed • Patches implementation is quick and easy (Protection against Day Zero Attacks) • Positive Security Model • (Automatic) Analysis of Web Application • Allow wanted Transactions • Everything else is Denied • Implicit Security against New, yet Unknown Attacks (Day Zero Attacks)

22. ! ! ! ! Non-compliant Information Unauthorised Access Infrastructural Intelligence Unauthorised Access Application Security with a WAF And Stops Bad Requests WAF Allows Legitimate Requests Browser • Bi-directional: • Inbound: protection from generalised & targeted attacks • Outbound: content scrubbing & application cloaking • Application content & context aware • High performance, low latency, high availability, high security • Policy-based full proxy with deep inspection & Java support • Positive security augmenting negative security • Central point of application security enforcement

23. Application Security with a WAF Intelligent Decisions Allow Only Good Application Behaviour; Positive Security Definition of Good and Bad Behaviour Browser

24. ! ! ! VIOLATION VIOLATION ALLOWED Selective Application Flow Enforcement Username From Acc. $ Amount Password To Acc. Transfer ? This part of the site is a financial transaction that requires authentication; we should enforce strict flow and parameter validation • Should this be a violation? • The user may have bookmarked the page! • Unnecessarily enforcing flow can lead to false positives.

25. Multiple security layers RFC enforcement Various HTTP limits enforcement Profiling of good traffic: Defined list of allowed file types, URI’s, parameters Each parameter is evaluated separately for: Pre defined value Length Character set Attack patterns looking for Pattern Matching Signatures

26. Flexible Deployment Options OBJECT FLOWS Tighter Security Posture PARAMETER VALUES PARAMETER NAMES Typical ‘standard’ starting point OBJECT NAMES OBJECT TYPES

27. Optimum policy is often a hybrid Flexible Policy Granularity • Generic Policies - Policy per object type • Low number of policies • Quick to implement • Requires little change management • Can’t take application flow into account • Specific Policies – Policy per object • High number of policies • More time to implement • Requires change management policy • Can enforce application flow • Tightest possible security • Protects dynamic values

28. POLICY TIGHTENING SUGGESTIONS • Policy-Building Tools • “Trusted IP” Learning • Live Traffic Learning • Crawler • Negative RegEx • Template Flexible Deployment Options OBJECT FLOWS Tighter Security Posture PARAMETER VALUES PARAMETER NAMES Typical ‘standard’ starting point OBJECT NAMES OBJECT TYPES

29. Deployment without False positives Easy web application implementation Rapid deployment policy Pre-configured application policies Learning mode Gradual deployment Transparent / semi-transparent / full blocking

30. F5 Application Security Manager (ASM) and WhiteHat Sentinel partnership Turnkey Vulnerability Detection and Remediation Solution

31. ASM + Sentinel Benefits Discovery and remediation within minutes Single click policy rules (XSS, SQLi) Targeted laser focused policy rules No false positives Third party policy validation Out-of-the-box integration for fast implementation

32. ASM + WhiteHat: what and how ? Security Policy Internet website

33. PCI: WAF or scan?

34. WAF deployment with the BIG-IP LTM & ASM Web Servers BIG-IP with ASM Firewall Management Access (browser) ASM = Application Security Manager

35. Layer 7 DoS and Brute Force Unique Attack Detection and Protection Unwanted clients are remediated and desired clients are serviced Improved application availability Focus on higher value productivity while automatic controls intervene

36. Summary ASM introduce the DoS and Brute Force prevention engines. The DoS prevention is anomaly based The brute force relies on the Dos engine to mitigate attacks Both features have reporting page to provide information on false positives in transparent mode and actual attack in blocking mode

37. DoS – configuration The configuration screen is divide into 5 main parts: Operation mode Detection Criteria Suspicious Criteria Prevention Policy Prevention Duration

38. DoS– Operation mode The operation mode: Off: the anomaly detection engine is off and will not collecting any data. Transparent: the anomaly detection engine is collecting data, writing it to report log in case threshold are reached but will not drop connections Blocking: the anomaly detection engine is collecting data, write those events to report log and will drop connection if thresholds are reached.

39. DoS– Detection Criteria Detection Criteria is the first phase of the DoS detection The Detection Criteria measurements are being done on latency and include: Latency increased by Latency reached Minimum Latency Threshold for detection

40. DoS– Suspicious Criteria Suspicious Criteria is the second phase of the DoS detection The Suspicious Criteria measurements are being done on TPS and include: TPS increased by TPS (per IP address) reached TPS (per URL) reached

41. DoS– Prevention Policy When the anomaly engine decide on the “Suspicious Criteria” that this is a DoS attack the engine will apply one of the prevention policies: Client Side Integrity Defense: ASM will send a java script in the response to the suspicious IP. If the client is a valid browser it will return a valid request, if it is a script, it will not return a request and therefore malicious and connection can be dropped. *note: it is recommended to check the impact of Java Script on clients before applying this policy

42. DoS– Prevention Duration Source IP-Based Rate Limiting: dropping connection with specific suspicious IP if “TPS (per IP address) reached”. Dropping the connection will stop when transaction rate “detection interval” is equal to its transaction rate “history interval”. URL-Bases Rate Limiting: dropping connection for specific URL if “TPS (per URL) reached” . Dropping the connection will stop when transaction rate “detection interval” is equal to its transaction rate “history interval”. Prevention Duration: limiting the amount of time the prevention policy is applied.

43. DoS - Reporting Reporting page for DoS will show events that reached the thresholds criteria's Some of the records might not be an actual connection drop when in transparent mode

44. DoS - Reporting (cont.) Only records that contain dropped request are actual prevention Legitimate Latency: Displays the latency history interval Detected Latency: Displays the latency detection interval

45. DoS - Reporting (cont.) Current Mitigation: Displays the prevention policy that was applied on the attack Previous Mitigation: Displays the previous prevention policy that didn’t manage to mitigate the attack IP Addresses: list of the source IP, including XFF header

46. Brute Force Brute Force is a new feature in ASM park city Part of the brute force feature relies on the DoS engine Brute force can be define per web application The configuration page contain few sections: Brute Force Protection Configuration Session-based Brute Force Protection Dynamic Brute Force Protection Access Validation

47. Brute Force - configuration The Brute Force Protection Configuration defines authentication and credentials for the system to determine there is a brute force attempt on them Login URL: the explicit object the login action is being perform. Wild card is also supported. Authentication type: basic , digest NTLM and HTML form is supported. For HTML form user should define the user name and password parameters name that the client send as login

48. Brute Force - configuration (cont.) Session-based Brute Force Protection enables the user to block clients that perform 5 login attempts with the same session. User can set how long they will wait until they can re login again for the same session Enabling this feature is via the main blocking page.

49. Brute Force - configuration (cont.) Dynamic Brute Force Protection. Operation mode: enable or disable Off: the system doesn’t collect any data. Transparent: in case thresholds are reached will not drop requests and will write event to repot log. Blocking: in case thresholds are reached will drop request and will write events to report log.

50. Brute Force - configuration (cont.) Detection Criteria: Failed Login Attempts increased by: ratio of detection interval and history interval for all IP’s Failed Login Attempts Rate reached: failed logon rate value for all IP’s. Minimum Failed Login Attempts: this minimum must be reached first to prevent false positives The “Minimum Failed Login Attempts’ is AND with (“Failed Login Attempts increased by” OR “Failed Login Attempts Rate reached”)