OWASP-Secure-Coding-Practices.md

  

OWASP Secure Coding Practices

Check list format that can be integrated into the software development lifecycle.

Introduction

• Generally it is much cheaper to build secure software than fixing security issues.
• Security breaches can have much cost themselves (coding secure, is much better)
• From SANS 2009 Study:
  • More than 60% of attacks on internet, are against web application (application layer)
• Developers team should assess their level of secure coding knowledge

Software Security and Risk Principles Overview

• The goal of software security is to maintain the confidentiality, integrity, and availability of information resources
• Primary focus of this document is web application
• Risk is a combination of factors that threaten the success of the business
• This can be described conceptually as follows: a threat agent interacts with a system, which may have a vulnerability that can be exploited in order to cause an impact.
• Client-side controls are good, but not enough!
  • Attackers can bypass client-side controls easily by proxies like Burp
  • The security controls must be implemented in server-side
• Software vulnerabilities can have a scope beyond the software itself:
  • Software and its information
  • Operating System
  • Backend Database
  • Other APPs in a shared environment
  • User's System
  • Other Software that the user interacts with

Secure Coding Practices Checklist

Input Validation

1. Perform Data Validation on Server
2. Classify data sources into trusted or untrusted:
   • validate the untrusted data sources
3. There should be a centralized input validation routine for the app
4. Specify proper character sets, such as UTF-8 for all sources
5. Encode data to a common character set before validating
6. All validation failure should result in input rejection
7. Determine if the system supports UTF-8 and if so, validate after UTF-8 decoding is completed
8. Validate client data before processing
   • all parameters
   • headers
   • cookies
   • values
9. Verify that header values in both request and responses contain only ASCII characters
10. Validate data before redirection
11. Validate for expected data types
12. Validate data range
13. Validate data length
14. Validate all input against a white list of allowed characters, whenever possible
15. If any dangerous (Hazardous) character must be allowed, extra controls like output encoding should be implemented. Examples of hazardous include:
    • <, >
    • ", '
    • %
    • (, )
    • &
    • \ , \', \"
16. Extra checks:
    • Null bytes: %00
    • New Line Characters: %0d, %0a, \r, \n
    • Check for "dot-dot-slash" (../ or ..\ )
    • If UTF-8 extended character set encoding is supported:
      • address alternate representation like: %c0%ae%c0%ae/

Output Encoding

17. all encoding on a trusted system e.g., the Server
18. Utilize a standard method for each type of output encoding
19. Encode output based on the context it will be in.
20. Encode all characters unless they are known to be safe for the intended interpreter
21. Sanitize output of un-trusted data to queries based on context e.g. SQL, XML, LDAP
22. Sanitize output of un-trusted data to OS Commands

Authentication & Password Management

23. Require Authentication for all routes & resources, except for those which intented to be public
24. All authentication controls must be enforced on a trusted system e.g. Server
25. Use and implement standard, tested auth services
26. Use a centralized implementation for all auth controls, including libraries that call external auth services
27. Separate authentication logic and the resource being requested and use redirection to and from centralized auth control
28. All authentication controls should fail securely
29. All administrative and account management functions must be at least as secure as the primary auth mechanism
30. If application stores credential
    • Ensure using only cryptographically strong one-way salted hashes of password
    • Password table and keys are write-able only by application
    • Do not use MD5
31. Password hashing must be implemented on a trusted system, e.g. Server
32. Validate authentication data only on completion of all data input
    • Especially when the authentication mechanism is sequential (steps by steps, and order is important)
33. Authentication failure process should not show which part was incorrect.
    • Instead of 'invalid username' or 'invalid password', just show Invalid username and/or password
    • Errors must be identically in both display and source code
34. Use authentication when using external systems, if they involve sensitive information
35. Authentication credentials for accessing services should be stored in a protected location on a trusted system (e.g. Server)
    • Source code is not a secure location
