Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project. It recommends validating all user input, distrusting even your own requests, and taking a layered approach to validation, enforcement of business rules, and authentication. Some specific best practices include implementing positive authentication, principle of least privilege, centralized authorization routines, separating admin and user access, and ensuring error handling fails safely.

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

3. 310p Book

5. Apps and web services

7. Validating User Input

10. Encode output GOLDEN RULE OF CLIENT INPUT “ All client input is hostile until proven otherwise or sanitized.”

12. You can not be trusted!

15. HMAC

16. Encryption

17. Digital Signature

19. Includes sanitization

21. Document and test thoroughly

22. Consider the edge cases

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

27. Minimum and maximum length

28. Whether null is allowed

29. Whether the parameter is required or not

30. Numeric range

32. Sanitize

33. No validation (when you hate your employer)

34. Authentication

37. SMS

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 <form … AUTOCOMPLETE=&quot;off&quot;> - for all form fields <input … AUTOCOMPLETE=&quot;off&quot;> - for just one field

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

56. Generally role based

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

67. Link user identity across requests

68. J2EE, PHP, ASP.NET Built-in (Lasso too!)

69. Cookies !

71. Store information in server-side sessions

72. Time out sessions

73. Provide Log-off facilities

76. HTTPS!

77. Using Interpreters

80. SQLi

81. LDAPi

82. XMLi

83. OSi

86. Output encoding

88. Strongly Type parameters

89. Prepared statements

90. Least Privilege principle

91. Crypto

93. Difficult to get right!

95. Non-repudiation

96. Confidentiality

98. Asymetric

99. Hashes

101. Use known algorithms, don’t write your own

103. Asymmetric: minimum 1536 bits

105. Protect keys

106. Catching Errors

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)

113. Dual purpose logs (audit and monitoring)

114. Reports and search logs using a read-only copy or complete replica

116. Fail Safe

117. General error message for end-user

118. No Debug mode in production

119. No stack traces or leaking privacy related information

120. Keep logs safe and confidential even when backed up

121. Foresee generic levels and provide Security Incident & Event Management (SIEM) hooks

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

131. Remote file inclusion

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

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

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

154. exactly the same security issues as all other web applications

155. Complex, bidirectional, and asynchronous nature: increased attack surface area

157. Authentication and Session Management

158. Access Control

159. Input Validation

160. Error Handling and Logging

161. Questions?