1. Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project

2. The Guide

ComplementsOWASP Top 10

3. 310p Book 4. Free and open source

• Gnu Free Doc License

Many contributors

5. Apps and web services 6. Most platforms

• Examples are J2EE, ASP.NET, and PHP

Comprehensive

Download from here: http://www.owasp.org/index.php/Category:OWASP_Guide_Project#tab=Download 7. Validating User Input 8. Input Validation

Never trust client input!

9. failure to properly validate input leads to almost all of the major vulnerabilities in applications

• Validate input

10. Encode output

GOLDEN RULE OF CLIENT INPUT All client input is hostile until proven otherwise or sanitized. 11. Distrust Even Your Own Requests!

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. You can not be trusted! 13. Layered approach

Integrity Checks

When data passes from trusted boundary to untrusted boundary and returned

Example:

14. Example: payment gateway Methods of integrity checking

Checksum

15. HMAC 16. Encryption 17. Digital Signature 18. Layered Approach

Validation

Performed on every tier, presentation layer checks for HTML issues, persistence layer checks for SQLi, etc.

19. Includes sanitization 20. Layered Approach

Business Rules

Enforce the context

21. Document and test thoroughly 22. Consider the edge cases 23. Examples:

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. 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. An attacker posing as a legitimate eBay buyer was able to purchase a computer, remove expensive components from it, then return it as "destroyed" to the seller, successfully bypassing business policy controls for eBay, Paypal and UPS. Examples from: http://projects.webappsec.org/Insufficient-Process-Validation 26. Data Validation Strategies

Accept known good (whitelisting)

• Parameters should be validated againstpositivespecs:

• Data type (string, integer, real, etc)

27. Minimum and maximum length

28. Whether null is allowed 29. Whether the parameter is required or not 30. Numeric range 31. Specific patterns (regular expressions)

Reject known bad (blacklisting)

32. Sanitize 33. No validation (when you hate your employer) 34. Authentication 35. Authentication

User identity / credential

Ties system identity to individual

Align with application risk

Choose authentication controls based on risk

Keep out the bad guys

Deny access to attackers of the authentication system

36. Best practices

User management process!

The stronger the requirement for non-repudiation, the more expensive the process.

Align credential with asset values

• Passwords (low-value)

37. SMS

38. Tokens

Re-authenticate on privilege boundaries and high-value transactions

39. Passwords are trivially broken!

Any password less than 16 characters in length can be brute forced in less than two weeks

40. Usernames & Passwords

Let users choose user names

Harder to enumerate

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 Password policies (strength, change control, storage) 42. Secure transport (SSL) + check in code:[if(server_port == 443)] 43. Carefully implement forgotten password functionality 44. Remove or disable default usernames 45. HTTP headers and meta tags to prevent caching - for all form fields - for just one field 46. Strong Authentication

Two-Factor Authentication: something you know, something you hold (or something you are)

47. Relative strengths / uses

• One-time passwords

48. Soft certificates

49. Connected hard certificates 50. Challenge Response Tokens 51. SMS Challenge Response 52. Transaction Signing 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. Authorization 55. Authorization

Assuresprivileges to access resources and perform actions

56. Generally role based 57. Best Practices

Principle of Least Privilege

58. Centralized authorization routines 59. Authorization matrix (auth check every page) 60. Control access to protected resources 61. Protect access to static resources 62. Be cautious of custom authorization controls (use framework instead) 63. Never implement client-side authorization tokens (cookies, custom headers, hidden form fields) 64. Separate applications for administrator and user access 65. Session Management 66. Session Management

HTTP is stateless

67. Linkuser identity across requests 68. J2EE, PHP, ASP.NET Built-in (Lasso too!) 69. Cookies ! 70. Best practices

Use frameworks

71. Store information in server-side sessions 72. Time out sessions 73. Provide Log-off facilities 74. Regenerate tokens

• Upon log-on / log-off (fixation attacks)

75. After defined time frame

Detect, (temp) lock out, log brute force attacks

76. HTTPS! 77. Using Interpreters 78. Interpreter Injection Prevention

Web application eco-system: tap into external systems

79. Examples:

• XSS (user agent)

80. SQLi

81. LDAPi 82. XMLi 83. OSi 84. Best Practices

General: API preferred instead of CMD

85. XSS:

• Input validation

86. Output encoding

87. Anti-XSS libraries

SQLi:

• Input validation

88. Strongly Type parameters

89. Prepared statements 90. Least Privilege principle 91. Crypto 92. Crypto

Complex

93. Difficult to get right! 94. Functions:

• Authentication

95. Non-repudiation

96. Confidentiality 97. Integrity

Algorithms

• Symmetric

98. Asymetric

99. Hashes 100. Best Practices

Dont confuse with encoding!

101. Use known algorithms, dont write your own 102. Carefully consider algorithm and key size

Symmetric: minimum 128 bits

103. Asymmetric: minimum 1536 bits 104. Hashes: minimum 128 bits Design your application to cope with new hashes and algorithms 105. Protect keys 106. Catching Errors 107. Error Handling, Auditing and Logging

Track Events within the application

108. Handling Errors (track app errors) 109. Auditable (track user state changes) 110. Traceable (track across all application tiers) 111. High integrity (non-modifiable logs) 112. Best Pracices

Fail safe do not fail open

113. Dual purpose logs (audit and monitoring) 114. Reports and search logs using a read-only copy or complete replica 115. Error Handling

Structured exception handling

116. Fail Safe 117. General error message for end-user 118. No Debug mode in production 119. Nostack traces or leaking privacy related information 120. Keep logs safe and confidential even when backed up 121. Foresee generic levels and provideSecurity Incident & Event Management (SIEM) hooks 122. Audit Logs

Check legal requirements

123. Only audit truly important events 124. Log centrally 125. Review copies of the logs 126. Sent logs to trusted systems 127. Use write-once media or similar 128. File System 129. File System

Protect against creation, modification or deletion

130. Devastating attacks:

• Defacement

131. Remote file inclusion

132. Best Practices

chroot jails on Unix platforms

133. minimal file system permissions 134. RO file systems if practical 135. Do not take user supplied file names when saving or working on local files 136. Input validation 137. Ensure the user cannot supply all parts of the path surround it with your path code 138. Use robots.txt control search engines 139. Remove all unused files 140. Protect temporary files 141. Disable browsing 142. Configuration 143. Configuration

Security

• Not only developers responsability

144. Not only operators responsability

Shared responsability

145. Security settings must be pre-defined, documented and subject to Change Management! 146. Best Practices

Turn off all unnecessary features by default

147. No default accounts 148. No backdoors 149. No clear passwords in configurations 150. SSL / SSH 151. Keep OS / Software up to date 152. Web 2.0 153. Web 2.0

Ajax, Flex, SilverLight ...

154. exactly the samesecurity issues as all other web applications 155. Complex, bidirectional, and asynchronous nature: increased attack surface area 156. Must also have adequate:

• Secure Communications

157. Authentication and Session Management

158. Access Control 159. Input Validation 160. Error Handling and Logging 161. Questions?