36. Use only HTTP POST Request to transit authentication credentials
37. Only send non-temporary passwords over an encrypted connection or as encrypted data, such as in an encrypted email. Temporary passwords associated with email resets may be an exception
38. Enforce password complexity requirements based on policy or regulations.
39. Enforce password length requirements based on policy or regulations.
40. Password entry should be hidden on the user's system
41. Enforce account disabling after an established number of invalid login attempts
    • account must be locked temporary
    • but not so long to allow Denial of Service attack
42. Password reset and changing operations require the same level of controls as account creation and authentication.
43. Password reset questions should support sufficiently random answers. (e.g., "favorite book" is a bad question because “The Bible” is a very common answer)
44. If using email based resets, only send email to a pre-registered address with a temporary link/password
45. Temporary links and password should have short expiration time
46. Enforce the changing of temporary passwords on the next use
47. Notify users when a password reset occurs
48. Prevent password re-use
49. Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use
50. Enforce password changes based on requirements in a policy or regulations.
    • Critical systems may require more frequent changes
51. Disable remember me functionality for password fields
52. The last successful or unsuccessful of a user account should be reported to the user at the next successful login
53. implement monitoring to identify attacks against multiple user accounts, using same password.
54. Change all vendor-supplied default passwords and user IDs or disable associated accounts
55. Re-authenticate users prior to performing critical operations
    • e.g. get password before changing e-mail, password &...
56. Use Multi-Factor Authentication for highly sensitive accounts
57. If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code

Session Management

58. Use the server or framework's session management controls.
59. Session identifier creation must always be done on a trusted system e.g. Server
60. Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers
61. Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site
62. Logout functionality should fully terminate the associated session or connection
63. Logout functionality should be available from all pages protected by authorization
64. Establish a session inactivity timeout that is a short as possible
    • Balance Risk & Business Functional requirement\
    • In most cases, it should be no more than several hours
65. Disallow persistent logins and enforce periodic session terminations, even when the session is active
    • user should receive notification to mitigate negative impact
66. If a session was established before login:
    • close the session first
    • then establish a new session
67. Generate a new session ID on any re-authentication
68. Do not allow concurrent logins with the same user ID
69. Do not expose session IDs in URLs, error messages or logs
    • session IDs should only be located in HTTP Cookie header.
    • Do not pass it as a GET parameter
70. Protect server side session data from unauthorized access: appropriate access control on server
71. Generate a new session ID and deactivate the old ones periodically: avoid session hijacking
72. generate new session ID if the connection changes from HTTP to HTTPS
73. Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks
74. Supplement standard session management for highly sensitive or critical operations by utilizing per-request, as opposed to per-session, strong random tokens or parameters
75. Set the secure attribute for cookies transmitted ofr HTTPS
76. Set cookies with the HttpOnly attribute, unless you specifically require client-side access to cookie

Access Control

77. Use only trusted system objects, e.g. server side session objects, for making access authorization decisions
78. Use a single site-wide component to check access authorization. This includes libraries that call external authorization services
79. Access controls should fail securely
80. Deny all access if the application cannot access its security configuration information
81. Enforce authorization controls on every request, including those made by server side scripts, "includes" and requests from rich client-side technologies like AJAX and Flash
82. Separate privileged logic from other application code
83. Restrict access to files or other resources, including those outside the application's direct control, to only authorized users
84. Restrict access to protected URLs to only authorized users
85. Restrict access to protected functions to only authorized users
86. Restrict direct object references to only authorized users
87. Restrict access to services to only authorized users
88. Restrict access to application data to only authorized users
89. Restrict access to user and data attributes and policy information used by access controls
90. Restrict access security-relevant configuration information to only authorized users
91. Server side implementation and presentation layer representations of access control rules must match
92. If state data must be stored on the client, use encryption and integrity checking on it
93. Enforce application login flows to comply with business rules
94. Limit the number of transactions a single user or device can perform in a given period of time
95. Use the "referer" header as a supplemental check only, it should never be the sole authorization check, as it can be spoofed
96. If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate
97. Implement account auditing and enforce disable of unused accounts
    • e.g. After no more than 30 days from the expiration of an account’s password
