Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation.

Similar presentations

Presentation on theme: "Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation."— Presentation transcript:

1 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 OWASP AppSec June 2004 NYC Beyond Best Practices: Web Application Security in the Real World OWASP AppSec Conference 2004 Dave Aitel

2 OWASP AppSec 2004 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

3 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

4 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

5 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

6 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

7 OWASP AppSec 2004 Web App Security Best Practices: Basic Network Topology  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 Web App

8 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.

9 OWASP AppSec 2004 The CISO Lifecycle Design Deployment Maintenance/ Update Request Implementation QA and Testing

10 OWASP AppSec 2004 The CISO Lifecycle As a security company sees it Design Deployment Maintenance/ Update Request Implementation QA and Testing Design Review Code Review Penetration Test Security Training Penetration Test Automated Scanning Automated Code Review

11 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

12 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,, etc)  Simply due-diligence  Lockdown scripts and configurations  Expensive, custom, and sometimes externally generated  Penetration Tests  Internally or externally resourced  Periodic

13 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

14 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

15 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

16 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

17 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* a/hockeystick@?ads_no=13487&&CE=i01

18 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

19 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

20 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

21 OWASP AppSec 2004 SQL Sniffers and IDSs  Custom heuristics are highly accurate at detecting misuse  Automated pattern matching (i.e. Bayesian) is also useful App Server SQL IDS SQL Statements have low entropy. Custom anomaly detection is easy.

22 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

23 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

24 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

25 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

26 OWASP AppSec 2004 Your Idealistic Web App Lifecycle 1.Design 2.Implement 3.QA 4.Test for security 5.Deploy 6.Modify and Maintain 7.Periodically test for security

27 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

28 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

29 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

30 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 strange database queries being made Are We Under Attack

31 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 User HelpDes k Data requests

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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 3 rd party components

41 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

42 OWASP AppSec 2004 Questions and War Stories  Thank you.

Download ppt "Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation."

Similar presentations

Ads by Google