OWASP Top 10 for 2010

Download OWASP Top 10 for 2010

Post on 03-Jan-2016

25 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

OWASP Education Computer based training. OWASP Top 10 for 2010. Keith Turpin The Boeing Company Application Security Assessments Lead OWASP Secure Coding Practices Lead OWASP Global Projects Committee keith.turpin@owasp.org. Nishi Kumar - PowerPoint PPT Presentation

TRANSCRIPT

<ul><li><p>*Objectives Understand OWASP Top 10 Understand methodology used to choose OWASP Top 10 for 2010 Understand how OWASP Top 10 relates to CWE/SANS Top 25 Identify and Remediate vulnerabilities from OWASP Top 10 </p></li><li><p>*OWASP Top 10 2010Risk Rating Methodology</p></li><li><p>*OWASP Top 10</p></li><li><p>*OWASP ESAPI 2.0 &amp; OWASP Top 10 for 2010 mappingA1: Injection</p><p>A2: Cross-Site Scripting (XSS)A3: Broken Authentication and Session ManagementA4: Insecure Direct Object ReferencesA5: Cross-Site Request Forgery (CSRF)A6: Security MisconfigurationA7: Insecure Cryptographic StorageA8: Failure to Restrict URL AccessA9: Insufficient Transport Layer ProtectionA10: Unvalidated Redirects and ForwardsEncoderEncoder, ValidatorAuthenticator, User, HTTPUtilitiesAccessReferenceMap, AccessControllerUser (CSRF Token)Security ConfigurationEncryptorAccessControllerHTTPUtilities AccessController</p></li><li><p>*OWASP Top 10 &amp; SANS CWE Top 25 mapping</p><p>https://www.owasp.org/index.php/ Category:OWASP_Top_Ten_Projecthttp://www.sans.org/top25-software-errors/http://cwe.mitre.org/top25/A1: Injection[2] CWE-89: </p><p>[9] CWE-78: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')A2: Cross-Site Scripting (XSS)[1] CWE-79: Improper Neutralization of Input During Web Page Generation('Cross-site Scripting')A3: Broken Authentication and Session Management[19] CWE-306:[11] CWE-798: Missing Authentication for Critical FunctionUse of Hard-coded CredentialsA4: Insecure Direct Object References[5] CWE-285:[6] CWE-807:[7] CWE-22: Improper AuthorizationReliance on Untrusted Inputs in a Security DecisionImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal')A5: Cross-Site Request Forgery (CSRF)[4] CWE-352: Cross-Site Request Forgery (CSRF)</p></li><li><p>*OWASP Top 10 &amp; SANS CWE Top 25 mapping</p><p>A6: Security Misconfiguration[16] CWE-209: Information Exposure Through an Error Message (Only partially covers OWASP Risk)A7: Insecure Cryptographic Storage[10] CWE-311: [24] CWE-327: Missing Encryption of Sensitive Data Use of a Broken or Risky Cryptographic AlgorithmA8: Failure to Restrict URL Access[5] CWE-285:</p><p>[21] CWE-732: Improper Authorization (Also listed with OWASP A-4)Incorrect Permission Assignment for Critical Resource (CWE-732 covers a broader scope than OWASP A8)A9: Insufficient Transport Layer Protection[10] CWE-311:</p><p>[24] CWE-327: Missing Encryption of Sensitive Data (Also listed with OWASP A-7)Use of a Broken or Risky Cryptographic Algorithm (Also listed with OWASP A-7)A10: Unvalidated Redirects and Forwards[23] CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</p></li><li><p>OWASP Top 10 &amp; SANS CWE Top 25 mappingNot a comprehensive or equivalent comparisonOWASP defines ten risks - made up of several specific vulnerabilitiesSANS CWE Top 25 is only a fraction of the full CWE list of weaknessesComplete mapping will have many CWEs listed for each item on the OWASP Top 10 list Mapping should be used for general reference purposes only*</p></li><li><p>*A1 Injection</p></li><li><p>A1 Injection*What are injection flaws? User Name: SamPassword: 123xyz SELECT * FROM USERS WHERE USERNAME=Sam' ANDPASSWORD='123xyz User Name: SamPassword: '; DROP DATABASE MAIN_DATABASE; --SELECT * FROM USERS WHERE USERNAME=Sam' ANDPASSWORD=' '; DROP DATABASE MAIN_DATABASE; -- '</p></li><li><p>A1 Injection*FirewallHardened OSWeb ServerApp ServerFirewallDatabasesLegacy SystemsWeb ServicesDirectoriesHuman ResrcsBillingCustom CodeAPPLICATION ATTACKNetwork LayerApplication LayerAccountsFinanceAdministrationTransactionsCommunicationKnowledge MgmtE-CommerceBus. FunctionsHTTP requestSQL queryDB Table HTTP response "SELECT * FROM accounts WHERE acct= OR 1=1--"1. Application presents a form to the attacker2. Attacker sends an attack in the form data3. Application forwards attack to the database in a SQL queryAccount Summary</p><p>Acct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-02934. Database runs query containing attack and sends encrypted results back to application5. Application decrypts data as normal and sends results to the user</p></li><li><p>A1 Avoiding Injection Flaws*Recommendations Avoid the interpreter entirely, orUse an interface that supports bind variables (e.g., prepared statements, or stored procedures),Bind variables allow the interpreter to distinguish between code and data</p><p>Encode all user input before passing it to the interpreterAlways perform white list input validation on all user supplied inputAlways minimize database privileges to reduce the impact of a flawReferencesFor more details, read the new http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet </p></li><li><p>*</p></li><li><p>*A2 Cross-Site Scripting (XSS)</p></li><li><p>Application with stored XSS vulnerability32Attacker sets the trap update my profileAttacker enters a malicious script into a web page that stores the data on the server1Victim views page sees attacker profileScript silently sends attacker Victims session cookieScript runs inside victims browser with full access to the DOM and cookies*</p></li><li>A2 Avoiding XSS FlawsRecommendationsEliminate FlawDont include user supplied input in the output pageDefend Against the FlawPrimary Recommendation: Output encode all user supplied input (Use OWASPs ESAPI to output encode:http://www.owasp.org/index.php/ESAPI Perform white list input validation on all user input to be included in pageFor large chunks of user supplied HTML, use OWASPs AntiSamy to sanitize this HTML to make it safe See: http://www.owasp.org/index.php/AntiSamyReferencesFor how to output encode properly, read the new http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet * E.g. output encoding with HTML entity encoding: The &lt; character becomes: &lt; The " character becomes: " This tag becomes: </li><li>Safe Escaping Schemes in Various HTML Execution ContextsHTML Style Property Values(e.g., .pdiv a:hover {color: red; text-decoration: underline} )JavaScript Data(e.g., some javascript )HTML Attribute Values(e.g., )HTML Element Content(e.g., some text to display )URI Attribute Values(e.g., </li><li><p>A3 Broken Authentication and Session Management*</p></li><li><p>1User sends credentials2Site uses URL rewriting(i.e., put session in URL)3User clicks on a link to http://www.hacker.com in a forumwww.boi.com?JSESSIONID=9FA1DB9EA...4Hacker checks referer logs on www.hacker.comand finds users JSESSIONID5Hacker uses JSESSIONID and takes over victims account*</p></li><li><p>A3 Avoiding Broken Authentication and Session ManagementVerify your architectureAuthentication should be simple, centralized, and standardizedUse the standard session id provided by your containerBe sure SSL protects both credentials and session id at all timesVerify the implementationForget automated analysis approaches. (Automated scanners are not good at detecting authentication and session management issues)Check your SSL certificateExamine all the authentication-related functionsVerify that logoff actually destroys the sessionUse OWASPs WebScarab to test the implementationFollow the guidance fromhttp://www.owasp.org/index.php/Authentication_Cheat_Sheet *</p></li><li><p>A4 Insecure Direct Object References*</p></li><li><p>Attacker notices his acct parameter is 6065 ?acct=6065</p><p>He modifies it to a nearby number ?acct=6066</p><p>Attacker views the victims account informationhttps://www.onlinebank.com/user?acct=6065*</p></li><li><p>A4 Avoiding Insecure Direct Object ReferencesEliminate the direct object referenceReplace them with a temporary mapping value (e.g. 1, 2, 3)ESAPI provides support for numeric &amp; random mappings </p><p>Validate the direct object referenceVerify the parameter value is properly formattedVerify the user is allowed to access the target objectQuery constraints work great!Verify the requested mode of access is allowed to the target object (e.g., read, write, delete)</p><p>*http://app?file=Report123.xlshttp://app?file=1</p><p>http://app?id=9182374 http://app?id=7d3J93</p></li><li><p>A5 Cross Site Request Forgery (CSRF)*</p></li><li><p>CSRF Vulnerability PatternThe ProblemWeb browsers automatically include most credentials with each requestEven for requests caused by a form, script, or image on another siteAll sites relying solely on automatic credentials are vulnerable!(almost all sites are this way)Automatically Provided CredentialsSession cookieBasic authentication headerIP addressClient side SSL certificatesWindows domain authentication</p><p>*</p></li><li><p>*A5 Cross Site Request Forgery Illustrated</p></li><li><p>A5 Avoiding CSRF FlawsAdd a secret, not automatically submitted, token to ALL sensitive requestsThis makes it impossible for the attacker to spoof the request(unless theres an XSS hole in your application)Tokens should be cryptographically strong or randomOptionsStore a single token in the session and add it to all forms and linksHidden Field: Single use URL: /accounts/687965fdfaew87agrdeForm Token: /accounts?auth=687965fdfaew87agrde Beware exposing the token in a referer headerHidden fields are recommendedCan have a unique token for each functionUse a hash of function name, session id, and a secretCan require secondary authentication for sensitive functions (e.g., eTrade)Dont allow attackers to store attacks on your siteProperly encode all input on the way outThis renders all links/requests inert in most interpreters See: www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet for more details*</p></li><li><p>A6 Security Misconfiguration*</p></li><li><p>Hardened OSWeb ServerApp ServerFrameworkSecurity Misconfiguration IllustratedApp ConfigurationCustom CodeAccountsFinanceAdministrationTransactionsCommunicationKnowledge MgmtE-CommerceBus. FunctionsTest ServersQA ServersSource ControlDevelopmentDatabaseInsider*</p></li><li><p>A6 Avoiding Security MisconfigurationVerify your systems configuration managementSecure configuration hardening guidelineAutomation is REALLY USEFUL hereMust cover entire platform and applicationKeep up with patches for ALL componentsThis includes software libraries, not just OS and Server applicationsAnalyze security effects of changes</p><p>Can you dump the application configurationBuild reporting into your processIf you cant verify it, it isnt secure</p><p>Verify the implementationScanning finds generic configuration and missing patch problems*</p></li><li><p>A7 Insecure Cryptographic Storage*</p></li><li><p>Insecure Cryptographic Storage Illustrated1Victim enters credit card number in form2Error handler logs CC details because merchant gateway is unavailable4Malicious insider steals 4 million credit card numbersLog files3Logs are accessible to all members of IT staff for debugging purposes*</p></li><li><p>A7 Avoiding Insecure Cryptographic StorageVerify your architectureIdentify all sensitive dataIdentify all the places that data is storedEnsure threat model accounts for possible attacksUse encryption to counter the threats, dont just encrypt the dataProtect with appropriate mechanismsFile encryption, database encryption, data element encryptionUse the mechanisms correctlyUse standard strong algorithms such as FIPS 140-2 (i.e. Triple-DES, AES, RSA) or an equivalent standardGenerate, distribute, and protect keys properlyBe prepared for key changeVerify the implementationA standard strong algorithm is used, and its the proper algorithm for this situationAll keys, certificates, and passwords are properly stored and protectedSafe key distribution and an effective plan for key change are in place Analyze encryption code for common flaws</p></li><li><p>A8 Failure to Restrict URL Access*</p></li><li><p>Failure to Restrict URL Access IllustratedAttacker notices the URL indicates his role /user/getAccountsHe modifies it to another directory (role) /admin/getAccounts, or /manager/getAccountsAttacker views more accounts than just their own</p></li><li><p>A8 Avoiding URL Access Control FlawsFor each URL, a site needs to do 3 thingsRestrict access to authenticated users (if not public)Enforce any user or role based permissions (if private)Completely disallow requests to unauthorized page types (e.g., config files, log files, source files, etc.)Verify your architectureUse a simple, positive model at every layerBe sure you actually have a mechanism at every layerVerify the implementationForget automated analysis approachesVerify that each URL in your application is protected by eitherAn external filter, like Java EE web.xml or a commercial productOr internal checks in YOUR code Use ESAPIs isAuthorizedForURL() methodVerify the server configuration disallows requests to unauthorized file typesUse WebScarab or your browser to forge unauthorized requests</p></li><li><p>A9 Insufficient Transport Layer Protection</p></li><li><p>Insufficient Transport Layer Protection IllustratedCustom CodeEmployeesBusiness PartnersExternal VictimBackend SystemsExternal Attacker1External attacker steals credentials and data off network2Internal attacker steals credentials and data from internal networkInternal Attacker</p></li><li><p>A9 Avoiding Insufficient Transport Layer ProtectionProtect with appropriate mechanismsUse TLS on all connections with sensitive dataIndividually encrypt messages before transmissionE.g., XML-EncryptionSign messages before transmissionE.g., XML-Signature</p><p>Use the mechanisms correctlyUse standard strong algorithms (disable old SSL algorithms)Manage keys/certificates properlyVerify SSL certificates before using themUse proven mechanisms when sufficientE.g., SSL vs. XML-Encryption See: http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat Sheet for more details</p></li><li><p>A10 Unvalidated Redirects and Forwards</p></li><li><p>Unvalidated Redirect Illustrated32Attacker sends attack to victim via email or webpageFrom: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim.1Application redirects victim to attackers siteRequest sent to vulnerable site, including attackers destination site as parameter. Redirect sends victim to attacker site4Evil site installs malware on victim, or phishs for private informationVictim clicks link containing unvalidated parameterEvil Sitehttp://www.irs.gov/taxrefund/claim.jsp?year=2006&amp; &amp;dest=www.evilsite.com</p></li><li><p>Unvalidated Forward Illustrated2Attacker sends attack to vulnerable page they have access to1Application authorizes request, which continues to vulnerable pageRequest sent to vulnerable page which user does have access to. Redirect sends user directly to private page, bypassing access control.3Forwarding page fails to validate parameter, sending attacker to unauthorized page, bypassing access controlpublic void doPost( HttpServletRequest request, HttpServletResponse response) {try {String target = request.getParameter( "dest" ) );...request.getRequestDispatcher( target ).forward(request, response);}catch ( ...</p><p>Filterpublic void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) {try {// Do sensitive stuff here....}catch ( ...</p></li><li><p>A10 Avoiding Unvalidated Redirects and ForwardsThere are a number of optionsAvoid using redirects and forwards as much as you canIf used, dont involve user parameters in defining the target URLIf you must involve user par...</p></li></ul>