98. the application must support disabling of accounts and terminating sessions when authorization ceases
99. Service accounts or accounts supporting connections to or from external systems should have the least privilege possible
100. Create an Access Control Policy to document an application's business rules, data types and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources

Cryptographic Practices

101. All cryptographic functions must be implemented on a trusted e.g. server
102. Protect master secrets from unauthorized access
103. Cryptographic modules should fail securely
104. All random numbers, random file names, random GUIDs, and random string should be generated using the cryptographic module's approved random number generator when these random values are intended to be un-guessable
105. Cryptographic modules used by the application should be compliant to FIPS 140-2 or an equivalent standard
106. Establish and utilize a policy and process for how cryptographic keys will be managed

Error Handling & Logging

107. Do not disclose information in error messages, including system details, session identifiers or account information
108. Use error handlers that do not display debugging or stack trace information
109. Implement generic error messages and use custom error pages
110. The application should handle application errors and not rely on server configuration
111. Properly free allocated memory, when error conditions error
112. Error handling logic associated with security controls should deny access by default
113. All logging controls should be implemented on a trusted system e.g. server
114. Logging controls should support both success and failure of specified security events
115. Ensure logs contain important log event data
116. Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software
117. Restrict access to logs to only authorized individuals
118. Utilize a master routine for all logging operations
119. Do not store sensitive information in logs, including unnecessary system details, session IDs or passwords
120. Ensure that a mechanism exists to conduct log analysis
121. Log all input validation failures
122. Log all authentication attempts, especially failures
123. Log all access control failures
124. Log all tempering events, including unexpected changes to state data
125. Log attempts to connect with invalid or expired session tokens
126. Log all system exceptions
127. Log all administrative functions, including changes to the security configuration settings
128. Log all backend TLS connection failures
129. Log cryptographic module failures
130. Use a cryptographic hash function to validate log entry integrity

Data Protection

131. implement least privilege
     • user must only access to things that really needs
132. Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files as soon as they are no longer required
133. Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see "Cryptographic Practices" for additional guidance
134. Protect server-side source code from being downloaded by a user
135. Do not store passwords, connection strings or other sensitive information in clear text or in any non-cryptographically secure manner on the client side
136. Remove comments in user accessible production code that may reveal backend or other sensitive information
137. Remove unnecessary application and system documentation as this can reveal useful information to attackers
138. Do not include sensitive information in HTTP GET request parameters
139. Disable auto complete features on forms expected to contain sensitive information
140. Disable client side caching on pages containing sensitive information. Cache-Control: no-store, may be used in conjunction with the HTTP header control Pragma: no-cache, which is less effective, but is HTTP/1.0 backward compatible
141. The application should support the removal of sensitive data when that data is no longer required
142. Implement appropriate access controls for sensitive data stored on the server. This includes cached data, temporary files and data that should be accessible only by specific system users

Communication Security

143. Implement encryption for the transmission of all sensitive information
144. TLS certificates should be valid and have the correct domain name, not be expired, and be installed with intermediate certificates when required
145. Failed TLS connections should not fall back to an insecure connection
146. Utilize TLS connections for all content requiring authenticated access and for all other sensitive information
147. Utilize TLS for connections to external systems that involve sensitive information or functions
148. Utilize a single standard TLS implementation that is configured appropriately
149. Specify character encodings for all connections
150. Filter parameters containing sensitive information from the HTTP referer, when linking to external sites

System Configuration

