Uploaded on

null Mumbai Chapter - May 2013 Meet

null Mumbai Chapter - May 2013 Meet

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • thanks
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
1,851
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
1
Likes
9

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OWASP TOP 10 - 2013Nitin Sharma
  • 2. 1. Injection2. Broken authentication/session management3. Cross-site scripting4. Insecure Direct object refrences5. Security Misconfiguration6. Sensitive Data Exposure7. Missing function level access control8. Cross site request forgery9. Using components with more vulnerabilities10. Unvalidated Redirects and ForwardsOWASP Top 10 Web ApplicationSecurity Vulnerabilities
  • 3.  SQL injection is a software vulnerability that occurswhen data entered by users is sent to the SQLinterpreter as a part of an SQL query Attackers provide specially crafted input data to theSQL interpreter and trick the interpreter to executeunintended commands a SQL Injection attack exploits security vulnerabilitiesat the database layer. By exploiting the SQL injectionflaw, attackers can create, read, modify, or deletesensitive dataA1 Injection
  • 4. Am I Vulnerable To Injection? The best way to find out if an application is vulnerableto injection is to verify that all use of interpretersclearly separates untrusted data from the commandor query. For SQL calls, this means using bindvariables in all prepared statements and storedprocedures, and avoiding dynamic queries.
  • 5.  Preventing injection requires keeping untrusted data separatefrom commands and queries. 1.The preferred option is to use a safe API which avoids the useof the interpreter entirely or provides a parameterizedinterface. Be careful of APIs, such as stored procedures, thatare parameterized, but can still introduce injection under thehood. 2.If a parameterized API is not available, you should carefullyescape special characters using the specific escape syntax forthat interpreter. OWASP’s ESAPI provides many of theseescaping routines. 3.Positive or “white list” input validation with appropriatecanonicalization is also recommended, but is not a completedefense as many applications require special characters intheir input. OWASP’s ESAPI has an extensible library of whitelist input validation routines.How Do I Prevent Injection?
  • 6. ExampleString custname = request.getParameter("customerName"); // This shouldREALLY be validated too// perform input validation to detect attacksString query = "SELECT account_balance FROM user_data WHEREuser_name = ? ";PreparedStatement pstmt = connection.prepareStatement( query );pstmt.setString( 1, custname);ResultSet results = pstmt.executeQuery( );Prepared Statement Example
  • 7.  Weak authentication Password-only Easily guessable usernames (admin, etc.) Unencrypted secrets are sniffable How to break in Guess/reset password Have app email you new password Sniff or crack password Backend authentication How are database passwords stored? Trust relationships between hosts (IP address can be spoofed, etc.) Countermeasures Strong passwords Remove default user names Protect sensitive filesA2 Broken Authentication andSession Management
  • 8.  Attacker uses trustedapplication/company to reflectmalicious code to end-user Attacker can “hide” the maliciouscode Unicode encoding 2 types of attacks Stored Reflected Countermeasures input validation Positive Negative: “< > ( ) # &” Don’t forget these: “&lt &gt &#40&#41 &#35 &#38” User/customer educationA3 Cross-Site Scripting (XSS)
  • 9. Types of XSSRefleced/Non persistant XSS
  • 10. Stored / Persistent Xss
  • 11.  Preventing XSS requires keeping untrusted data separatefrom active browser content. 1.The preferred option is to properly escape all untrusteddata based on the HTML context (body, attribute,JavaScript, CSS, or URL) that the data will be placed into 2.Positive or “whitelist” input validation is alsorecommended as it helps protect against XSS, but is not acomplete defense as many applications require specialcharacters in their input.How Do I Prevent XSS?
  • 12.  A direct object reference occurs when a developerexposes a reference to an internal implementationobject, such as a file, directory, or database key.Without an access control check or other protection,attackers can manipulate these references to accessunauthorized data.A4 Insecure Direct Object References
  • 13. Am I Vulnerable The best way to find out if an application is vulnerable toinsecure direct object references is to verify that all objectreferences have appropriate defenses. To achieve this,consider: Code review of the application can quickly verify whethereither approach is implemented safely. Testing is alsoeffective for identifying direct object references andwhether they are safe. Automated tools typically do notlook for such flaws because they cannot recognize whatrequires protection or what is safe or unsafe.
  • 14.  Preventing insecure direct object references requiresselecting an approach for protecting each user accessibleobject (e.g., object number, filename): Check access. Each use of a direct object reference from anuntrusted source must include an access control check toensure the user is authorized for the requested objectHow Do I Prevent This?
  • 15.  Good security requires having a secure configurationdefined and deployed for the application,frameworks, application server, web server, databaseserver, and platform. All these settings should bedefined, implemented, and maintained as many arenot shipped with secure defaults. This includeskeeping all software up to date.A5 Security Misconfiguration
  • 16. Am I Vulnerable to Attack 1.Is everything unnecessary disabled, removed, or notinstalled (e.g. ports, services, pages, accounts, privileges)? 2.Are default account passwords changed or disabled? 3.Is your error handling set up to prevent stack traces andother overly informative error messages from leaking? 4.Are the security settings in your developmentframeworks (e.g., Struts, Spring, ASP.NET) and librariesunderstood and configured properly? A concerted,repeatable process is required to develop and maintain aproper application security configuration.
  • 17.  The primary recommendations are to establish all of thefollowing: 1.A repeatable hardening process that makes it fast and easyto deploy another environment that is properly locked down.Development, QA, and production environments should all beconfigured identically. 2.A process for keeping abreast of and deploying all newsoftware updates and patches in a timely manner to eachdeployed environment.How Do I Prevent This?
  • 18.  Many web applications do notproperly protect sensitive data, suchas credit cards, tax ids, andauthentication credentials. Attackersmay steal or modify such weaklyprotected data to conduct identitytheft, credit card fraud, or othercrimes. Sensitive data deserves extraprotection such as encryption at restor in transit, as well as specialprecautions when exchanged withthe browser.A6 Sensitive Data Exposure
  • 19. Am I Vulnerable to Data Exposure The first thing you have to determine is which data issensitive enough to require extra protection. For example,passwords, credit card numbers, health records, andpersonal information should be protected. For all such data,ensure: 1.It is encrypted everywhere it is stored long term, includingbackups of this data. 2.It is encrypted in transit, ideally internally as well asexternally. All internet traffic should be encrypted.
  • 20.  The full perils of unsafe cryptography, SSL usage, and dataprotection are well beyond the scope of the Top 10. Thatsaid, for all sensitive data, do all of the following, at aminimum: 1.Considering the threats you plan to protect this datafrom (e.g., insider attack, external user), make sure youencrypt all sensitive data at rest and in transit in a mannerthat defends against these threats. 2.Don’t store sensitive data unnecessarily. Discard it assoon as possible. Data you don’t have can’t be stolen. 3.Ensure strong standard algorithms and strong keys areused, and proper key management is in place.How Do I Prevent This?
  • 21.  Virtually all web applications verify function level access rightsbefore making that functionality visible in the UI. However,applications need to perform the same access control checkson the server when each function is accessed. If requests arenot verified, attackers will be able to forge requests in order toaccess unauthorized functionality.A7 Missing function level accesscontrol
  • 22. Am I Vulnerable to Function level Access The best way to find out if an application has failed toproperly restrict function level access is to verify everyapplication function: 1.Does the UI show navigation to unauthorized functions? 2.Are proper authentication and authorization checked?
  • 23.  1.The enforcement mechanism(s) should deny all access bydefault, requiring explicit grants to specific roles for accessto every function. 2.If the function is involved in a workflow, check to makesure the conditions are in the proper state to allow access.How Do I Prevent Function levelAccess?
  • 24.  A CSRF attack forces a logged-on victim’s browser to send aforged HTTP request, including the victim’s session cookieand any other automatically included authenticationinformation, to a vulnerable web application. This allows theattacker to force the victim’s browser to generate requeststhe vulnerable application thinks are legitimate requestsfrom the victim.A8 Cross site request forgery
  • 25. Am I Vulnerable to CSRF See if each link and form includes an unpredictable token.Without such a token, attackers can forge maliciousrequests. Focus on the links and forms that invoke state-changingfunctions, since those are the most important CSRF targets.You should check multistep transactions, as they are notinherently immune.
  • 26.  Preventing CSRF usually requires the inclusion of anunpredictable token in each HTTP request. Such tokensshould, at a minimum, be unique per user session. 1.The preferred option is to include the unique token in ahidden field. This causes the value to be sent in the body ofthe HTTP request, avoiding its inclusion in the URL, which issubject to exposure. 2. OWASP’s ESAPI includes CSRF methods developers canuse to prevent such vulnerabilities. 3.Requiring the user to reauthenticate, or prove they are auser (e.g., via a CAPTCHA) can also protect against CSRFHow Do I Prevent CSRF?
  • 27.  Vulnerable components, such as libraries,frameworks, and other software modules almostalways run with full privilege. So, if exploited, theycan cause serious data loss or server takeover.Applications using these vulnerable components mayundermine their defenses and enable a range ofpossible attacks and impacts.A9 Using Components with KnownVulnerabilities
  • 28. Am I Vulnerable ? Determining if you are vulnerable requires searching thedatabases of your applications as well as keeping abreast ofproject mailing lists and announcements for anything thatmight be a vulnerability.
  • 29.  Use components that you didn’t write. But realistically, thebest way to deal with this risk is to ensure that you keepyour components up-to-date.How Do I Prevent This?
  • 30.  Web applications frequently redirect and forwardusers to other pages and websites, and use untrusteddata to determine the destination pages. Withoutproper validation, attackers can redirect victims tophishing or malware sites, or use forwards to accessunauthorized pages.A10 Unvalidated Redirects andForwards
  • 31. Am I Vulnerable to Redirection The best way to find out if an application has any unvalidatedredirects or forwards is to: 1.Review the code for all uses of redirect or forward (called atransfer in .NET). For each use, identify if the target URL isincluded in any parameter values. If so, verify theparameter(s) are validated to contain only an alloweddestination, or element of a destination. 2.Also, spider the site to see if it generates any redirects.
  • 32.  Safe use of redirects and forwards can be done in a numberof ways: 1.Simply avoid using redirects and forwards. 2.If used, don’t involve user parameters in calculating thedestination. This can usually be done. 3.If destination parameters can’t be avoided, ensure that thesupplied value is valid, and authorized for the user. It isrecommended that any such destination parameters be amapping value, rather than the actual URL or portion of theURL, and that server side code translate this mapping to thetarget URL.How Do I Prevent This?