Web Application Security Workshop

  • Published on

  • View

  • Download

Embed Size (px)


Web Application Security Workshop. James Walden. About the Speaker. Background Ph.D. from Carnegie Mellon University 10 years of secure development experience. Gives workshops in secure programming and software security at a variety of conferences. Assistant Professor at NKU - PowerPoint PPT Presentation


<ul><li><p>Web Application Security WorkshopJames Walden</p></li><li><p>About the SpeakerBackgroundPh.D. from Carnegie Mellon University10 years of secure development experience.Gives workshops in secure programming and software security at a variety of conferences.</p><p>Assistant Professor at NKUSpecialize in software security.4 years experience teaching security.</p></li><li><p>What is web application security?The art and science of developing web applications that function correctly even when under attack.</p></li><li><p>Firewalls dont protect web apps</p></li><li><p>What is web application security?Its more than just cryptography.SSL wont solve all your problems.Its more than securing the web server.Web applications have their own problems.Its more than application firewalls.Firewall cant know every safe action at every possible state in your application.</p></li><li><p>The source of the problemMalicious hackers dont create security holes; they simply exploit them. Security holes and vulnerabilities the real root cause of the problem are the result of bad software design and implementation.</p><p>John Viega &amp; Gary McGraw</p></li><li><p>Penetrate and PatchDiscover flaws after deployment.Often by attackers.Users may not deploy patches.Patches may have security flaws (15%?)Patches are maps to vulnerabilities.Attackers reverse engineer to create attacks.</p></li><li><p>A Growing Problem</p></li><li><p>Vulnerability Trends for 2006</p></li><li><p>Web Application VulnerabilitiesInput-based Security ProblemsInjection FlawsInsecure Remote File InclusionUnvalidated InputAuthentication and AuthorizationCross-Site ScriptingAuthenticationAccess ControlOther BugsError Handling and Information LeakageInsecure StorageInsecure Communications</p></li><li><p>InjectionInjection attacks trick an application into including unintended commands in the data send to an interpreter.InterpretersInterpret strings as commands.Ex: SQL, shell (cmd.exe, bash), LDAP, XPathKey IdeaInput data from the application is executed as code by the interpreter.</p></li><li><p>SQL InjectionApp sends form to user.Attacker submits form with SQL exploit data.Application builds string with exploit data.Application sends SQL query to DB.DB executes query, including exploit, sends data back to application.Application returns data to user.AttackerWeb ServerDB ServerFirewallUserPass or 1=1--</p></li><li><p>SQL Injection in PHP$link = mysql_connect($DB_HOST, $DB_USERNAME, $DB_PASSWORD) or die ("Couldn't connect: " . mysql_error());mysql_select_db($DB_DATABASE);$query = "select count(*) from users where username = '$username' and password = '$password'";$result = mysql_query($query);</p></li><li><p>SQL Injection Attack ExampleUnauthorized Access Attempt:password = or 1=1 --SQL statement becomes:select count(*) from users where username = user and password = or 1=1 --Checks if password is empty OR 1=1, which is always true, permitting access.</p></li><li><p>Impact of SQL InjectionSELECT SSN FROM USERS WHERE UID=$UID</p></li><li><p>SQL Injection Demo</p></li><li><p>Impact of SQL InjectionLeakage of sensitive information.Legal consequences of losing PII.PR consequences of losing PII.Modification of sensitive information.Loss of sensitive information.Denial of service against db server.</p></li><li><p>The Problem: String BuildingBuilding a SQL command string with user input in any language is dangerous.Variable interpolation.String concatenation with variables.String format functions like sprintf().String templating with variable replacement.</p></li><li><p>Mitigating SQL InjectionIneffective MitigationsBlacklistsStored Procedures</p><p>Effective MitigationsWhitelistsPrepared Queries</p></li><li><p>Ineffective Mitigation: BlacklistFilter out known bad SQL metacharacters,such as single quotes.Problems:Numeric parameters dont use quotes.URL escaped metacharacters.Unicode encoded metacharacters.Did you miss any metacharacters?2nd Order SQL Injection.</p></li><li><p>Ineffective Mitigation: Stored ProceduresSQL Stored Procedures build strings too:</p><p>CREATE PROCEDURE dbo.doQuery(@id nchar(128)AS DECLARE @query nchar(256) SELECT @query = SELECT cc FROM cust WHERE id= + @id + EXEC @queryRETURN</p></li><li><p>Mitigation: WhitelistReject input that doesnt match your list of safe characters to accept.Identify whats good, not whats bad.Reject input instead of attempting to repair.Still have to deal with single quotes when required, such as in names.</p></li><li><p>Mitigation: Prepared Queriesrequire_once 'MDB2.php'; </p><p>$mdb2 =&amp; MDB2::factory($dsn, $options); if (PEAR::isError($mdb2)) {die($mdb2-&gt;getMessage()); } $sql = SELECT count(*) from users where username = ? and password = ?;$types = array('text', 'text'); $sth = $mdb2-&gt;prepare($sql, $types, MDB2_PREPARE_MANIP); $data = array($username, $password); $sth-&gt;execute($data); </p></li><li><p>Insecure Remote File InclusionInsecure remote file inclusion vulnerabilities allow an attack to trick the application into executing code provided by the attacker on another site.Dynamic codeIncludes in PHP, Java, .NETDTDs for XML documentsKey IdeaAttacker controls pathname for inclusion.</p></li><li><p>Impact of Remote File InclusionLoss of control of web application.Installation of malware.Attacks launched against other sites.Denial of service.</p></li><li><p>Mitigating Remote File InclusionTurn off remote file inclusion.Do not run code from uploaded files.Do not use user-supplied paths.Validate all paths before loading code.</p></li><li><p>Unvalidated InputUnvalidated input is an architecture flaw.Individual input-related bugs are easy to fix.How do you defend against the general problem of input-based attacks?Key IdeasApplication needs to validate all input.Input validation needs to be part of design.</p></li><li><p>Input Validation PrinciplesAll input must be validated.Input must be validated on the server.Use a standard set of validation rules.Reject all input that isnt in your whitelist.Blacklists can miss bad inputs.Input repairs can produce bad input.</p></li><li><p>Input Validation ArchitectureView</p><p>Output encoding.Controller</p><p> General input validation.Model</p><p>Model-specific validation.ValidationRulesView SelectionStateChangeUser InputStateQueryChangeNotice</p></li><li><p>Validating InputCheck that input matches specified:Data typeCharacter setInput lengthNULLs or empty strings allowed?Numeric rangeList of legal valuesList of patterns</p></li><li><p>Impact of Unvalidated InputMore input-related vulnerabilities.Loss of application integrity.Loss of sensitive information.Effort required to patch individual input-related bugs.</p></li><li><p>Mitigating Unvalidated InputDesign for input validation.Architect app so all input is checked.Create a standard library of validation rules.Use a whitelist approach.Educate developers about validation.Verify that all input is validated.</p></li><li><p>Cross-Site Scripting (XSS)Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attackers choosing.XSS used to obtain session ID forBank site (transfer money to attacker)Shopping site (buy goods for attacker)Key ideasAttacker sends malicious code to server.Victims browser loads code from server and runs it.</p></li><li><p>Anatomy of an XSS Attack1. Login2. CookieWeb Server3. XSS AttackAttackerUser4. User clicks on XSS link.5. XSS URL7. Browser runs injected code.Evil site saves ID.</p><p>8. Attacker hijacks user session.6. Page with injected code.</p></li><li><p>XSS URL Exampleshttp://www.microsoft.com/education/?ID=MCTN&amp;target=http://www.microsoft.com/education/?ID=MCTN&amp;target="&gt;alert(document.cookie)</p><p>http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=alert(Test);</p><p>http://www.shopnbc.com/listing.asp?qu=alert(document.cookie)&amp;frompage=4&amp;page=1&amp;ct=VVTV&amp;mh=0&amp;sh=0&amp;RN=1</p><p>http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E</p></li><li><p>Why does XSS Work?Same-Origin PolicyBrowser only allows Javascript from site X to access cookies and other data from site X.Attacker needs to make attack come from site X.Vulnerable Server ProgramAny program that returns user input without filtering out dangerous code.</p></li><li><p>Impact of XSSAttackers can hijack user accounts.Attackers can hijack admin accounts too.Attacker can do anything a user can do.Difficult to track down source of attack.</p></li><li><p>Mitigating XSSDisallow HTML inputAllow only safe HTML tagsFilter outputReplace HTML special characters in outputex: replace &lt; with &lt; and &gt; with &gt;also replace (, ), #, &amp;Tagged cookiesInclude IP address in cookie and only allow access to original IP address that cookie was created for.</p></li><li><p>AuthenticationAuthentication is the process of determining a users identity.Key IdeasHTTP is a stateless protocol.Every request must be authenticated.Use username/password on first request.Use session IDs on subsequent queries.</p></li><li><p>Authentication AttacksSniffing passwordsGuessing passwordsIdentity management attacksReplay attacksSession ID fixationSession ID guessing</p></li><li><p>Impact of Authentication AttacksAttackers can hijack user accounts.Attackers can hijack admin accounts too.Attacker can do anything a user can do.Difficult to track down source of attack.</p></li><li><p>Mitigating Authentication AttacksUse SSL to prevent sniffing attacks.Require strong passwords.Use secure identity management.Use a secure session ID mechanism.IDs chosen at random from large space.Regenerate session IDs with each request.Expire session IDs in short time.</p></li><li><p>Access ControlAccess control determines which users have access to which system resources.Levels of access controlSiteURLFunctionFunction(parameters)Data</p></li><li><p>Impact of Broken Access ControlAccess to other customers accounts.Execute code as other users.Execute administrative code.Leakage of sensitive information.Legal consequences of losing PII.PR consequences of losing PII.</p></li><li><p>Mitigating Broken Access ControlCheck every access.Use whitelist model at every layer.Do not rely on client-level access control.Do not rely on security through obscurity.</p></li><li><p>Improper Error HandlingApplications can unintentionally leak information about configuration, architecture, or sensitive data when handling errors improperly.Errors can provide too much dataStack tracesSQL statementsSubsystem errorsUser typos, such as passwords.</p></li><li><p>Impact of Improper Error HandlingReturning user input can create a cross-site vulnerability.Information leakage can increase the probability of a successful attack against the application.Leakage of sensitive information.Legal consequences of losing PII.PR consequences of losing PII.</p></li><li><p>Mitigating Improper Error HandlingCatch all exceptions.Check all error codes.Wrap application with catch-all handler.Send user-friendly message to user.Store details for debugging in log files.Dont log passwords or other sensitive data.</p></li><li><p>Insecure StorageStoring sensitive data without encrypting it, or using a weak encryption algorithm, or using a strong encryption system improperly.ProblemsNot encrypting sensitive data.Using home grown cryptography.Insecure use of weak algorithms.Storing keys in code or unprotected files.</p></li><li><p>Impact of Insecure StorageLeakage of sensitive information.Legal consequences of losing PII.PR consequences of losing PII.</p></li><li><p>Storage RecommendationsHash algorithmsMD5 and SHA1 look insecure.Use SHA256.Encrypting dataUse AES with 128-bit keys.Key generationGenerate random keys.Use secure random source.</p></li><li><p>Mitigating Insecure StorageUse well studied public algorithms.Use truly random keys.Store keys in protected files.Review code to ensure that all sensitive data is being encrypted.Check database to ensure that all sensitive data is being encrypted.</p></li><li><p>Insecure CommunicationApplications fail to encrypt sensitive data in transit from client to server and vice-versa.Need to protectUser authentication and session data.Sensitive data (CC numbers, SSNs)Key IdeaUse SSL for all authentication connections.</p></li><li><p>Impact of Insecure CommunicationAttackers can hijack user accounts.Attacker can do anything a user can do.Leakage of sensitive information.Legal consequences of losing PII.PR consequences of losing PII.</p></li><li><p>Mitigating Insecure CommunicationUse SSL for all authenticated sessions.Use SSL for all sensitive data.Verify that SSL is used with automated vulnerability scanning tools.</p></li><li><p>Going Further</p></li><li><p>ReferencesMark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007.Java Gotchas, http://mindprod.com/jgloss/gotchas.html, 2007.Mitre, Common Weaknesses Vulnerability Trends, http://cwe.mitre.org/documents/vuln-trends.html, 2007.Gary McGraw, Software Security, Addison-Wesley, 2006.J.D. Meier, et. al., Improving Web Application Security: Threats and Countermeasures, Microsoft, http://msdn2.microsoft.com/en-us/library/aa302418.aspx, 2006.OWASP Top 10, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2007.Ivan Ristic, Web Application Firewalls: When Are They Useful?, OWASP AppSec EU 2006.Joel Scambray, Mike Shema, and Caleb Sima, Hacking Exposed: Web Applications, 2nd edition, Addison-Wesley, 2006.</p><p>Diagram from Ivan OWASP AppSec EU 2006.Trend data from MITRE CWE.</p></li></ul>


View more >