151. Ensure servers, frameworks and system components are running the latest version
152. Ensure servers, frameworks and system components have all patches issued for the version in use
153. Turn off directory listings
154. Restrict the web server, process and service accounts to the least privileges possible
155. When exceptions occur, fail securely
156. Remove all unnecessary functionality and files
157. Remove test code or any functionality not intended for production, prior to deployment
158. Prevent disclosure of your directory structure in the robots.txt file by placing directories not intended for public indexing into an isolated parent directory. Then "Disallow" that entire parent directory in the robots.txt file rather than Disallowing each individual directory
159. Define which HTTP methods, GET or POST, the application will support and whether it will be handled differently in different pages in the application
160. Disable unnecessary HTTP methods, such as WebDAV extensions. If an extended HTTP method that supports file handling is required, utilize a well-vetted authentication mechanism
161. if the web server handles both HTTP 1.0 and 1.1, ensure that both are configured in a similar way or ensure that you understand any difference that may exist (e.g. handling of extended HTTP methods)
162. Remove unnecessary information from HTTP response headers related to the OS, web-server version and application frameworks
163. The security configuration store for the application should be able to be output in human-readable form to support auditing
164. Implement an asset management system and register system components and software in it
165. Isolate Production environment and Development environment (network)
     • test or Development environments are often less secure
     • test environment must be access only by authorized test groups
166. Implement a software change control system to manage and record changes to the code both in development and production

Database Security

167. Use strongly typed parameterized queries
168. Utilize input validation and output encoding and be sure to address meta characters. If these fail, do not run the database command
169. Ensure that variables are strongly typed
170. The application should use the lowest possible level of privilege when accessing the database
171. Use secure credentials for database access
172. Connection strings should not be hard coded within the application. Connection strings should be stored in a separate configuration file on a trusted system, and they should be encrypted.
173. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database
174. Close the connection as soon as possible
175. Remove or change all default database administrative passwords. Utilize strong passwords/phrases or implement multi-factor authentication
176. Turn off all unnecessary database functionality
     • (e.g., unnecessary stored procedures or services, utility packages, install only the minimum set of features and options required (surface area reduction))
177. Remove unnecessary default vendor content (e.g., sample schemas)
178. Disable any default accounts that are not required to support business requirements
179. The application should connect to the database with different credentials for every trust distinction (e.g., user, read-only user, guest, administrators)

File Management

180. Do not pass user supplied data directly to any dynamic include function
181. Require authentication before allowing a file to be uploaded
182. Limit the type of files that can be uploaded to only those types that are needed for business purposes
183. Validate uploaded files are the expected type by checking file headers. Checking for file type by extension alone is not sufficient
184. Do not save files in the same web context as the application. Files should either go to the content server or in the database
185. Prevent or restrict the uploading of any file that may be interpreted by the web server
186. Turn off execution privileges on file upload directories
187. Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive using the associated path or the chrooted environment
188. When referencing existing files, use a white list of allowed file names and types. Validate the value of the parameter being passed and if it does not match one of the expected values, either reject it or use a hard coded default file value for the content instead
189. Do not pass user supplied data into a dynamic redirect. If this must be allowed, then the redirect should accept only validated, relative path URLs
190. Do not pass directory or file paths, use index values mapped to pre-defined list of paths
191. Never send the absolute file path to the client
192. Ensure application files and resources are read-only
193. Scan user uploaded files for viruses and malware

Memory Management

194. Utilize input and output control for un-trusted data
195. Double check that the buffer is as large as specified
196. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string
197. Check buffer boundaries if calling the function in a loop and make sure there is no danger of writing past the allocated space
198. Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions
199. Specifically close resources, don’t rely on garbage collection. (e.g., connection objects, file handles, etc.)
200. Use non-executable stacks when available
201. Avoid the use of known vulnerable functions (e.g., printf, strcat, strcpy etc.)
202. Properly free allocated memory upon the completion of functions and at all exit points

General Coding Practices

202. Use tested and approved managed code rather than creating new unmanaged code for common tasks
203. Utilize task specific built-in APIs to conduct operating system tasks
     • Do not allow application to directly execute OS commands
204. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
205. Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions
206. Protect shared variables and resources from inappropriate concurrent access
207. Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage
208. In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible
209. Avoid calculation errors by understanding your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation
210. Do not pass user supplied data to any dynamic execution function
211. Restrict users from generating new code or altering existing code
212. Review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality
213. Implement safe updating
     • if applications uses automate updating, implement ways to verify signature of updates
     • Use encrypted channels to transfer the code from the host server

Glossary

• See OWASP Secure Coding Practices Glossary Section