Beyond Best Practices: Web Application Security in the Real World OWASP AppSec June 2004 NYC OWASP AppSec Conference 2004 Dave Aitel www.immunitysec.com Copyright © 2004 - The OWASP Foundation Permission.
Download ReportTranscript Beyond Best Practices: Web Application Security in the Real World OWASP AppSec June 2004 NYC OWASP AppSec Conference 2004 Dave Aitel www.immunitysec.com Copyright © 2004 - The OWASP Foundation Permission.
Beyond Best Practices: Web Application Security in the Real World OWASP AppSec June 2004 NYC OWASP AppSec Conference 2004 Dave Aitel www.immunitysec.com Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License. The OWASP Foundation http://www.owasp.org Immunity, Inc. A NYC based application security professional services firm Two years of work as Immunity in and around the financial district Previous experiences in government and private sector firms OWASP AppSec 2004 Immunity Tools and Resources GPL Software SPIKE Proxy SPIKE Commercial Software CANVAS Books The Hacker's Handbook/The Shellcoder's Handbook Conferences NYC Security Shindigs BlackHat, CanSecWest/PacSec, etc OWASP AppSec 2004 Agenda What are current web application security best practices (from a CISO perspective) What are the gaps in these practices, as commonly used How can these gaps be filled in the future OWASP AppSec 2004 Note There currently exists no one document describing best practices for web application security at the CISO level This makes critiquing them hard We'll use our experience to describe what companies are doing instead OWASP AppSec 2004 Drivers For Web App Security News Reports damage to company image Monetary loss Esp. with on-line stores Rules and Regulations Sarbanes this and that OWASP AppSec 2004 Web App Security Best Practices: Basic Network Topology Web App Separation by functionality allows separation of threats And therefore risk Using data flow as an indicator prevents fooling yourself as to real risks of compromise OWASP AppSec 2004 A word on DMZs From: Improving Web Application Security: Threats and Countermeasures (MSDN) Do not pass RPC over your firewall. It is conceptually better not to have one in place. OWASP AppSec 2004 The CISO Lifecycle Design Maintenance/ Update Request Deployment Implementation QA and Testing OWASP AppSec 2004 The CISO Lifecycle As a security company sees it Security Training Maintenance/ Update Request Design Design Review Implementation Code Review Penetration Test Deployment Automated Scanning QA and Testing Automated Code Review Penetration Test OWASP AppSec 2004 Bottom Rung Infrastructure-related vulnerabilities Overflows, etc. DoS or other attack SQL Injection Accepting File Names from the client Cross-Site Scripting (the “blue moon” threat) Poor management of user-input Being able to replace dollar values Poor firewall rule-set maintenance OWASP AppSec 2004 Best Practices: Infrastructure-related vulnerabilities DoS is just as bad as penetration in many cases 4 hours preventable downtime==lost job for CISO Patch deployment Patch alert services (iDefense, ISS.net, etc) Simply due-diligence Lockdown scripts and configurations Expensive, custom, and sometimes externally generated Penetration Tests Internally or externally resourced Periodic OWASP AppSec 2004 Problems with these Best Practices Periodic is not periodic enough Penetration tests done by consultants are expensive and over-thorough Patch deployment is far too slow Patch deployment doesn't account for actual risk of already having been owned OWASP AppSec 2004 Automation Everything in the bottom rung can be found by a product or novice except: Trying to buy goods on your site for less than you want me to (bypassing business logic) Major Products include WebInspect (SPIdynamics) AppScan KavaDo OWASP AppSec 2004 Purchasing Automation 10-50K Licensing restrictions Per person, rather than per-seat Per-host Difficult to update and customize Unknown reliability and coverage OWASP AppSec 2004 Enhancing Automation Automation is great until you realize that you need to work around some quirk in your site and your automated tool can't support that Use Open Source tools, such as SPIKE Proxy or OWASP WebScarab to fill these gaps Modifying the code to fit your environment is a key philosophical change that can make you more secure for less money and resources OWASP AppSec 2004 Some Examples URL formats for sites don't always fit the http://site/bob.cgi?value=thing&value2=thing2 format. This makes them hard to scan via commercial automated tools http://us.rd.yahoo.com/classsite/fd/hj/evt=7540/*http://hotjobs.com http://g.msn.co.kr/KRJ9/5279.10?http://ad1.targetgraph.com/click.kti/msnkore a/hockeystick@?ads_no=13487&&CE=i01 OWASP AppSec 2004 Server Security All web and application servers have had buffer overflows Don't look to W xor X (XP SP2, Fedora CORE) or stack canaries (W2K3) as some sort of savior Install a HIDS Won't protect you against data or injection issues It's a backwards thing for me to hit your actual server Optimally, use grsecurity on Linux OWASP AppSec 2004 Cross-Site-Scripting SQL Injection can be solved with a library or API policy See MSDN documentation on the new ASP.NET way to do so However, that very same MSDN documentation notes that you should use code review and trial and error penetration testing to find XSS OWASP AppSec 2004 SQL Injection Fairly simple to scan for Turn off custom error handler pages Spider website, insert quotes,parens as necessary Record error messages and send to development team Current practice of hiring consultants/expensive software to find this is wasteful Especially if you leave error handler pages on OWASP AppSec 2004 SQL Sniffers and IDSs Custom heuristics are highly accurate at detecting misuse Automated pattern matching (i.e. Bayesian) is also useful SQL IDS App Server SQL Statements have low entropy. Custom anomaly detection is easy. OWASP AppSec 2004 Top Rung Vulnerabilities Being able to access “data” that I should not be able to access Attacking session-id or other randomization weaknesses Manipulating session-state variables to bypass business logic and authentication OWASP AppSec 2004 The 1% Rule The top 1% of hackers are extremely differentiated Each of them may get into your site, but via very different methods This makes them impossible to model, predict, and defend against OWASP AppSec 2004 Current Top Rung Best Practices Hire penetration test experts to code review and analyze live systems Hire outside experts to train your developers OWASP AppSec 2004 Better Top Run Best Practices Develop internal experts to train your developers in a manner specific to your application Establish an internal team accountable for application security Develop custom application security code review tools Hire outside experts to find new CLASSES of vulnerabilities in your application, not new vulnerabilities OWASP AppSec 2004 Your Idealistic Web App Lifecycle 1. 2. 3. 4. 5. 6. 7. Design Implement QA Test for security Deploy Modify and Maintain Periodically test for security OWASP AppSec 2004 Security in the Design Phase .... Is a Myth. Your team often didn't do the design And sometimes not the implementation as well Many products are purchased Or have large components that are purchased You may not even have code or documentation to them Requirements change during development And after deployment OWASP AppSec 2004 Auditing and Logging Currently, few people look at their log files for security issues unless an incident occurs The correct way to use your auditing and logging is to use it as a feedback loop into your custom security applications OWASP AppSec 2004 APS versus HIDS An application layer IDS can find vulnerabilities, rather than intrusions Much harder problem to generalize There is no “Application Level” IP XML transactions generally top out at 300 TPS A HIDS does not protect data It protects files and other OS resources OWASP AppSec 2004 Proper logs can be custom IDS Web App Are we seeing anomalous login attempts Is the middle-ware receiving anomalous amounts or types of requests? Are We Under Attack Are strange database queries being made OWASP AppSec 2004 User Roles For each request is there a “and USERROLE='1'” at the end of the query? Can your SQL IDS tell you if there isn't? Admin Data requests User HelpDes k OWASP AppSec 2004 Dealing with third party components Stop buying third party software on an “AS IS” basis Conduct or obtain assurances that this software is free from glaring defects, such as buffer overflows Perform due diligence testing OWASP AppSec 2004 Database Encryption Storing the key on the same application as the vulnerabilities is still considered “Best practices” as long as encryption is being used... If you have 30K users a day, and an attacker manages to sit on your App server for 20 minutes, how many passwords do they now have? How many of them live in CA? Web App OWASP AppSec 2004 SSL Object Lesson The QA site needs to contain every aspect of the production site, including F5 load balancers, customer support infrastructure, etc. These things are part and parcel of your application OWASP AppSec 2004 HMACS Often used to prevent users from manipulating cookie or session variables Cookie: Admin=0; HASH=MD5(“Admin=0”+”secretkey”) Don't hard-code your HMAC into your application Don't use a small, English string as your HMAC seed OWASP AppSec 2004 Automated Code/Binary Auditing Tools New and old offerings Fortify Software @stake SRA Microsoft PreFix/PreFast Coverity Ounce Labs HBGary Bugscan Secure Software OWASP AppSec 2004 Automated code assessment downsides Extremely first generation May require special build configurations Cannot scan across component boundaries Expensive People underestimate the time it takes for a good code reviewer to find bugs OWASP AppSec 2004 Parsing for Success Analyzing each component's interactions with the system in depth is impossible Component use changes over time But quick scripts can be written that work for your application and can be included in your QA process Looking for strcpy() is a waste of time – verify that YOUR API is used properly instead OWASP AppSec 2004 Cover Review Best Practices Improved Train for specifics Don't let security consultants work off-site Do daily scans for application vulnerabilities across every site OWASP AppSec 2004 Filling the Gaps Customized code review applications Customized Application Layer IDS Customized Data Mining IDS's Customized Developer Training Actually Writing Security Documentation Getting the most out of your security money QA Testing of 3rd party components OWASP AppSec 2004 What's Missing? Policy Useless unless monitored via technical measures Make your policy documentation of existing efforts Audits (ISO31337, etc) Providing no security value and little marketing value Eschew OWASP AppSec 2004 Questions and War Stories Thank you. OWASP AppSec 2004