Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project
The Guide <ul><li>Complements  OWASP Top 10
310p Book
Free and open source </li></ul><ul><ul><li>Gnu Free Doc License </li></ul></ul><ul><li>Many contributors
Apps and web services
Most platforms </li></ul><ul><ul><li>Examples are J2EE, ASP.NET, and PHP </li></ul></ul><ul><li>Comprehensive </li></ul>Do...
Validating User Input
Input Validation <ul><li>Never trust client input!
failure to properly validate input leads to almost all of the major vulnerabilities in applications </li></ul><ul><ul><li>...
Encode output </li></ul></ul>GOLDEN RULE OF CLIENT INPUT “ All client input is hostile until proven otherwise or sanitized.”
Distrust Even Your Own Requests! <ul><li>CSRF (cross-site request forgery) and Clickjacking are two examples of where mali...
You can not be trusted! </li></ul>
Layered approach <ul><li>Integrity Checks </li><ul><li>When data passes from trusted boundary to untrusted boundary and re...
Example: payment gateway </li></ul><li>Methods of integrity checking </li><ul><li>Checksum
HMAC
Encryption
Digital Signature </li></ul></ul></ul>
Layered Approach <ul><li>Validation </li><ul><li>Performed on every tier, presentation layer checks for HTML issues, persi...
Includes sanitization </li></ul></ul>
Layered Approach <ul><li>Business Rules </li><ul><li>Enforce the context
Document and test thoroughly
Consider the edge cases
Examples: </li><ul><li>E-trade and Schwab, in their signup process, failed to validate a limit of one bank account per any...
QVC lost more than USD $412,000.00 when a woman discovered she could purchase items via the QVC website, immediate cancel ...
An attacker posing as a legitimate eBay buyer was able to purchase a computer, remove expensive components from it, then r...
Data Validation Strategies <ul><li>Accept known good (whitelisting) </li></ul><ul><ul><li>Parameters should be validated a...
Minimum and maximum length
Whether null is allowed
Whether the parameter is required or not
Numeric range
Specific patterns (regular expressions) </li></ul></ul></ul><ul><li>Reject known bad (blacklisting)
Sanitize
No validation (when you hate your employer) </li></ul>
Authentication
Authentication <ul><li>User identity / credential </li><ul><li>Ties system identity to individual </li></ul><li>Align with...
Best practices <ul><li>User management process! </li><ul><li>The stronger the requirement for non-repudiation, the more ex...
SMS
Tokens </li></ul></ul><ul><li>Re-authenticate on privilege boundaries and high-value transactions
Passwords are trivially broken! </li><ul><li>Any password less than 16 characters in length can be brute forced in less th...
Usernames & Passwords <ul><li>Let users choose user names </li><ul><li>Harder to enumerate
Avoid the use of Firstname.Lastname, e-mail address, credit card numbers or customer number, or any semi-public data, such...
Upcoming SlideShare
Loading in...5
×

OWASP Secure Coding

3,808

Published on

