Secure Coding for Java
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Secure Coding for Java

on

  • 1,086 views

 

Statistics

Views

Total Views
1,086
Views on SlideShare
1,020
Embed Views
66

Actions

Likes
0
Downloads
22
Comments
0

1 Embed 66

http://www.scoop.it 66

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

Secure Coding for Java Presentation Transcript

  • 1. The OWASP Foundation http://www.owasp.org Integrating security & privacy in a web application project OWASP Training Day - Ottawa Feb 27th 2012 Module 2 : Secure Codingmardi 8 janvier 13
  • 2. Agenda •Introduction •Using OWASP materials to secure code •Secure Coding principles •Code Reviewmardi 8 janvier 13
  • 3. http://www.google.fr/#q=sebastien gioria ➡Head of IT and Security Audit at Groupe Y ➡OWASP France Leader & Founder - Evangéliste ➡ OWASP Global Education Comittee Member (sebastien.gioria@owasp.org) ➡Leader and technical advisor on the Web App security group at CLUSIF Twitter :@SPoint CISA && ISO 27005 Risk Manager ★More than 15 years of manager and technical leads in differents firms ; bank, insurance, telecom, startups, ... ★Technical Expertise ★Securing SDLC ★Pentesting ★CodeReview ★Risk management, audits ★Security and Network trainingmardi 8 janvier 13
  • 4. ForeWords •This is a Training made from my own experience with a big number of company using OWASP materials. •Only the documents from OWASP wiki are OWASP officials (see https://www.owasp.org) 5 •Some extracts come from document I wrote as OWASP leader, this is why you could find it elsewhere.mardi 8 janvier 13
  • 5. Majors OWASP publications we can use All are on the wiki https://www.owasp.org All are under GPL or friendly licenses Majors publications you can use to secure your projects/SDLC Top10 reference this 3 guides Ø OWASP Top10 Ø Auditor/Testing Guide Ø Code Review Guide Building Code Review Testing Guide Guide 12Guide Ø Building Guide Ø Application Security Verification Standard (ASVS) Application Security Desk Reference (ASDR) Ø Secure Coding Practicesmardi 8 janvier 13
  • 6. 13mardi 8 janvier 13
  • 7. 13mardi 8 janvier 13
  • 8. Learning 13mardi 8 janvier 13
  • 9. Learning 13mardi 8 janvier 13
  • 10. Learning Contract 13mardi 8 janvier 13
  • 11. Learning Contract 13mardi 8 janvier 13
  • 12. Learning Contract Testing 13mardi 8 janvier 13
  • 13. Learning Contract Testing 13mardi 8 janvier 13
  • 14. Learning Contract Build Testing 13mardi 8 janvier 13
  • 15. Learning Contract Build Testing 13mardi 8 janvier 13
  • 16. Learning Contract Build Check Testing 13mardi 8 janvier 13
  • 17. Learning Contract Build Check Testing 13mardi 8 janvier 13
  • 18. Learning Contract Build Check Testing Progress 13mardi 8 janvier 13
  • 19. The OWASP Foundation http://www.owasp.org Introductionmardi 8 janvier 13
  • 20. Consequences of bad or no security • Identity theft • Hardware theft • Bad Media coverage • Customers loss • Legals/business penalty • Financials loss • IT downtime 8mardi 8 janvier 13
  • 21. © CLUSIF 2010 - Extrait de la présentation MIPS2010 17mardi 8 janvier 13
  • 22. © CLUSIF 2010 - Extrait de la présentation MIPS2010 18mardi 8 janvier 13
  • 23. What Verizon (PCI-DSS company) said ? © Verizon 2010 11mardi 8 janvier 13
  • 24. What Verizon (PCI-DSS company) said ? © Verizon 2010 11mardi 8 janvier 13
  • 25. What Verizon (PCI-DSS company) said ? © Verizon 2010 11mardi 8 janvier 13
  • 26. Verizon Study © Verizon 2010 12mardi 8 janvier 13
  • 27. Verizon Study © Verizon 2010 12mardi 8 janvier 13
  • 28. 22 © IBM X-Force 2009 - Extrait du rapport 2009mardi 8 janvier 13
  • 29. 23 © IBM X-Force 2009 - Extrait du rapport 2009mardi 8 janvier 13
  • 30. Vulnerability exposure 26mardi 8 janvier 13
  • 31. What you CIO Said : I got a Firewall ! 27mardi 8 janvier 13
  • 32. What your business user said : I have SSL based Web Site 28mardi 8 janvier 13
  • 33. What your business user said : only the hacker can attack my website • Tools are more and more simples. • Try a simple request on google website on SQL Injection and look at it. • An attack on a Web Server cost 100$/200$ per day on the underground market. 29mardi 8 janvier 13
  • 34. What your user said : a vulnerability on internal WebApp is not critical. •No, The web is anywhere, and CSRF, HTML5 CORS and more can make this completly destructive •Be aware and share this : • AJAX doing a lot of things without you 30 •Be aware and share this : • HTML5 will come with “nice” user functionnality , but with big impact on security (WebSocket, CORS, ...)mardi 8 janvier 13
  • 35. The OWASP Foundation http://www.owasp.org OWASP Application Security Verification Standardmardi 8 janvier 13
  • 36. What is ASVS ? •A standard that provides a basis for the verification of web applications application- independent. •A standard life-cycle model independent. •A standard that define requirements that can be applied across applications without 43 special interpretation.mardi 8 janvier 13
  • 37. What are ASVS responses ? •How much trust can be placed in a web application? •What features should be built into security controls? •How do I acquire a web application that is verified to have a certain range in coverage and level of rigor?mardi 8 janvier 13
  • 38. ASVS secure controls requirements Level Level Level Level Security Area Level 3 Level 4 1A 1B 2A 2B V1 – Security Architecture Verification Requirements 1 1 2 2 4 5 V2 – Authentication Verification Requirements 3 2 9 13 13 14 V3 – Session Management Verification Requirements 4 1 6 7 8 9 V4 – Access Control Verification Requirements 5 1 12 13 14 15 V5 – Input Validation Verification Requirements 3 1 5 7 8 9 V6 – Output Encoding/Escaping Verification Requirements 0 1 2 8 9 10 V7 – Cryptography Verification Requirements 0 0 2 8 9 10 V8 – Error Handling and Logging Verification Requirements 1 1 2 8 8 9 V9 – Data Protection Verification Requirements 1 1 2 3 4 4 V10 – Communication Security Verification Requirements 1 0 3 6 8 8 V11 – HTTP Security Verification Requirements 3 3 6 6 7 7 V12 – Security Configuration Verification Requirements 0 0 0 2 3 4 V13 – Malicious Code Search Verification Requirements 0 0 0 0 0 5 V14 – Internal Security Verification Requirements 0 0 0 0 1 3 Totals 22 12 51 83 96 112 23mardi 8 janvier 13
  • 39. But ASVS stand for Verification ? •ASVS just said functionals needs for controls. •We could use it as a Secure Coding Policy. ★Don’t be medium(ASVS Level1/2), just target excellence (ASVS Level 4) 24mardi 8 janvier 13
  • 40. Using ASVS as a secure coding policy ASVS : Verify that all password fields do not echo the user’s password when it is entered. ➡ All Password fields must be define as HTML passwd fields and must not echo user passwd. ➡ All login forms must include autocomplete=off tag ASVS : Verify that all input validation is performed on the server side. ➡ Performs all input validation on the server. Nothing in the browser 25mardi 8 janvier 13
  • 41. Positive attitude Negative  The tester shall search for XSS holes Positive  Verify that the application performs input validation and output encoding on all user input See: http://www.owasp.org/index.php/ XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet 56mardi 8 janvier 13
  • 42. The OWASP Foundation http://www.owasp.org OWASP Secure Coding Practicesmardi 8 janvier 13
  • 43. OWASP Secure Coding Practices •Small document (only 9 pages) •Could be use as an simple checklist for your policy. •Could be use together with ASVS or alone. •More technical and deeper approach than ASVS . •Wrote and use by Boeing :) 28mardi 8 janvier 13
  • 44. Secure Coding Practices Contents •Input Validation •Data Protection •Output Encoding •Communication Security •Authentication and •System Configuration Password Management •Database Security •Session Management •File Management •Access Control •Memory Management •Cryptographic Practices •General Coding Practices •Error Handling and Logging 29mardi 8 janvier 13
  • 45. Now the torture room 30mardi 8 janvier 13
  • 46. The OWASP Foundation http://www.owasp.org Let talk Secure Coding now (extracts from OWASP Secure Coding Practices/ OWASP CheatSheets OWASP ASVS, ...)mardi 8 janvier 13
  • 47. KISS : Keep it Short and Simple 32mardi 8 janvier 13
  • 48. Some secures principles to follow •Deep defense of application is mandatory •Following less privileges is the best solution •Segregate duty more that user think ➡Remember that application need to answer user needs and not security pleasure. 33mardi 8 janvier 13
  • 49. Deep defense of an Application (example) Secure Good crash mecanisms Preventing parameters Critical data protections configuration thefts User auth Web App Server SGBD Server Fi Browser re w Web  Apps Applica5on all Authorisation Authorisation and Logs/Audit of Input • Critical data transport and authentication transactions Critical data protections Validation protection authentication • Preventing session and ID theft 70mardi 8 janvier 13
  • 50. Fail securely Don’t give user technical details of the crash. Example : • 404 • 500 35mardi 8 janvier 13
  • 51. Fail Securely 36mardi 8 janvier 13
  • 52. Don’t try to make obscure things 72mardi 8 janvier 13
  • 53. Don’t try to make obscure things GEOPORTAIL 72mardi 8 janvier 13
  • 54. Don’t try to make obscure things 72mardi 8 janvier 13
  • 55. Don’t try to make obscure things GOOGLE MAPS 72mardi 8 janvier 13
  • 56. Controls • Controls need : • to be simple • to be used correctly • functional • present in every part of the application 74 Bad understanding of a control result of unused it by developers and application will be vulnerable.mardi 8 janvier 13
  • 57. Minimals controls to have You must have at least this components in your application : • Authentication • Authorization • Logging and audit • Secure Storage 75 • Secure transport • Secure input and output manipulation of datamardi 8 janvier 13
  • 58. The OWASP Foundation http://www.owasp.org Authenticationmardi 8 janvier 13
  • 59. Implement good passwd strategy Password length - Categorize applications : • Important : at least 6 characters • Critical : at least 8 characters and perhaps multi-factors authentication • High Critical : at least 14 characters and multi-factors authentication Password strength - Implement passwd complexity with previous categories • at least : 1 upper, 1 lower, 1 digit, 1 special • don’t allow dictionnary passwd • don’t allow continuous characters 41mardi 8 janvier 13
  • 60. Implement good passwd strategy •Let the user choose it •Force the user to change it regulary, and add no reuse capability. •Don’t allow too much “I forgot my passwd” •Don’t allow change of passwd without user approval; require actual passwd from the user and more for high critical. •Add sleep strategy ! •Add detection of misuse strategy ! •Don’t store passwd in clear !!!!! use hash ! 42mardi 8 janvier 13
  • 61. Multi-Factor authentication •Passwds are bad •Passwds are guessable •Multi-factor combine: • something you have (token, mobile, ...) • something you know (details about you, passwd, ...) • sometime, something you are (biometrics) • Use it for high critical applications. 43mardi 8 janvier 13
  • 62. Implement good global strategy •Ask second authentication for critical transactions (with multi-factor auth...) •Force authentication to be in TLS/SSL •Regenerate Session ID after authentication •Force Session ID to be “secure” •Limiting forgotten passwd,change of login/passwd 44mardi 8 janvier 13
  • 63. Good Passwd strategy 45mardi 8 janvier 13
  • 64. How to do ? •Authenticate all pages but not public pages (login, logout, help, ....) •Don’t allow more than one authentication mecanism •Authenticate on the SERVER •Simply send back “user or passwd mismatch” and nothing else after a failed authentication. •Logged all failed and all correct authentication •After each authentication give the user the last status of his authentication. 46mardi 8 janvier 13
  • 65. The OWASP Foundation http://www.owasp.org Exercice 1.1 Adding secure Authentication to ePoneymardi 8 janvier 13
  • 66. Exercice 1.1 - Ideas Setup Passwd strategy • Length • Complexity Fighting brute-force • in-session limitation • out of session limitation 48mardi 8 janvier 13
  • 67. The OWASP Foundation http://www.owasp.org Session Managementmardi 8 janvier 13
  • 68. Session •Use Default Java Framework Generator •Use other name than the default name of the Framework (rename JSESSIONID...) •Force transport of ID authentication on SSL/TLS. •Don’t allow Session ID in URL ! •If using cookie : • Secure Cookie • HTTPOnly Cookie • Limiting path + domain • Max Age and expiration 50mardi 8 janvier 13
  • 69. Session tricky Automatic expiration • categorize applications : • default : 1 hour • critical (some transaction) : 20mns • high critical (financials or account impact) : 5mns Renew Session ID after any privilege change Don’t allow simultaneous logon Add Session Attack Detection • add in-session tips : ip of session, other random number, ... 51mardi 8 janvier 13
  • 70. Browser defenses Bind JavaScript events to close session • on window.close() • on window.stop() • on window.blur() • on window.home() Use Javascripts timer to automatic close session in high critical applications Disable WebBrowser Cross-tab Session if possible...(bad user experiences....) • If you use cookie, this is not possible !!!! 52mardi 8 janvier 13
  • 71. Using Servlet 3.0 ? <session-­‐config>    <cookie-­‐config>        <http-­‐only>true</http-­‐only>        <secure>true</secure>    </cookie-­‐config> </session-­‐config> 53mardi 8 janvier 13
  • 72. Access Controls 107mardi 8 janvier 13
  • 73. Remembermardi 8 janvier 13
  • 74. Remember (1)Without access control, you can’t control the user in your applicationmardi 8 janvier 13
  • 75. Remember (1)Without access control, you can’t control the user in your application (2)Client inputs are EVILmardi 8 janvier 13
  • 76. Authentication && Authorization • Two Levels of authentication and authorization are needed –In the Application –In infrastructure App Server SGBD Role  A Connexion Table A + duty A Table  A Connexion Table B + Duty B Role  B Table  Bmardi 8 janvier 13
  • 77. Authorization Have in mind the rule : • Nothing by default Centralize all authorization code on the SERVER If client state are mandatory, use encryption and integrity checking on the server side to catch state tampering. Limit number of transaction per user at a interval time. 57mardi 8 janvier 13
  • 78. Authorization Enforce : • protection of URL to authorized account only • protection of function to authorized account only • protection of file access to authorized account only Application need to terminate session when authorization failed. Split administrative and user authorization Enforce dormant account : • loss privileges. • “disable account” • alerts 58mardi 8 janvier 13
  • 79. Exercice Make que application mono-session per user 59mardi 8 janvier 13
  • 80. Input Validation Ensure all data validation are done on THE SERVER. • If you do something on client side we can said you do “painting” Classify your data : • Trusted Data • Untrusted Data Conduct trusted path. Centralize your data validation Use parametrize query when exists (SQL) 60mardi 8 janvier 13
  • 81. Border validation Consider validating data along all the entry points of your Application border 61mardi 8 janvier 13
  • 82. Input Validation Use proper characters set for all input Encode all data to the same character set before doing anything <=>Canonicalize Reject all not validated datas Validate data : • expected type (convert as soon as possible to Java Types) • expected range • expected length • expected values • expected “white list” if possible 62mardi 8 janvier 13
  • 83. Input Validation Be careful of using “hazardous” characters (ex: <>’,”!(+)& %.) Add specific validation : • check for null bytes (%00) • check for new lines (%0D, %0A, n, r, ...) • check for dot-dot-slashes (../) 63mardi 8 janvier 13
  • 84. Be careful of encoding for specific validation... <script>alert(XSS);</script> URL %3c%73%63%72%69%70%74%3e%61%6c %65%72%74%28%58%53%53%29%3b%3c%2f%73%63%72%69%70%74%3e %0a HTML &#x3c;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3e;&#x61;&#x6c;&#x65;&#x7 2;&#x74;&#x28;&#x58;&#x53;&#x53;&#x29;&#x3b;&#x3c;&#x2f;&#x73;&#x63;&#x 72;&#x69;&#x70;&#x74;&#x3e;&#x0a; UTF-8 %u003c%uff53%uff43%uff52%uff49%uff50%uff54%u003e%uff41%uff4c %uff45%uff52%uff54%uff08%uff38%uff33%uff33%uff09%u003c %u2215%uff53%uff43%uff52%uff49%uff50%uff54%u003 One space ? <script>alert(XSS);</script>mardi 8 janvier 13
  • 85. Validating Datas 124mardi 8 janvier 13
  • 86. SQL => bad 125mardi 8 janvier 13
  • 87. SQL => bad 125mardi 8 janvier 13
  • 88. SQL => bad 125mardi 8 janvier 13
  • 89. SQL => a little bit better 126mardi 8 janvier 13
  • 90. XML => bad 127mardi 8 janvier 13
  • 91. XML => bad 127mardi 8 janvier 13
  • 92. XML => Validating 128mardi 8 janvier 13
  • 93. Better, a XML schema <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="item"> <xs:complexType> <xs:sequence> <xs:element name="description" type="xs:string"/> <xs:element name="price" type="xs:decimal"/> <xs:element name="quantity" type="xs:integer"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>mardi 8 janvier 13
  • 94. XML => XML Parsermardi 8 janvier 13
  • 95. LDAP => bad 131mardi 8 janvier 13
  • 96. LDAP => bad 131mardi 8 janvier 13
  • 97. LDAP => better 132mardi 8 janvier 13
  • 98. Using OWASP ESAPI 74mardi 8 janvier 13
  • 99. The OWASP Foundation http://www.owasp.org Output Encodingmardi 8 janvier 13
  • 100. Output encoding It’s a Defense in depth mechanism Encode ON THE SERVER Centralize the encoder functions Sanitize all data send to the client • HTMLEncode is a minimum but did not work on all cases 76mardi 8 janvier 13
  • 101. Essai 1 => bad 137mardi 8 janvier 13
  • 102. Essai 1 => bad 137mardi 8 janvier 13
  • 103. Essai 2 => it’s bad, but better than nothing 138mardi 8 janvier 13
  • 104. Essai 2 => it’s bad, but better than nothing 138mardi 8 janvier 13
  • 105. A good solution with a robust Sanitizer :) 139mardi 8 janvier 13
  • 106. The OWASP Foundation http://www.owasp.org Error Loggingmardi 8 janvier 13
  • 107. Error Handling Your Application will crash ! Catch all exceptions without exception (remember the null pointer exception !) • Clean all exception code of sensitive datas • Don’t give user any details about crash, just said “It’s a crash, try again later” Logs are sensitive, you MUST PROTECT THEM Log : • input validation failures • authentication request; especially failures • access control failures • systems exceptions • administrative functionality • crypto failures • invalid/expired session token access 81mardi 8 janvier 13
  • 108. Logging/Errors Split your logs with categories, examples : • Access • Error • Debug • Audit Use log4j for standard logging 82mardi 8 janvier 13
  • 109. Log4J Example import com.sec.dev; // Import log4j classes. import org.apache.log4j.Logger; import org.apache.log4j.BasicConfigurator; public class SecLogger { // Define a static logger variable so that it references the // Logger instance named "MyApp". static Logger logger = Logger.getLogger(MyApp.class); public static void main(String[] args) { // Set up a simple configuration that logs on the console. BasicConfigurator.configure(); logger.setLevel(Level.DEBUG); // optional if log4j.properties file not used // Possible levels: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL logger.info("Entering application."); Bar bar = new Bar(); bar.doIt(); logger.info("Exiting application."); } } 83mardi 8 janvier 13
  • 110. Exercice Add correct logging to ePoney Verify error handling implementation 84mardi 8 janvier 13
  • 111. Bad handling of Exception 144mardi 8 janvier 13
  • 112. Bad handling of Exception 144mardi 8 janvier 13
  • 113. Good handling of exception <error-page> 145 <exception-type>java.lang.Throwable</ exception-type> <location>/error.jsp</location> </error-page>mardi 8 janvier 13
  • 114. The OWASP Foundation http://www.owasp.org Data Protectionmardi 8 janvier 13
  • 115. Data protection Protect sensitive datas, don’t store them in clear. Store sensitive datas in trusted systems Don’t use GET request for sensitive data. Disable client site caching 88mardi 8 janvier 13
  • 116. Disable Client Side caching import  javax.servlet.*; import  javax.servlet.http.HttpServletResponse; import  java.io.IOException; import  java.util.Date; public  class  CacheControlFilter  implements  Filter  {        public  void  doFilter(ServletRequest  request,  ServletResponse  response,                                                  FilterChain  chain)  throws  IOException,  ServletException  {                HttpServletResponse  resp  =  (HttpServletResponse)  response;                resp.setHeader("Expires",  "Tue,  03  Jul  2001  06:00:00  GMT");                resp.setHeader("Last-­‐Modified",  new  Date().toString());                resp.setHeader("Cache-­‐Control",  "no-­‐store,  no-­‐cache,  must-­‐revalidate,  max-­‐age=0,  post-­‐check=0,  pre-­‐check=0");                resp.setHeader("Pragma",  "no-­‐cache");                chain.doFilter(request,  response);        } } web.xml <filter>        <filter-­‐name>SetCacheControl</filter-­‐name>        <filter-­‐class>com.sec.dev.cacheControlFilter</filter-­‐class> </filter>                                               <filter-­‐mapping>        <filter-­‐name>SetCacheControl</filter-­‐name> <url-­‐pattern>/*</url-­‐pattern> </filter-­‐mapping> 89mardi 8 janvier 13
  • 117. The OWASP Foundation http://www.owasp.org Acces to FileSystemmardi 8 janvier 13
  • 118. Absolute Path is bad 151mardi 8 janvier 13
  • 119. Absolute Path is bad 151mardi 8 janvier 13
  • 120. Absolute Path is bad 151mardi 8 janvier 13
  • 121. Canonicalisation is good 92mardi 8 janvier 13
  • 122. The OWASP Foundation http://www.owasp.org Secure Communicationsmardi 8 janvier 13
  • 123. Secure Communications Use TLS/SSL : • at least SSL v3.0/TLS 1.0 • minimum of 128bits encryption • use secure crypto : AES is good Don’t expose critical data in the URL Failed SSL/TLS communications should not fall back to insecure Validate certificate when used Protect all page, not just logon page ! 94mardi 8 janvier 13
  • 124. Force TLS/SSL Response Use HTTP Strict Transport Security (HSTS). • Available on some browsers • draft IETF : http://tools.ietf.org/html/ draft-ietf-websec-strict-transport- sec-04 HttpServletResponse  ...; response.setHeader("Strict-­‐Transport-­‐Security",  "max-­‐age=7776000;   includeSubdomains"); 95mardi 8 janvier 13
  • 125. The OWASP Foundation http://www.owasp.org Administrative interfacesmardi 8 janvier 13
  • 126. Administratives interfaces Use multi-factor authentication system Log transaction in other log files than user. Enforce logging, examples : • transaction on duty • transaction on user accounts Be careful of duty : • Help Desk is not an Administrator ! 97mardi 8 janvier 13
  • 127. The OWASP Foundation http://www.owasp.org Configurationmardi 8 janvier 13
  • 128. site:yale.edu inurl:passwordmardi 8 janvier 13
  • 129. Configuration Review all properties, configuration files Be careful of default passwds... Remove, and not just desactivate, unused functions/modules Use sandbox system when available : Be careful of Java Signed code who execute with more privileges ! 100mardi 8 janvier 13
  • 130. The OWASP Foundation http://www.owasp.org Code Reviewmardi 8 janvier 13
  • 131. Why Security Code review /Vulnerability searching? 102mardi 8 janvier 13
  • 132. Why Security Code review /Vulnerability searching? ✓To find them ? 102mardi 8 janvier 13
  • 133. Why Security Code review /Vulnerability searching? ✓To find them ? ✓To know where there are in the code ? 102mardi 8 janvier 13
  • 134. Why Security Code review /Vulnerability searching? ✓To find them ? ✓To know where there are in the code ? ✓To ensure they are not in our code ? 102mardi 8 janvier 13
  • 135. Why Security Code review /Vulnerability searching? ✓To find them ? ✓To know where there are in the code ? ✓To ensure they are not in our code ? ✓To conform to legal/business rule ? 102mardi 8 janvier 13
  • 136. What is security code review ? It’s a tools driven review of your code. Security Code Review imply : • Source code access • Business document access • Configuration access 103mardi 8 janvier 13
  • 137. SQL Injection ? 104mardi 8 janvier 13
  • 138. Injection code 105mardi 8 janvier 13
  • 139. False  Posi5ve False  Nega5ve Didn’t  find Code  Review 1 1 1 Test 3 3 5 A voir : http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 106mardi 8 janvier 13
  • 140. False  Posi5ve False  Nega5ve Didn’t  find Code  Review 1 1 1 Test 3 3 5 A voir : http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 106mardi 8 janvier 13
  • 141. XSS 107mardi 8 janvier 13
  • 142. False  Posi5ve False  Nega5ve Didn’t  find Code  Review 2 2 2 Test 5 3 1 A voir : http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 108mardi 8 janvier 13
  • 143. False  Posi5ve False  Nega5ve Didn’t  find Code  Review 2 2 2 Test 5 3 1 A voir : http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 108mardi 8 janvier 13
  • 144. Common AuthN & Session Mgt Reqts 109mardi 8 janvier 13
  • 145. Both Have Their Advantages Pen Testing Pros Code Review Pros • Requires less •Easier to specialized expertise •Find all the content • Easier setup •Find all instances of certain types of flaws • Easier to perform •Verify controls are • Exercises the entire correct app infrastructure •Verify controls are used in all the required • Proves places vulnerabilities 110mardi 8 janvier 13
  • 146. The OWASP Foundation http://www.owasp.org Toolsmardi 8 janvier 13
  • 147. LAPSE+ is a eclipse plugin to static analysis of code for detecting vulnerabilities of untrusted data injection in Java EE Applications. LAPSE+ is inspired by existing lightweight security auditing tools such as FlawFinder. Developed by Group of Stanford University. GPL Software. 112mardi 8 janvier 13
  • 148. LAPSE+ Vulnerabilities Detected URL Tampering Cookie Poisoning Parameter Tampering Header Manipulation Cross-site Scripting (XSS) HTTP Response Splitting Injections (SQL, Command, XPath, XML, LDAP) Path Traversal 113mardi 8 janvier 13
  • 149. 114mardi 8 janvier 13
  • 150. 115mardi 8 janvier 13
  • 151. CodePro on ePoney 116mardi 8 janvier 13
  • 152. The OWASP Foundation http://www.owasp.org Demomardi 8 janvier 13
  • 153. Now you can protect against him 118mardi 8 janvier 13
  • 154. License 119mardi 8 janvier 13