1 / 30

Web Application Security

Web Application Security. (and why it matters to YOU!) By Mark Bristow and Doug Wilson. Your presenters today. Doug Wilson Security Lead and Network/Systems Engineer for EMIB at NIH DougWilsonMoo@gmail.com Mark Bristow Application Security Engineer at GAO

wilma
Télécharger la présentation

Web Application Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Web Application Security (and why it matters to YOU!) By Mark Bristow and Doug Wilson

  2. Your presenters today • Doug Wilson • Security Lead and Network/Systems Engineer for EMIB at NIH • DougWilsonMoo@gmail.com • Mark Bristow • Application Security Engineer at GAO • Mark.Bristow@gmail.com (and yes, we are “security guys”)

  3. Why we are here A brief discussion on • What is Web Application Security? • Why does it matter to you? • Instances of real-world problems . . . • And what you can do to remediate them.

  4. What is Web Application Security? (the elevator speech)

  5. Web application security is . . . An overall process that • Starts in the initial planning stages • Requirements gathering • Business logic • Application structure and design • Continues through • Coding • Testing • Deployment • And doesn’t finish until • The full lifecycle of the application • Including decommissioning

  6. But why should this matter to me? • No one would ever bother with my web site. • We already have “security” • We use open source -- it has peer review • We use a vendor -- it has the vendor backing it and they are getting better these days • We keep up on patches/versions/revisions • “So we have a firewall, an IDS, an IPS, and use SSL . . . we’re covered . . . right?”

  7. The time to fix this is NOW • The web was designed as a trusted environment. It is NOT that anymore. • Web technologies allow a degree of interoperability and integration of data never before dreamed of, for good and for bad. • Web applications are still “emerging technologies” for most organizations. • The drive to stay competitive results in unrealistic expectations and unsafe practices.

  8. Recent IT nightmares • VA and other government agencies • PII for 26.5 million veterans • TJ Maxx and credit card processing • 45 million credit card numbers • AOL and User Data • 19 million queries from 650,000 subscribers • PaineWebber logic bomb • 2000 servers, over $3.1 million just to restore

  9. Web App specific numbers • Symantec ISTR Jul-Dec 2006 (from March 2007) • 2,526 vulnerabilities in 2006 (second half) • 66% affected Web Applications!!! • Government Sector had the highest percentage of data breaches that could lead to identity theft • CIO Magazine interviews Jeremiah Grossman (5/07) • Vulnerabilities in 80% of websites analyzed • Remaining 20% are mostly static sites • Most C-level execs they talk to think firewalls protect against web application attacks -- THIS IS NOT TRUE!!!

  10. The bottom line -- Liability • Liability is not only very costly, it can damage intangibles. • Public sector groups often care more about intangibles. Private sector financial damages can put you out of business. • Regardless of the who the bad guy is, the liability lies with the people who create and maintain these systems and their management.

  11. OWASP Top 10 • Cross Site Scripting (XSS) • Injection Flaws • Malicious File Execution • Insecure Direct Object Reference • Cross Site Request Forgery (CSRF) • Information Leakage and Error Handling • Broken Authentication and Session Management • Insecure Cryptographic Storage • Insecure Communications • Failure to Restrict URL Access

  12. Cross Site Scripting • What is Cross Site Scripting? • Getting the user to execute arbitrary code in their web browser • Why is XSS So Dangerous? • Compromise victim computer • Can steal user’s authentication credentials • Intranet Port scanning • Stealing Sensitive Data • Key/Mouse logging • WebWorms • XSS is everywhere • FBI, AOL, HBO, CNN, BBC, FOX, Weather.com… to name a few

  13. Injection Flaws • Come in many flavors: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection, and more • SQL Injection • What is SQL injection? • Injecting code to modify the intent of a SQL query • What happens if I set my password to ‘ OR ‘z’=‘z? • What can I do with SQL Injection? • Break or bypass Authentication • Has the potential to expose your database data to an attacker • Attacker can potentially modify your database structure and data Select * from users where uname =‘’ and pw=‘’OR ‘Z’=‘Z’ p\/\/nd

  14. Fixing Injection Flaws • The top two flaws are based on Injection • Most of these are easily solved by following a few simple concepts religiously, in the way that works for your environment. • Don’t trust ANYTHING that comes from the client. Ever. • Validate and type all input as strictly as you can. • Encode and control all output as strictly as you can.

  15. Malicious File Execution • Often found when developers directly use user input with file streams • Can allow for remote code execution, root kit installation and more. • Include $userinput.”.php”

  16. Insecure Direct Object Reference • Occurs when a resource object is directly called via user input. • Examples • Directory Traversal • Source code disclosure

  17. Fixing Object Access Flaws • Don’t trust ANYTHING that comes from the client. Ever. • Validate and type all input as strictly as you can. • Encode and control all output as strictly as you can. • Do you sense a trend here? • In fact, let’s talk about this for a moment

  18. Input and Output • Input Validation • Client side -- doesn’t really do anything for security, though it still has its uses • Server side – The only place where your validation provides security • Double-escaping and understanding the logic of how this works • Regex – Your new best friend <3 • Output Encoding • Output should be encoded to match the delivery medium • HTML Entity encoding will stop 99% of XSS attacks • < = &lt; > = &gt; & = &amp; ……

  19. Mechanics of good Validation • Techniques • White listing – Pass only when content contains only known good input • Black Listing – Fail when a known bad is detected • Sanitization – “Clean” data before using it based on Black or White List • Examples • Lets generate a white list for a “name” field • Lets generate a black list for the same “name” field

  20. Sanitization Issues • Lets sanitize the name field against script injection • String name = request.getParameter( "name" ); • name.replaceALL(“script”, “”); • out.println(name); • Is this a white or black list? • Test cases • Name = “<script>alert(‘I pwnt j00’);</script>” • Result: <>alert(‘I pwnt j00’);</> • Name = “<scrscriptipt>alert(‘I pwnt j00’);</scrscriptipt>” • Result: <script>alert(‘I pwnt j00’);</script> • Sometimes this is a necessary evil • How would you take care of a text area?

  21. Object Access, Part II • This (and other things on the list) is not strictly a code issue • Server configuration is also key, and flaws in server software need to be patched ASAP. • If you don’t need the functionality in the application, don’t have it, or make sure you do it safely.

  22. Cross Site Request Forgery (CSRF) • When an attacker forces a victim’s browser to submit a request the victim did not intend to submit • Also known as a “One click attack” or session riding or XSRF • Exploits pre-established trust relationship (session) to force authorization • High remediation costs • Malicious requests and legitimate requests are indistinguishable. • Origionally dates to 1998 but is just becoming well understood • Example • Victim logs into their bank website • Victim views attacker’s blog or infected page • CSRF Exploit initiates a request to the bank website to make a money transfer • User’s state automatically appended to CSRF Request • Bank sees an authenticated and valid request to the transfer action to transfer funds and executes it • Attacker gets victim’s money

  23. Fixing CSRF • CSRF is often labeled as “unfixable,” it’s inherent in how the web works. But you can take steps to help. • Problems and safeguards • Data returned as javascript (Gmail) -- fixed by while(); loop • Digg article -- fix: secret tokens • Amazon One-Click -- fix: Password re-entered • Fixes work -- unless you combine with XSS. Then the rules change, and some standard fixes go out the window (like secret tokens)

  24. The rest of the OWASP Top 10 • Information Leakage • Error messages provide vital tools to an attacker • Broken Session Management • Insecure Cryptographic Storage • Insecure Communications • SSL is a web attacker’s best friend • Failure to restrict URL access • What happens when I request an admin page directly without logging in first? • “Logic flaws” and why they are only really found by people.

  25. The AJAX question • Does AJAX and other similar technologies make for “worse” application security? What about web services? • Hot topic of debate -- Asynchronous applications and web services aren’t innately more “insecure,” but greatly increase complexity and attack surface. • Both Asynchronous and Web Service style applications have the potential to reintroduce a lot of old problems, and hide exploitation from being readily visible. • Minimalist approach is best

  26. The Sky is Falling? • The sky is NOT falling! • All of the vulnerabilities mentioned here can be fixed • Developer education and a robust software security program can help mitigate these issues • Educate yourselves • Educate your customers

  27. Pick a place, we can add security • Already up and running? • Assessments -- Humans and Tools • Managed Services • WAF/IPS/IDS -- Monitor, Monitor, Monitor!!!! • Deployment • Make sure it’s secure before it goes out the door • Development • Educate your developers • Code review -- Humans and Tools • Architecture • Educate your architects • consider security from day one

  28. How do I get started? • LEARN! What threats are out there and how they apply to your organization? • Classify what data is most important to your organization • Identify all of your web applications and assign them criticalities based on business needs and data classification • Perform vulnerability assessments to determine how big the problem is • “Bake security in” to your SDLC

  29. Resources • Sites • http://www.owasp.org • http://www.webappsec.org/ • http://ha.ckers.org • http://www.sans-ssi.org/ • Books • How to Break Web Software • Hacking Exposed : Web Applications • XSS ATTACKS • Training • Certified Ethical Hacker (CEH) • Foundstone Ultimate Web Hacking • SANS Training • Securing Critical Web Applications and Web Services (Aspect Security) • Writing Secure Web Applications: Developer Training

  30. Questions? Doug Wilson -- DougWilsonMoo@gmail.com Mark Bristow -- Mark.Bristow@gmail.com

More Related