• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Intro to Web Application Security
 

Intro to Web Application Security

on

  • 7,307 views

Introduction to Web Application Security presented at for the Penn State Information Assurance Club (Fall 2007)

Introduction to Web Application Security presented at for the Penn State Information Assurance Club (Fall 2007)

Statistics

Views

Total Views
7,307
Views on SlideShare
7,301
Embed Views
6

Actions

Likes
1
Downloads
201
Comments
0

2 Embeds 6

http://www.slideshare.net 4
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Intro to Web Application Security Intro to Web Application Security Presentation Transcript

    • Information Assurance Club 2007 Understanding Web Application Security
    • What is Application Security?
      • Application Security encompasses measures taken to prevent exceptions in the security policy of an application or the underlying system vulnerabilities through flaws in the design, development, or deployment of the application. [Wikipedia]
      • Make sure code
      • Properly uses security mechanisms
      • Has no design or implementation flaws
    •  
    •  
    • Application Layer VS Network Layer
      • Application Layer
        • Attackers send attacks inside valid HTTP requests
        • Custom code is manipulated to do something it shouldn’t
        • Security requires software development expertise, not signatures
      • Network Layer
        • Firewall, hardening, patches, IDS, IPS
        • SSL cannot detect or prevent attacks inside HTTP requests
        • Security based on signature database
    • Test Your Hacking Knowledge
      • What might happen in an application if an attacker…
        • Adds “; rm –rf /” to a menu selection passed to a system call
        • Replaces the unitprice hidden field with -500
        • Sends 1000000 ‘A’ characters to a login script
        • Figures out the encoding used for cookies
        • Disables all client side Javascript for form validation
        • Adds to the end of an account ID parameter “%27%20OR%201%3d1”
        • Sends 1,000 HTTP requests per second to the search field for an hour
    • Why Should I Care?
      • How likely is a successful web application attack?
        • Anyone in the world, including insiders, can send an HTTP request to your server
        • Vulnerabilities are highly prevalent
        • Easy to exploit without special tools or knowledge
        • Little chance of being detected
        • Hundreds of thousands of developers with no security background or training
      • Consequences?
        • Corruption or disclosure of database contents
        • Root access to web and application servers
        • Loss of authentication and access control for users
        • Defacement
        • Loss of use / availability
        • Secondary attacks from your site
      • Application security is just as important as Network Security
    • Attacks Shift Towards Application Layer
      • 75% of All Attacks on Information Security Are Directed to the Web Application Layer
      • 2/3 of All Web Applications Are Vulnerable
      • -Gartner
    • How Do Attackers Do It?
      • Proxies
      • Browser plugins
      • Vulnerability scanning tools
      • Many attacks can be launched using only a browser and text editor
    • HyperText Transfer Protocol (HTTP) GET /index.html HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Date: Mon, 23 April 2007 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8
    • HTTPS
      • Just encryption
      • Eavesdropping
        • Protect Passwords
        • Gmail
      • Bypass IPS
      • Doesn't prevent hacking
    • Transparent Proxy
      • http://fiddler2.com/sandbox/
      • Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
      • Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more.
      • Others: Paros, Web Scarab, etc
    • Authentication Common Problems
      • Never expire (facebook)
      • Not protected by SSL
      • Easy to forge (cookies)
      • Replay attacks
        • Re-using cookies
        • Preventable with encrypted date/time stamp
    • Authentication Best Practices
      • Ensure HTTPS is being used
      • Login failures should NOT indicate whether username or password failed
      • Strong password policy (don’t store in clear text)
      • Use brute force countermeasures
        • CAPTCHA
        • Time delay
    • State Problems
      • HTTP is a stateless protocol
      • Session ID tells client browser who you are
      • Server maintains a map of session objects
      • Hijacking techniques
        • Guessing
        • XSS
        • Not using HTTPS
        • Session ID exposed using URL-rewriting
    • Session Best Practices
      • Single sign on/off
      • Seemingly random and at least 20 bytes
      • Timeout
      • Use SSL
      • Avoid URL-rewriting (disclosure risk)
    • Access Control
      • Restricting access
        • Who?
        • What can they see?
        • What can they do?
      • Should exist in UI, BLL, and DAL
    • Broken Access Control
      • Attacker notices URL indicating role
        • / guest /getAccountInfo
      • They modify it to another directory (role)
        • / admin /getAccountInfo
        • / auth /getAccountInfo
      • Attacker views more accounts than just their own
    • Cross-Site Scripting (XSS)
      • Web application vulnerability that allows an attacker to execute a malicious script in a victim's web browser
      • How it works
        • Web browsers support scripting languages like Javascript that allow web pages to perform logic
        • If an attacker can get a web server to send their malicious script to a victim, the script executes as if it came from that web site
      • Consequences
        • Steal session cookies
        • Deface websites
        • Information disclosure
    • XSS Vulnerability Pattern
      • Web app vulnerable to XSS if
        • Attacker can provide malicious user input
        • Site puts user input into a response
          • Search, form field, message board, etc
        • Site doesn't properly validate or sanitize that user input
          • Unless developer is familiar with XSS, it's very likely that proper input validation is not being done
    • Two Types of XSS
      • Stored XSS
        • Dangerous user input is stored on the site and displayed at some later time
        • Typically found in message boards, guest books, surveys
        • Like leaving a land mine for a victim to trip across on a vulnerable site
      • Reflected XSS
        • Dangerous user input is immediately sent back to the user that submitted it
        • Possibly a malicious link with an embedded script
        • Typically found in search fields, error pages, etc
    • Cross-site Scripting - Tricks
      • Scripts can only access data from their own site
        • Enforced by the browser “sandbox” SOP
          • Trick: Use an anonymous proxy
        • Scripts can't access the OS or file system
          • Trick: Wscript
          • http://my.3c.ist.psu.edu/rrr174/email.js
      • The browser isn't doing anything abnormal
      • Cheat Sheet: http://ha.ckers.org/xss.html
      • Demos: http://www.attacklabs.com
    • XSS Real World Example
      • MySpace XSS Worm – Oct 2005
        • AKA Samy worm
        • Introduced an XSS attack into his own profile
        • When anyone viewed his profile, the attack:
          • added Samy as a 'friend' to that user's profile
          • and infected them with the same XSS attack in their own profile
          • Then, when anyone views the infected profile, starts all over...
      • The exploit:
        • Used 'java script' since 'javascript' was filtered out, String.fromCharCode(34) to generate a double quote, etc.
        • Used XmlHttpRequest (AJAX), so does Yamanner worm
        • 10 hrs – 560 friends, 13 hrs – 6400 friends, 18 hrs - 1,000,000 friends, 19 hrs - entire site down, 22 hrs – site back up again
    •  
    • XSS– Input Filters
      • Many applications attempt XSS protection with filters
        • Convert < and > to &lt and &gt
        • Strip out HTML tags
        • Eliminate <script> tags
        • Strip out Javascript
      • .NET provides XSS protection by default
        • <%@ Page ValidateRequest=”true” %>
        • Anti-Cross Site Scripting Library
          • http://msdn2.microsoft.com/en-us/security/aa973814.aspx
      • Better to white list input instead of black list
      • VALIDATE USER INPUT!!! TRUST NOTHING FROM THE CLIENT!!!
    • PSU Webmail XSS
      • https://webmaillite.psu.edu/webmail/inbox.cgi?mailbox =
      • https://my.3c.ist.psu.edu/rrr174/xss.js
      • popMessage param (cookie)
      • Now what?
      • Hijack web access session ID
      • Steal email
      • Go phishing
      • Do anything the user can do
    • View Passwords
      • javascript:(function(){var s,F,j,f,i; s = %22%22; F = document.forms; for(j=0; j<F.length; ++j) { f = F[j]; for (i=0; i<f.length; ++i) { if (f[i].type.toLowerCase() == %22password%22) s += f[i].value + %22 %22; } } if (s) alert(%22Passwords in forms on this page: %22 + s); else alert(%22There are no passwords in forms on this page.%22);})();
    • CSRF (Sea-Surf)
      • Cross-site request forgery, also known as one click attack or session riding
      • Digg and Amazon have been targets
      • Prevention
        • Include a secret, user-specific token in forms that is verified in addition to the cookie
        • Users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session
    • Injection Overview
      • Many applications invoke interpreters
        • SQL
        • OS command shell (cmd.exe, perl)
        • Sendmail, LDAP, XPath, XSLT
      • Interpreters take commands and data and execute the instructions
        • Attacker can send malicious data or commands into your application tricking it into behaving differently
      • Frequently interpreters run as root or administrator
    • SQL Injection – Example
      • Get rows from table based on user provided parameter
        • SELECT * FROM users WHERE SSN='” + ssn + “'”
      • SSN goes from user to web application to database
        • Never validated
        • Attacker sends 123456789' OR '1'='1
      • Application builds a query
        • SELECT * FROM users WHERE SSN='123456789' OR '1'='1'
        • Returns every user in the database
      • Blind SQL Injection: http://www.0x90.org/releases/absinthe
    • Prevent SQL Injection
      • Validate user input
      • Stored procedures
      • Parameterized queries
      • Connection strings (Access Control)
        • Prevent DELETE and DROP queries
    • Injection Demo SQL Injection: Almost every IST student’s web application is vulnerable https://my.3c.ist.psu.edu/jeb5010/customer.php?Name ='%20OR%201=1-- Remote Code Execution: http://scripts.cac.psu.edu/pxn126/finger.cgi
    • Conclusion
      • Be aware of security threats
        • Train yourself
      • Assess security at every step of the SDLC
      • Define unacceptable risks
        • Then implement policy
        • Ensure accountability
      • Consider commercial solutions (Get help)
    • Where can I learn more?
      • http://www.owasp.org/index.php/OWASP_Top_Ten_Project
      • http://en.wikipedia.org/wiki/Category:Web_security_exploits
      • http://www.spidynamics.com/spilabs/index.html
      • http://ha.ckers.org
      • http://johnny.ihackstuff.com/ghdb.php
      • http://www.foundstone.com/resources/freetools.htm
      • http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
      • http://blogged-on.de/xss
      • http://leastprivilege.com
      • Download this presentation
        • http://my.3c.ist.psu.edu/rrr174/webappsec.ppt
    • Questions? Ask questions and I'll try to answer them