Presentation at LDC09: OWASP Secure Coding

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,808
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
211
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OWASP Secure Coding

  1. 1. Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project
  2. 2. The Guide <ul><li>Complements OWASP Top 10
  3. 3. 310p Book
  4. 4. Free and open source </li></ul><ul><ul><li>Gnu Free Doc License </li></ul></ul><ul><li>Many contributors
  5. 5. Apps and web services
  6. 6. Most platforms </li></ul><ul><ul><li>Examples are J2EE, ASP.NET, and PHP </li></ul></ul><ul><li>Comprehensive </li></ul>Download from here: http://www.owasp.org/index.php/Category:OWASP_Guide_Project#tab=Download
  7. 7. Validating User Input
  8. 8. Input Validation <ul><li>Never trust client input!
  9. 9. failure to properly validate input leads to almost all of the major vulnerabilities in applications </li></ul><ul><ul><li>Validate input
  10. 10. Encode output </li></ul></ul>GOLDEN RULE OF CLIENT INPUT “ All client input is hostile until proven otherwise or sanitized.”
  11. 11. Distrust Even Your Own Requests! <ul><li>CSRF (cross-site request forgery) and Clickjacking are two examples of where malicious requests appear to be initiated by you, from your browser, using your credentials
  12. 12. You can not be trusted! </li></ul>
  13. 13. Layered approach <ul><li>Integrity Checks </li><ul><li>When data passes from trusted boundary to untrusted boundary and returned </li><ul><li>Example: <input type=”hidden”>
  14. 14. Example: payment gateway </li></ul><li>Methods of integrity checking </li><ul><li>Checksum
  15. 15. HMAC
  16. 16. Encryption
  17. 17. Digital Signature </li></ul></ul></ul>
  18. 18. Layered Approach <ul><li>Validation </li><ul><li>Performed on every tier, presentation layer checks for HTML issues, persistence layer checks for SQLi, etc.
  19. 19. Includes sanitization </li></ul></ul>
  20. 20. Layered Approach <ul><li>Business Rules </li><ul><li>Enforce the context
  21. 21. Document and test thoroughly
  22. 22. Consider the edge cases
  23. 23. Examples: </li><ul><li>E-trade and Schwab, in their signup process, failed to validate a limit of one bank account per any given user, allowing an attacker to assign the same bank account to tens of thousands of users, resulting in a loss of USD $50,000.00.
  24. 24. QVC lost more than USD $412,000.00 when a woman discovered she could purchase items via the QVC website, immediate cancel her order, but still receive the items.
  25. 25. An attacker posing as a legitimate eBay buyer was able to purchase a computer, remove expensive components from it, then return it as &quot;destroyed&quot; to the seller, successfully bypassing business policy controls for eBay, Paypal and UPS. </li></ul></ul></ul>Examples from: http://projects.webappsec.org/Insufficient-Process-Validation
  26. 26. Data Validation Strategies <ul><li>Accept known good (whitelisting) </li></ul><ul><ul><li>Parameters should be validated against positive specs: </li><ul><li>Data type (string, integer, real, etc…)
  27. 27. Minimum and maximum length
  28. 28. Whether null is allowed
  29. 29. Whether the parameter is required or not
  30. 30. Numeric range
  31. 31. Specific patterns (regular expressions) </li></ul></ul></ul><ul><li>Reject known bad (blacklisting)
  32. 32. Sanitize
  33. 33. No validation (when you hate your employer) </li></ul>
  34. 34. Authentication
  35. 35. Authentication <ul><li>User identity / credential </li><ul><li>Ties system identity to individual </li></ul><li>Align with application risk </li><ul><li>Choose authentication controls based on risk </li></ul><li>Keep out the bad guys </li><ul><li>Deny access to attackers of the authentication system </li></ul></ul>
  36. 36. Best practices <ul><li>User management process! </li><ul><li>The stronger the requirement for non-repudiation, the more expensive the process. </li></ul><li>Align credential with asset values </li></ul><ul><ul><li>Passwords (low-value)
  37. 37. SMS
  38. 38. Tokens </li></ul></ul><ul><li>Re-authenticate on privilege boundaries and high-value transactions
  39. 39. Passwords are trivially broken! </li><ul><li>Any password less than 16 characters in length can be brute forced in less than two weeks </li></ul></ul>
  40. 40. Usernames & Passwords <ul><li>Let users choose user names </li><ul><li>Harder to enumerate
  41. 41. Avoid the use of Firstname.Lastname, e-mail address, credit card numbers or customer number, or any semi-public data, such as social security number </li></ul><li>Password policies (strength, change control, storage)
  42. 42. Secure transport (SSL) + check in code: [if(server_port == 443)]
  43. 43. Carefully implement forgotten password functionality
  44. 44. Remove or disable default usernames
  45. 45. HTTP headers and meta tags to prevent caching </li></ul><form … AUTOCOMPLETE=&quot;off&quot;> - for all form fields <input … AUTOCOMPLETE=&quot;off&quot;> - for just one field
  46. 46. Strong Authentication <ul><li>Two-Factor Authentication: something you know, something you hold (or something you are)
  47. 47. Relative strengths / uses </li></ul><ul><ul><li>One-time passwords
  48. 48. Soft certificates
  49. 49. Connected hard certificates
  50. 50. Challenge Response Tokens
  51. 51. SMS Challenge Response
  52. 52. Transaction Signing </li></ul></ul>
  53. 53. Positive Authentication (fail closed) bAuthenticated := false securityRole := null try { userrecord := fetch_record(username) if userrecord[username].password != sPassword then throw noAuthentication end if if userrecord[username].locked == true then throw noAuthentication end if if userrecord[username].securityRole == null or banned then throw noAuthentication end if … other checks … bAuthenticated := true securityRole := userrecord[username].securityRole } catch { bAuthenticated := false securityRole := null // perform error handling, and stop } return bAuthenticated
  54. 54. Authorization
  55. 55. Authorization <ul><li>Assures privileges to access resources and perform actions
  56. 56. Generally role based </li></ul>
  57. 57. Best Practices <ul><li>Principle of Least Privilege
  58. 58. Centralized authorization routines
  59. 59. Authorization matrix (auth check every page)
  60. 60. Control access to protected resources
  61. 61. Protect access to static resources
  62. 62. Be cautious of custom authorization controls (use framework instead)
  63. 63. Never implement client-side authorization tokens (cookies, custom headers, hidden form fields)
  64. 64. Separate applications for administrator and user access </li></ul>
  65. 65. Session Management
  66. 66. Session Management <ul><li>HTTP is stateless
  67. 67. Link user identity across requests
  68. 68. J2EE, PHP, ASP.NET Built-in (Lasso too!)
  69. 69. Cookies ! </li></ul>
  70. 70. Best practices <ul><li>Use frameworks
  71. 71. Store information in server-side sessions
  72. 72. Time out sessions
  73. 73. Provide Log-off facilities
  74. 74. Regenerate tokens </li></ul><ul><ul><li>Upon log-on / log-off (fixation attacks)
  75. 75. After defined time frame </li></ul></ul><ul><li>Detect, (temp) lock out, log brute force attacks
  76. 76. HTTPS! </li></ul>
  77. 77. Using Interpreters
  78. 78. Interpreter Injection Prevention <ul><li>Web application eco-system: tap into external systems
  79. 79. Examples: </li></ul><ul><ul><li>XSS (user agent)
  80. 80. SQLi
  81. 81. LDAPi
  82. 82. XMLi
  83. 83. OSi </li></ul></ul>
  84. 84. Best Practices <ul><li>General: API preferred instead of CMD
  85. 85. XSS: </li></ul><ul><ul><li>Input validation
  86. 86. Output encoding
  87. 87. Anti-XSS libraries </li></ul></ul><ul><li>SQLi: </li></ul><ul><ul><li>Input validation
  88. 88. Strongly Type parameters
  89. 89. Prepared statements
  90. 90. Least Privilege principle </li></ul></ul>
  91. 91. Crypto
  92. 92. Crypto <ul><li>Complex
  93. 93. Difficult to get right!
  94. 94. Functions: </li></ul><ul><ul><li>Authentication
  95. 95. Non-repudiation
  96. 96. Confidentiality
  97. 97. Integrity </li></ul></ul><ul><li>Algorithms </li></ul><ul><ul><li>Symmetric
  98. 98. Asymetric
  99. 99. Hashes </li></ul></ul>
  100. 100. Best Practices <ul><li>Don’t confuse with encoding!
  101. 101. Use known algorithms, don’t write your own
  102. 102. Carefully consider algorithm and key size </li><ul><li>Symmetric: minimum 128 bits
  103. 103. Asymmetric: minimum 1536 bits
  104. 104. Hashes: minimum 128 bits </li></ul><li>Design your application to cope with new hashes and algorithms
  105. 105. Protect keys </li></ul>
  106. 106. Catching Errors
  107. 107. Error Handling, Auditing and Logging <ul><li>Track Events within the application
  108. 108. Handling Errors (track app errors)
  109. 109. Auditable (track user state changes)
  110. 110. Traceable (track across all application tiers)
  111. 111. High integrity (non-modifiable logs) </li></ul>
  112. 112. Best Pracices <ul><li>Fail safe – do not fail open
  113. 113. Dual purpose logs (audit and monitoring)
  114. 114. Reports and search logs using a read-only copy or complete replica </li></ul>
  115. 115. Error Handling <ul><li>Structured exception handling
  116. 116. Fail Safe
  117. 117. General error message for end-user
  118. 118. No Debug mode in production
  119. 119. No stack traces or leaking privacy related information
  120. 120. Keep logs safe and confidential even when backed up
  121. 121. Foresee generic levels and provide Security Incident & Event Management (SIEM) hooks </li></ul>
  122. 122. Audit Logs <ul><li>Check legal requirements
  123. 123. Only audit truly important events
  124. 124. Log centrally
  125. 125. Review copies of the logs
  126. 126. Sent logs to trusted systems
  127. 127. Use write-once media or similar </li></ul>
  128. 128. File System
  129. 129. File System <ul><li>Protect against creation, modification or deletion
  130. 130. Devastating attacks: </li></ul><ul><ul><li>Defacement
  131. 131. Remote file inclusion </li></ul></ul>
  132. 132. Best Practices <ul><li>“ chroot” jails on Unix platforms
  133. 133. minimal file system permissions
  134. 134. RO file systems if practical
  135. 135. Do not take user supplied file names when saving or working on local files
  136. 136. Input validation
  137. 137. Ensure the user cannot supply all parts of the path – surround it with your path code
  138. 138. Use robots.txt – control search engines
  139. 139. Remove all unused files
  140. 140. Protect temporary files
  141. 141. Disable browsing </li></ul>
  142. 142. Configuration
  143. 143. Configuration <ul><li>Security </li></ul><ul><ul><li>Not only developer’s responsability
  144. 144. Not only operator’s responsability </li></ul></ul><ul><li>Shared responsability
  145. 145. Security settings must be pre-defined, documented and subject to Change Management! </li></ul>
  146. 146. Best Practices <ul><li>Turn off all unnecessary features by default
  147. 147. No default accounts
  148. 148. No backdoors
  149. 149. No clear passwords in configurations
  150. 150. SSL / SSH
  151. 151. Keep OS / Software up to date </li></ul>
  152. 152. Web 2.0
  153. 153. Web 2.0 <ul><li>Ajax, Flex, SilverLight ...
  154. 154. exactly the same security issues as all other web applications
  155. 155. Complex, bidirectional, and asynchronous nature: increased attack surface area
  156. 156. Must also have adequate: </li></ul><ul><ul><li>Secure Communications
  157. 157. Authentication and Session Management
  158. 158. Access Control
  159. 159. Input Validation
  160. 160. Error Handling and Logging </li></ul></ul>
  161. 161. Questions?
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×