From c14679480ce5ecac267619417c447419e24d7588 Mon Sep 17 00:00:00 2001 From: Jon Gadsden Date: Wed, 29 Oct 2025 20:32:16 +0000 Subject: [PATCH] rmeove appendices --- .../01-container-security.md | 124 ------- .../02-secure-coding.md | 326 ------------------ .../03-cryptographic-practices.md | 58 ---- .../04-application-spoofing.md | 66 ---- .../05-content-security-policy.md | 143 -------- .../06-exception-error-handling.md | 93 ----- .../07-file-management.md | 35 -- .../08-memory-management.md | 19 - .../01-implementation-dos-donts/index.md | 13 - .../01-secure-environment.md | 59 ---- .../02-system-hardening.md | 65 ---- .../03-open-source-software.md | 101 ------ .../02-verification-dos-donts/index.md | 14 - 13 files changed, 1116 deletions(-) delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/01-container-security.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/02-secure-coding.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/03-cryptographic-practices.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/04-application-spoofing.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/05-content-security-policy.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/06-exception-error-handling.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/07-file-management.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/08-memory-management.md delete mode 100644 docs/en/12-appendices/01-implementation-dos-donts/index.md delete mode 100644 docs/en/12-appendices/02-verification-dos-donts/01-secure-environment.md delete mode 100644 docs/en/12-appendices/02-verification-dos-donts/02-system-hardening.md delete mode 100644 docs/en/12-appendices/02-verification-dos-donts/03-open-source-software.md delete mode 100644 docs/en/12-appendices/02-verification-dos-donts/index.md diff --git a/docs/en/12-appendices/01-implementation-dos-donts/01-container-security.md b/docs/en/12-appendices/01-implementation-dos-donts/01-container-security.md deleted file mode 100644 index d2f673ea..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/01-container-security.md +++ /dev/null @@ -1,124 +0,0 @@ -This is a collection of Do's and Don'ts when it comes to container security, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -Container image security, host security, client security, daemon security, runtime security: - -* Choose the right base image -* Include only the required packages in the image -* If using Docker images, use multi-stage builds -* Use layer caching and multi stage builds to: - * Separate build-time dependencies from runtime dependencies - * Remove special permissions from images - * `find / -perm /6000 -type f -exec ls -ld {} \;` - * RUN `find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true` -* Reduce overall image size by shipping only what your app needs to run, - see the [Docker documentation][docker] for more information -* Remove unused images with prune: `docker image prune [OPTIONS]` -* Do not embed any secrets, passwords, keys, credentials, etc in images -* Use a read-only file system -* Sign images with cryptographic keys and not with username/password combination -* Secure your code and its dependencies -* Test your images for vulnerabilities -* Monitor container runtimes -* Docker Content Trust (DCT) is enabled on Docker clients -* Check freshness security of images with the provided timestamp key that is associated with the registry. -* Create the timestamp key by Docker and store on the server -* Use tagging keys associated with a registry. - Such that a poisoned image from a different registry cannot be pushed into a registry. -* Use offline keys to sign the tagging keys. -* Offline keys are owned by the organization and secured in an out-of-band location. -* Scan images frequently for any vulnerabilities. Rebuilt all images to include patches - and instantiate new containers from them -* Remove `setuid` and `setgid` permissions from the images. -* Where applicable, use 'copy' instruction in place of 'add' instruction. -* Verify authenticity of packages before installing them into images -* Use namespaces and control groups for containers -* Use bridge interfaces for the host -* Authenticity of packages is verified before installing them into images -* Mount files on a separate partition to address any situation where the mount becomes full, - but the host still remains usable -* Mark registries as private and only use signed images. -* Pass commands through the authorization plugin to ensure that only authorized client connects to the daemon -* TLS authentication is configured to restrict access to the Docker daemon -* Namespaces are enabled to ensure that -* Leave control groups (cgroups) at default setting to ensure that tampering does not take place - with excessive resource consumption. -* Do not enable experimental features for Docker -* set docker.service file ownership to root:root. -* Set docker.service file permissions to either 644 or to a more restrictive value. -* Set docker.socket file ownership and group ownership to root. -* Set file permissions on the docker.socket file to 644 or more restrictively -* Set /etc/docker directory ownership and group ownership to root -* Set /etc/docker directory permissions to 755 or more restrictively -* Set ownership of registry certificate files (usually found under `/etc/docker/certs.d/` directory) - to individual ownership and is group owned by root. -* Set registry certificate files (usually found under `/etc/docker/certs.d/` directory) - permissions to 444 or more restrictively. -* Acquire and ship daemon logs to SIEM for monitoring -* Inter-container network connections are restricted and enabled on a requirement basis. - By default containers cannot capture packets that have other containers as destination -* Where hairpin NAT is enabled, userland proxy is disabled -* Docker daemon is run as a non-root user to mitigate lateral privilege escalation - due to any possible compromise of vulnerabilities. -* `No_new_priv` is set (but not to false) to ensure that containers cannot gain additional privileges - via `suid` or `sgid` -* Default SECCOMP profile is applied for access control. -* TLS CA certificate file on the image host (the file that is passed along with the `--tlscacert` parameter) - is individually owned and group owned by root -* TLS CA certificate file on the image host (the file that is passed along with the `--tlscacert` parameter) - has permissions of 444 or is set more restrictively -* Containers should run as a non-root user. -* Containers should have as small a footprint as possible, and should not contain unnecessary software packages - which could increase their attack surface -* Docker default bridge 'docker0' is not used to avoid ARP spoofing and MAC flooding attacks -* Either Dockers AppArmor policy is enabled or the Docker hosts AppArmor is enabled. -* SELinux policy is enabled on the Docker host. -* Linux kernel capabilities are restricted within containers -* privileged containers are not used -* sensitive host system directories are not mounted on containers -* `sshd` is not run within containers -* privileged ports are not mapped within containers (TCP/IP port numbers below 1024 are considered privileged ports) -* only needed ports are open on the container. -* the hosts network namespace is not shared. -* containers root filesystem is mounted as read only -* Do not use docker exec with the `--privileged` option. -* docker exec commands are not used with the user=root option -* cgroup usage is confirmed -* The `no_new_priv` option prevents LSMs like SELinux from allowing processes to acquire new privileges -* Docker socket is not mounted inside any containers to prevent processes running within the container - to execute Docker commands which would effectively allow for full control of the host. -* incoming container traffic is bound to a specific host interface -* hosts process namespace is not shared to ensure that processes are separated -* hosts IPC namespace is not shared to ensure that inter-process communications does not take place -* host devices are not directly exposed to containers -* hosts user namespaces are not shared to ensure isolation of containers -* CPU priority is set appropriately on containers -* memory usage for containers is limited. -* 'on-failure' container restart policy is set to '5' -* default `ulimit` is overwritten at runtime if needed -* container health is checked at runtime -* PIDs cgroup limit is used (limit is set as applicable) -* The Docker host is hardened to ensure that only Docker services are run on the host -* Secure configurations are applied to ensure that the containers do not gain access to the host via the Docker daemon -* Docker is updated with the latest patches such that vulnerabilities are not compromised -* The underlying host is managed to ensure that vulnerabilities are identified and mitigated with patches -* Docker server certificate file (the file that is passed along with the `--tlscert` parameter) - is individual owned and group owned by root. -* Docker server certificate file (the file that is passed along with the `--tlscert` parameter) - has permissions of 444 or more restrictive permissions. -* Docker server certificate key file (the file that is passed along with the `--tlskey` parameter) - is individually owned and group owned by root. -* Docker server certificate key file (the file that is passed along with the `--tlskey` parameter) has permissions of 400 -* Docker socket file is owned by root and group owned by docker. -* Docker socket file has permissions of 660 or are configured more restrictively -* ensure `daemon.json` file individual ownership and group ownership is correctly set to root, if it is in use -* if `daemon.json` file is present its file permissions are correctly set to 644 or more restrictively - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140101] or [edit on GitHub][edit140101]. - -[docker]: https://docs.docker.com/get-started/09_image_best/ -[edit140101]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/01-container-security.md -[issue140101]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/01-container-security diff --git a/docs/en/12-appendices/01-implementation-dos-donts/02-secure-coding.md b/docs/en/12-appendices/01-implementation-dos-donts/02-secure-coding.md deleted file mode 100644 index 6858a39e..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/02-secure-coding.md +++ /dev/null @@ -1,326 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to secure coding, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -* Authentication - * User - * Require authentication for all pages and resources, except those specifically intended to be public - * Perform all authentication on server side. Send credentials only on encrypted channel (HTTPS) - * Use a centralized implementation for all authentication controls, including libraries that call external - authentication services. Use security vetted libraries for federation (Okta / PING / etc). - If using third party code for authentication, inspect the code carefully to ensure it is not affected - by any malicious code - * Segregate authentication logic from the resource being requested and use redirection to and from - the centralized authentication control - * Validate the authentication data only on completion of all data input, - especially for sequential authentication implementations - * Authentication failure responses should not indicate which part of the authentication data was incorrect. - For example, instead of "Invalid username" or "Invalid password", - just use "Invalid username and/or password" for both. - Error responses must be truly identical in both display and source code - * Utilize authentication for connections to external systems that involve sensitive information or functions - * Authentication credentials for accessing services external to the application should be encrypted - and stored in a protected location on a trusted system (e.g., Secrets Manager). - The source code is NOT a secure location. - * Do not store passwords in code or in configuration files. Use Secrets Manager to store passwords - * Use only HTTP POST requests to transmit authentication credentials - * Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. - This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed - * Re-authenticate users prior to performing critical operations - * Use Multi-Factor Authentication for highly sensitive or high value transactional accounts - * If using third party code for authentication, inspect the code carefully - to ensure it is not affected by any malicious code - * Restrict the user if a pre-defined number of failed logon attempts exceed. - Restrict access to a limited number of attempts to prevent brute force attacks - * Partition the portal into restricted and public access areas - * Restrict authentication cookies to HTTPS connections - * If the application has any design to persist passwords in the database, hash and salt the password - before storing in database. Compare hashes to validate password - * Authenticate the user before authorizing access to hidden directories - * Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks - by using the same messages for all outcomes. - * Server - * When using SSL/TLS, ensure that the server identity is established by following a trust chain - to a known root certificate - * When using SSL/TLS, validate the host information of the server certificate. - * If weak client authentication is unavoidable, perform it only over a secure channel - * Do not rely upon IP numbers or DNS names in establishing identity. - * Ensure all internal and external connections (user and entity) go through an appropriate - and adequate form of authentication. Be assured that this control cannot be bypassed. - * For the account that runs the web server: - * Grant permissions to only those folders that the application needs to access - * Grant only those privileges that the account needs - * Disable HTTP TRACE. - It can help in bypassing WAF because of it inherent nature of TRACE response includes all headers on its route. - Please see - [Three Minutes with the HTTP TRACE Method][trace] - for further details - * Disable WEBDav feature unless it is required for business reasons. - If it is, perform a risk assessment for enabling the feature on your environment. - * Ensure that authentication credentials are sent on an encrypted channel - * Ensure development/debug backdoors are not present in production code. - * Password policy - * Provide a mechanism for self-reset and do not allow for third-party reset. - * If the application has any design to persist passwords in the database, hash and salt the password - before storing in database. Compare hashes to validate password. - * Rate limit bad password guesses to a fixed number(5) in a given time period (5-minute period) - * Provide a mechanism for users to check the quality of passwords when they set or change it. - * 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 - * Enforce password complexity requirements established by policy or regulation. - Authentication credentials should be sufficient to withstand attacks that are typical - of the threats in the deployed environment. - (e.g., requiring the use of alphabetic as well as numeric and/or special characters) - * Enforce password length requirements established by policy or regulation. Eight characters is commonly used, - but 16 is better or consider the use of multi-word pass phrases - * Password entry should be obscured on the user's screen. (e.g., on web forms use the input type "password") - * Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common). - The account must be disabled for a period of time sufficient to discourage brute force guessing of credentials, - but not so long as to allow for a denial-of-service attack to be performed - * Password reset and changing operations require the same level of controls as account creation and authentication. - * Password reset questions should support sufficiently random answers. - (e.g., "favorite book" is a bad question because “The Bible” is a very common answer) - * If using email based resets, only send email to a pre-registered address with a temporary link/password - * Temporary passwords and links should have a short expiration time - * Enforce the changing of temporary passwords on the next use - * Notify users when a password reset occurs - * Prevent password re-use - * For high risk application (for example banking applications or any application the compromise of credentials - of which may lead to identity theft), passwords should be at least one day old before they can be changed, - to prevent attacks on password re-use - * Enforce password changes based on requirements established in policy or regulation. Critical systems - may require more frequent changes. The time between resets must be administratively controlled - * Disable "remember me" functionality for password fields - * Avoid sending authentication information through E-mail, particularly for existing users. -* Authorization - * Access control - * Build authorization on rules based access control. - Persist the rules as a matrix (for example as a list of strings which is passed as a parameter to a method - that is run when the user first access the page, based on which access is granted). - Most frameworks today, support this kind of matrix. - * Check if the user is authenticated before checking the access matrix. - If the user is not authenticated, direct the user to the login page. - Alternatively, use a single site-wide component to check access authorization. - This includes libraries that call external authorization services - * Ensure that the application has clearly defined the user types and the privileges for the users. - * Ensure there is a least privilege stance in operation. Add users to groups and assign privileges to groups - * Scan the code for development/debug backdoors before deploying the code to production. - * Re-Authenticate the user before authorizing the user to perform business critical activities - * Re-Authenticate the user before authorizing the user to admin section of the application - * Do not include authorization in the query string. Direct the user to the page via a hyperlink on a page. - Authenticate the user before granting access. For example if `admin.php` is the admin page for `www.example.com` - do not create a query string like `www.example.com/admin.php`. - Instead include a hyperlink to `admin.php` on a page and control authorization to the page - * Prevent forced browsing with role based access control matrix - * Ensure Lookup IDs are not accessible even when guessed and lookup IDs cannot be tampered with - * 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 - * Server side implementation and presentation layer representations of access control rules must match - * Implement access controls for POST, PUT and DELETE especially when building an API - * Use the "referer" header as a supplemental check only, it should never be the sole authorization check, - as it is can be spoofed - * Ensure it is not possible to access sensitive URLs without proper authorization. - Resources like images, videos should not be accessed directly by simply specifying the correct path - * Test all URLs on administrator pages to ensure that authorization requirements are met. - If verbs are sent cross domain, pin the OPTIONS request for non-GET verbs to the IP address of - subsequent requests. This will be a first step toward mitigating DNS Rebinding and TOCTOU attacks. - * Session management - * Creation of session: Use the server or framework’s session management controls. - The application should only recognize these session identifiers as valid - * Creation of session: Session identifier creation must always be done on a trusted system (e.g., The server) - * Creation of session: If a session was established before login, - close that session and establish a new session after a successful login - * Creation of session: Generate a new session identifier on any re-authentication - * Random number generation: Session management controls should use well vetted algorithms - that ensure sufficiently random session identifiers. - Rely on CSPRNG rather than PRNG for random number generation - * Domain and path: Set the domain and path for cookies containing authenticated session identifiers - to an appropriately restricted value for the site - * Logout: Logout functionality should fully terminate the associated session or connection - * Session timeout: Establish a session inactivity timeout that is as short as possible, - based on balancing risk and business functional requirements. - In most cases it should be no more than several hours - * Session ID: Do not expose session identifiers in URLs, error messages or logs. - Session identifiers should only be located in the HTTP cookie header. For example, - do not pass session identifiers as GET parameters - * Session ID: 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 - * JWT - * Reject tokens set with ‘none’ algorithm when a private key was used to issue them (`alg: ""none""`). - This is because an attacker may modify the token and hashing algorithm to indicate, through the ‘none’ keyword, - that the integrity of the token has already been verified, - fooling the server into accepting it as a valid token - * Use appropriate key length (e.g. 256 bit) to protect against brute force attacks. - This is because attackers may change the algorithm from ‘RS256’ to ‘HS256’ and use the public key to generate - a HMAC signature for the token, as server trusts the data inside the header of a JWT - and doesn’t validate the algorithm it used to issue a token. - The server will now treat this token as one generated with ‘HS256’ algorithm - and use its public key to decode and verify it - * Adjust the JWT token validation time depending on required security level (e.g. from few minutes up to an hour). - For extra security, consider using reference tokens if there’s a need to be able to revoke/invalidate them - * Use HTTPS/SSL to ensure JWTs are encrypted during client-server communication, - reducing the risk of the man-in-the-middle attack. This is because sensitive information may be revealed, - as all the information inside the JWT payload is stored in plain text - * Only use up-to-date and secure libraries and choose the right algorithm for requirements - * Verify all tokens before processing the payload data. Do not use unsigned tokens. - For the tokens generated and consumed by the portal, sign and verify tokens - * Always check that the `aud` field of the JWT matches the expected value, - usually the domain or the URL of your APIs. If possible, check the "sub" (client ID) - make sure that - this is a known client. This may not be feasible however in a public API situation - (e.g., we trust all clients authorized by Google). - * Validate the issuer's URL (`iss`) of the token. It must match your authorization server. - * If an authorization server provides X509 certificates as part of its JWT, - validate the public key using a regular PKIX mechanism - * Make sure that the keys are frequently refreshed/rotated by the authorization server. - * Make sure that the algorithms you use are sanctioned by JWA ([RFC7518][rfc7518]) - * There is no built in mechanism to revoke a token manually, before it expires. - One way to ensure that the token is force expired build a service that can be called on log out. - In the mentioned service, block the token. - * Restrict accepted algorithms to the ONE you want to use - * Restrict URLs of any JWKS/X509 certificates - * Use the strongest signing process you can afford the CPU time for - * Use asymmetric keys if the tokens are used across more than one server - * SAML -* Input data validation - * Identify input fields that form a SQL query. Check that these fields - are suitably validated for type, format, length, and range. - * To prevent SQL injection use bind variables in stored procedures and SQL statements. - Also referred as prepared statements / parameterization of SQL statements. - DO NOT concatenate strings that are an input to the database. - The key is to ensure that raw input from end users is not accepted without sanitization. - When converting data into a data structure (deserializing), perform explicit validation for all fields, - ensuring that the entire object is semantically valid. - Many technologies now come with data access layers that support input data validation. - These layers are usually in the form of a library or a package. Ensure to add - these libraries / dependencies / packages to the project file such that they are not missed out. - * Use a security vetted library for input data validation. Try not to use hard coded allow-list of characters. - Validate all data from a centralized function / routine. - In order to add a variable to a HTML context safely, use HTML entity encoding - for that variable as you add it to a web template. - * Validate HTTP headers. Dependencies that perform HTTP headers validation are available in technologies. - * Validate post backs from javascript. - * Validate data from http headers, input fields, hidden fields, drop down lists & other web components - * Validate data retrieved from database. This will help mitigate persistent XSS. - * Validate all redirects. Unvalidated redirects may lead to data / credential exfiltration. - Evaluate any URL encodings before trying to use the URL. - * Validate data received from redirects. The received data may be from untrusted source. - * If any potentially hazardous characters must be allowed as input, - be sure that you implement additional controls like output encoding, - secure task specific APIs and accounting for the utilization of that data throughout the application. - Examples of common hazardous characters include `< > " ' % ( ) & + \ \' \"` - * If your standard validation routine cannot address the following inputs, then they should be checked discretely - * Check for null bytes `%00` - * Check for new line characters `%0d, %0a, \r, \n` - * Check for “dot-dot-slash" `../` or `..\` path alterations characters. - In cases where UTF-8 extended character set encoding is supported, address alternate representation like: - `%c0%ae%c0%ae/` - (Utilize canonicalization to address double encoding or other forms of obfuscation attacks) - * Client-side storage (`localStorage`, `SessionStorage`, `IndexedDB`, WebSQL): - If you use client-side storage for persistence of any variables, - validate the date before consuming it in the application - * Reject all input data that has failed validation. - * If used, don’t involve user parameters in calculating the destination. This can usually be done. - If destination parameters can’t be avoided, ensure that the supplied value is valid, - and authorized for the user. - It is recommended that any such destination parameters be a mapping value, - rather than the actual URL or portion of the URL, - and that server side code translate this mapping to the target URL. - Applications can use ESAPI to override the `sendRedirect()` method - to make sure all redirect destinations are safe. -* Output data encoding - * If your code echos user input or URL parameters back to a Web page, validate input data as well as output data. - It will help you prevent persistent as well as reflective cross-site scripting. - Pay particular attention to areas of the application that permit users - to modify configuration or personalization settings. - Also pay attention to persistent free-form user input, - such as message boards, forums, discussions, and Web postings. - Encode javascript to prevent injection by escaping non-alphanumeric characters. - Use quotation marks like " or ' to surround your variables. - Quoting makes it difficult to change the context a variable operates in, which helps prevent XSS - * Conduct all encoding on a trusted system (e.g., The server) - Utilize a standard, tested routine for each type of outbound encoding - Contextually output encode all data returned to the client - that originated outside the application's trust boundary. - HTML entity encoding is one example, but does not work in all cases - Encode all characters unless they are known to be safe for the intended interpreter - Contextually sanitize all output of untrusted data to queries for SQL, XML, and LDAP - Sanitize all output of untrusted data to operating system commands - * Output encoding is not always perfect. It will not always prevent XSS. Some contexts are not secure. These include: - Callback functions - Where URLs are handled in code such as this CSS `{ background-url : “javascript:alert(test)”; }` - All JavaScript event handlers (`onclick()`, `onerror()`, `onmouseover()`). - Unsafe JavaScript functions like `eval()`, `setInterval()`, `setTimeout()` - Don't place variables into these contexts as even with output encoding, it will not prevent an XSS attack fully - * Do not rely on client-side validation. Perform validation on server side to prevent second order attacks. -* Canonicalisation - * Convert all input data to an accepted/decided format like UTF-8. This will help prevent spoofing of character -* Test all URLs with different parameter values. - Spider and check the site/product/application/portal for redirects. -* Connection with backend - Assign required permissions and privileges for accounts / roles - used by the application to connect to the database. - In the event of any compromise of the account / role, - the malicious actor would be able to do whatever the account /role has permissions for. -* Insecure direct object references -* Unvalidated redirects - Test all URLs with different parameter values to validate any redirects - If used, do not allow the URL as user input for the destination. - Where possible, have the user provide short name, ID or token which is mapped server-side to a full target URL. - This provides the protection against the URL tampering attack. - Be careful that this doesn't introduce an enumeration vulnerability where - a user could cycle through IDs to find all possible redirect targets - If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, - and is authorized for the user. - Sanitize input by creating a list of trusted URLs (lists of hosts or a regex). - This should be based on an allow-list approach, rather than a block list. - Force all redirects to first go through a page notifying users that they are going off of your site, - with the destination clearly displayed, and have them click a link to confirm. -* JSON - For JSON, verify that the Content-Type header is application/json and not text/html to prevent XSS - Do not use duplicate keys. Usage of duplicate keys may be processed differently by parsers. - For example last-key precedence versus first-key precedence. -* Generate fatal parse errors on duplicate keys. - Do not perform character truncation. Instead, replace invalid Unicode with placeholder characters - (e.g., unpaired surrogates should be displayed as the Unicode replacement character `U+FFFD`). - Truncating may break sanitization routines for multi-parser applications." -* Produce errors when handling integers or floating-point numbers that cannot be represented faithfully -* Do not use `eval()` with JSON. This opens up for JSON injection attacks. Use JSON.parse() instead - Data from an untrusted source is not sanitized by the server and written directly to a JSON stream. - This is referred to as server-side JSON injection. - Data from an untrusted source is not sanitized and parsed directly using the JavaScript `eval` function. - This is referred to as client-side JSON injection. - To prevent server-side JSON injections, sanitize all data before serializing it to JSON - Escape characters like ":", "\", "@", "'”", "%", "?", "--", ">", "<", "&" - -#### JSON Vulnerability Protection - -A JSON vulnerability allows third party website to turn your JSON resource URL into JSONP request under some conditions. -To counter this your server can prefix all JSON requests with following string `")]}',\n"`. -AngularJS will automatically strip the prefix before processing it as JSON. - -For example if your server needs to return: `['one','two']` -which is vulnerable to attack, your server can return: `)]}', ['one','two']` - -Refer to [JSON vulnerability protection](https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection) -Always have the outside primitive be an object for JSON strings - -Exploitable: `[{""object"": ""inside an array""}]` - -Not exploitable: `{""object"": ""not inside an array""}` - -Also not exploitable: `{""result"": [{""object"": ""inside an array""}]}"` - -* Avoid manual build of JSON, use an existing framework -* Ensure calling function does not convert JSON into a javascript - and JSON returns its response as a non-array json object -* Wrap JSON in () to force the interpreter to think of it as JSON and not a code block -* When using node.js, on the server use a proper JSON serializer to encode user-supplied data properly - to prevent the execution of user-supplied input on the browser. - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140102] or [edit on GitHub][edit140102]. - -[edit140102]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/02-secure-coding.md -[issue140102]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/02-secure-coding -[rfc7518]: https://www.rfc-editor.org/rfc/rfc7518 -[trace]: https://www.blackhillsinfosec.com/three-minutes-with-the-http-trace-method/ diff --git a/docs/en/12-appendices/01-implementation-dos-donts/03-cryptographic-practices.md b/docs/en/12-appendices/01-implementation-dos-donts/03-cryptographic-practices.md deleted file mode 100644 index f815fe90..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/03-cryptographic-practices.md +++ /dev/null @@ -1,58 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to cryptographic practices, gathered from practical experiences. - -* The basis for usage of PKI is to address (using encryption and hashing) -* Confidentiality -* Integrity -* Authentication -* Non-repudiation -* Cryptography is used for the following: - * Data-at-rest protection using data encrypting keys and key encrypting keys. For which, -* Do not use custom cryptographic algorithms / deprecated algorithms -* Do not use passwords as cryptographic keys -* Do not hard-code cryptographic keys in the application -* Persist secret keys in a secure vault like HSM, KMS, Secrets Manager -* Manage encryption keys through the lifecycle, including key retirement/replacement - when someone who has access leaves the organization -* Rotate keys on a regular basis. However this depends on the key strength and the algorithm used. - If the key strength is low, the rotation period will be smaller -* Maintain a contingency plan to recover data in the event of an encrypted key being lost -* Ensure the code eliminates secrets from memory. -* Maintain a contingency plan that can recover data in the event of an encrypted key being lost -* Store keys away from the data -* Do not use IV twice for a fixed key -* Communication security -* Ensure no sensitive data is transmitted in the clear, internally or externally. -* Validate certificates properly against the hostnames/users for whom they are meant -* Failed TLS connections should not fall back to an insecure connection -* Do not use IV twice for a fixed key -* Cryptography in general -* All protocols and algorithms for authentication and secure communication - should be well vetted by the cryptographic community. -* Perform Message integrity checking by using a combined mode of operation, or a MAC based on a block cipher. -* Do not use key sizes less than 128 bits or cryptographic hash functions with output sizes less than 160 bits. -* Do not use custom cryptographic algorithms that have not been vetted by cryptography community -* Do not hardcode cryptographic keys in applications? -* Issue keys using a secure means. -* Maintain a key lifecycle for the organization (Creation, Storage, Distribution and installation, Use, - Rotation, Backup, Recovery, Revocation, Suspension, Destruction) -* Lock and unlock symmetric secret keys securely -* Maintain CRL (Certificate Revocation Lists) maintained on a real-time basis -* Validate certificates properly against the hostnames/users for whom they are meant -* Ensure the code eliminates secrets from memory -* Specific encryption, in addition to SSL -* Mask or remove keys from logs -* Use salted hashes when using MD5 or any such less secure algorithms -* Use known encryption algorithms, do not create your own as they will almost certainly be less secure -* Persist secret keys in a secure vault like HSM, KMS, Secrets Manager -* Do not use IV twice for a fixed key -* Ensure that cryptographic randomness is used where appropriate, - and that it has not been seeded in a predictable way or with low entropy. - Most modern APIs do not require the developer to seed the CSPRNG to get security. - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140103] or [edit on GitHub][edit140103]. - -[edit140103]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/03-cryptographic-practices.md -[issue140103]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/03-cryptographic-practices diff --git a/docs/en/12-appendices/01-implementation-dos-donts/04-application-spoofing.md b/docs/en/12-appendices/01-implementation-dos-donts/04-application-spoofing.md deleted file mode 100644 index 3a887fc1..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/04-application-spoofing.md +++ /dev/null @@ -1,66 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to application spoofing, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -What is application spoofing: - -* A threat actor including an application in a malicious iFrame -* A threat actor creating dependencies with similar names as legitimate ones (typo squatting) - -How can it be addressed: - -#### Application spoofing / clickjacking - -Set `X-FRAME-OPTIONS` header to `SAMEORIGIN` or `DENY`, depending on what the business requirement is -for rendering the web page. -This will help prevent a malicious actor including your application in an iFrame to capture credentials/exfiltrate data. -As a caveat, this will not work with Meta Tags. X-FRAME-OPTIONS must be applied as HTTP Response Header - -Use Content Security Policy: - -Common uses of CSP frame-ancestors: - -Content-Security-Policy: frame-ancestors 'none'; - -This prevents any domain from framing the content. This setting is recommended unless a specific need -has been identified for framing. - -Content-Security-Policy: frame-ancestors 'self'; - -This only allows the current site to frame the content. - -Content-Security-Policy: frame-ancestors 'self' `*.somesite.com https://myfriend.site.com;` - -This allows the current site, as well as any page on `somesite.com` (using any protocol), -and only the page `myfriend.site.com`, using HTTPS only on the default port (443). - -Use `SameSite` Cookies - -Use `httpOnly` cookies - -#### Domain squatting / typo squatting - -What is domain squatting (also known as cybersquatting): - -* A threat actor creating a malicious domain with the same spelling as a legitimate domain - but use different UTF characters (domain squatting) -* A threat actor registering, trafficking in, or using an Internet domain name, - with an intent to profit from the goodwill of a trademark belonging to someone else -* Though domain squatting impacts brand value directly, it has an impact from a security perspective -* It can result in the following kind of scenario: (also known as typosquatting) - Wherein the domain with U+00ED may be a malicious application trying to harvest credentials -* Typo squatting is achieved with supply chain manipulation. - -How can it be addressed: - -* Use threat intelligence to monitor lookalikes for your domain -* In the event a dispute needs to be raised, it can be done with [URDP][urdp] -* Verify packages in registries before using them - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140104] or [edit on GitHub][edit140104]. - -[edit140104]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/04-application-spoofing.md -[issue140104]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/04-application-spoofing -[urdp]: https://www.icann.org/resources/pages/help/dndr/udrp-en diff --git a/docs/en/12-appendices/01-implementation-dos-donts/05-content-security-policy.md b/docs/en/12-appendices/01-implementation-dos-donts/05-content-security-policy.md deleted file mode 100644 index 89e61314..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/05-content-security-policy.md +++ /dev/null @@ -1,143 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to Content Security Policy, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -Content Security Policy (CSP) helps in allow-listing the sources that are allowed to be executed by clients. - -To this effect CSP helps in addressing vulnerabilities that are the target of scripts getting executed -from different domains (namely XSS, ClickJacking) - -1. The policy elements listed below is restrictive. - Third party libraries can be allow-listed as a part of `script-src`, `default-src`, `frame-src` - or `frame-ancestors`. - -2. I assume fonts / images / media / plugins are not loaded from any external sources. - -3. Do not use `\*\` as an attribute for any of the components of the policy. - -CSP considers two types of content: - -Passive content - resources which cannot directly interact with or modify other resources on a page: -images, fonts, audio, and video for example - -Active content - content which can in some way directly manipulate the resource with which a user is interacting. - -SCOPE - -The scope of this policy / procedure / whatever includes (but not limited to): - -- Applications that are displayed in browsers - - On desktops - - On laptops - - On mobile devices -- Mobile Applications - - iOS - - Android - -Policy for content security should be set in <> (insert the URL where the report for policy violations should be sent) -- sandbox (this is something to be tried out specifies an HTML sandbox policy - that the user agent applies to the protected resource) -- `plugin-types` <<>> (insert the list of plugins that the protected resource can invoke) -- `base-uri` (restricts the URLs that can be used to specify the document base URL, but I do not know how this is used) -- `child-src` 'self' - -An Example: - -```text - -``` - -For display on desktops and laptops: add `name="Content-Security-Policy"` value - -For display on other mobile devices that use HTML5: `meta http-equiv="Content-Security-Policy"` - -#### Mobile Application - -#### iOS - -iOS framework has capability to restrict connecting to sites that are not a part of the allow-list on the application, -which is the `NSExceptionDomains`. Use this setting to restrict the content that gets executed by the application - -```text -NSAppTransportSecurity : Dictionary { - NSAllowsArbitraryLoads : Boolean - NSAllowsArbitraryLoadsForMedia : Boolean - NSAllowsArbitraryLoadsInWebContent : Boolean - NSAllowsLocalNetworking : Boolean - NSExceptionDomains : Dictionary { - : Dictionary { - NSIncludesSubdomains : Boolean - NSExceptionAllowsInsecureHTTPLoads : Boolean - NSExceptionMinimumTLSVersion : String - NSExceptionRequiresForwardSecrecy : Boolean - NSRequiresCertificateTransparency : Boolean - } - } -} -``` - -#### Android - -Setting rules for Android application: - -- If your application doesn't directly use JavaScript within a WebView, do not call `setJavaScriptEnabled()` -- By default, WebView does not execute JavaScript, so cross-site-scripting is not possible -- Use `addJavaScriptInterface()` with particular care because it allows JavaScript to invoke operations - that are normally reserved for Android applications. If you use it, expose `addJavaScriptInterface()` - only to web pages from which all input is trustworthy -- Expose a`ddJavaScriptInterface()` only to JavaScript that is contained within your application APK -- When sharing data between two apps that you control or own, use signature-based permissions - -```text - - package="com.example.myapp"> - -``` - -- Disallow other apps from accessing Content Provider objects - -```text - - package="com.example.myapp"> - - - - - ... - - -``` - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140105] or [edit on GitHub][edit140105]. - -[edit140105]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/05-content-security-policy.md -[issue140105]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/05-content-security-policy diff --git a/docs/en/12-appendices/01-implementation-dos-donts/06-exception-error-handling.md b/docs/en/12-appendices/01-implementation-dos-donts/06-exception-error-handling.md deleted file mode 100644 index c7ee9293..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/06-exception-error-handling.md +++ /dev/null @@ -1,93 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to exception and error handling, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -* Ensure that all method/function calls that return a value have proper error handling and return value checking -* Ensure that exceptions and error conditions are properly handled -* Ensure that no system errors can be returned to the user -* Ensure that the application fails in a secure manner -* Ensure resources are released if an error occurs. -* Ensure that stack trace is not thrown to the user. -* Swallowing exceptions into an empty catch() block is not advised as an audit trail - of the cause of the exception would be incomplete -* Code that might throw exceptions should be in a try block and code that handles exceptions in a catch block -* If the language in question has a finally method, use it. The finally method is guaranteed to always be called -* The finally method can be used to release resources referenced by the method that threw the exception -* This is very important. An example would be if a method gained a database connection from a pool of connections, - and an exception occurred without finally, the connection object shall not be returned - to the pool for some time (until the timeout) -* This can lead to pool exhaustion. finally() is called even if no exception is thrown -* Handle errors and exception conditions in the code -* Do not expose sensitive information in user sessions -* When working with a multi-threaded or otherwise asynchronous environment, - ensure that proper locking APIs are used to lock before the if statement; - and unlock when it has finished. -* Types of errors: - * The result of business logic conditions not being met - * The result of the environment wherein the business logic resides fails - * The result of upstream or downstream systems upon which the application depends fail - * Technical hardware / physical failure -* Failures are never expected, but they do occur. - In the event of a failure, it is important not to leave the "doors" of the application open - and the keys to other "rooms" within the application sitting on the table. - In the course of a logical workflow, which is designed based upon requirements, - errors may occur which can be programmatically handled, - such as a connection pool not being available, or a downstream server not being contactable -* This is a very tricky guideline. - To fail securely, areas of failure should be examined during the course of the code review. - It should be examined if all resources should be released in the case of a failure - and during the thread of execution if there is any potential for resource leakage, - resources being memory, connection pools, file handles etc - Include a statement that defaults to safe failure -* The review of code should also include pinpointing areas where the user session should be terminated or invalidated. -Sometimes errors may occur which do not make any logical sense from a business logic perspective -or a technical standpoint; - e.g: ""A logged in user looking to access an account which is not registered to that user - and such data could not be inputted in the normal fashion.""" -* Examine the application for 'main()' executable functions and debug harnesses/backdoors - In their basic form, backdoors are user id / password combination with the required privileges, embedded in the code, - which can be used later on by the developer to get into the system without having to request for login credentials -* Search for commented out code, commented out test code, which may contain sensitive information -* Search for any calls to the underlying operating system or file open calls and examine the error possibilities - -#### Logging - -* Ensure that no sensitive information is logged in the event of an error -* Ensure the payload being logged is of a defined maximum length and that the logging mechanism enforces that length -* Ensure no sensitive data can be logged; E.g. cookies, HTTP GET method, authentication credentials -* Examine if the application will audit the actions being taken by the application on behalf of the client - (particularly data manipulation/Create, Read, Update, Delete (CRUD) operations) -* Ensure successful and unsuccessful authentication is logged -* Ensure application errors are logged -* Examine the application for debug logging with the view to logging of sensitive data -* Ensure change in sensitive configuration information is logged along with user who modified it. - Ensure access to secure storage areas including crypto keys are logged -* Credentials and sensitive user data should not be logged -* Does the code include poor logging practice of not declaring Logger object as static and final? -* Does the code allow entering invalidated user input to the log file? -* Capture following details for the events: - * User identification - * Type of event - * Date and time - * Success and failure indication - * Origination of event - * Identity or name of affected data, system component, resource, or service (for example, name and protocol) -* Log file access, privilege elevation, and failures of financial transactions -* Log all administrators actions. Log all actions taken after privileges are elevated - `runas` / `sudo` -* Log all input validation failures -* Log all authentication attempts, especially failures -* Log all access control failures -* Log all apparent tampering events, including unexpected changes to state data -* Log attempts to connect with invalid or expired session tokens -* Log all system exceptions -* Log all administrative functions, including changes to the security configuration settings -* Log all backend TLS connection failures -* Log cryptographic module failures -* Use a cryptographic hash function to validate log entry integrity - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140106] or [edit on GitHub][edit140106]. - -[edit140106]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/06-exception-error-handling.md -[issue140106]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/06-exception-error-handling diff --git a/docs/en/12-appendices/01-implementation-dos-donts/07-file-management.md b/docs/en/12-appendices/01-implementation-dos-donts/07-file-management.md deleted file mode 100644 index f7b4e297..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/07-file-management.md +++ /dev/null @@ -1,35 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to file management, gathered from practical experiences. - -* Validate all filenames and directories before use, ensuring that there are no special characters - that might lead to accessing an unintended file -* Use safe directories for all file access except those initiated by the end user - e.g. document saving and restoring to a user-chosen location -* Use a sub-domain with one way trust for the downloaded files. - Such that any compromise of the sub-domain does not impact the main domain. - Do not save files in the same web context as the application. - Files should either go to the content server or in the database -* Have at least 64 bits of randomness in all temporary file names -* where applicable, require authentication before allowing a file to be uploaded -* Limit the type of files that can be uploaded to only those types that are needed for business purposes -* Validate uploaded files are the expected type by checking file headers -* Prevent or restrict the uploading of any file that may be interpreted by the web server -* Turn off execution privileges on file upload directories -* Implement safe uploading in UNIX by mounting the targeted file directory as a logical drive - using the associated path or the chrooted environment -* When referencing existing files, use an allow 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 -* 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 -* Do not pass directory or file paths, use index values mapped to pre-defined list of paths -* Never send the absolute file path to the client -* Ensure application files and resources are read-only -* Scan user uploaded files for viruses and malware - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140107] or [edit on GitHub][edit140107]. - -[edit140107]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/07-file-management.md -[issue140107]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%20/12-appendices/01-implementation-dos-donts/07-file-management diff --git a/docs/en/12-appendices/01-implementation-dos-donts/08-memory-management.md b/docs/en/12-appendices/01-implementation-dos-donts/08-memory-management.md deleted file mode 100644 index 70514f45..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/08-memory-management.md +++ /dev/null @@ -1,19 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to memory management, gathered from practical experiences. - -* Check that the buffer is as large as specified -* 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 -* Check buffer boundaries if calling the function in a loop and make sure there is no danger - of writing past the allocated space -* Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions -* Specifically close resources, do not rely on garbage collection. (for example connection objects, file handles, etc.) -* Properly free allocated memory upon the completion of functions and at all exit points. - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140108] or [edit on GitHub][edit140108]. - -[edit140108]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/01-implementation-dos-donts/08-memory-management.md -[issue140108]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-appendices/01-implementation-dos-donts/08-memory-management diff --git a/docs/en/12-appendices/01-implementation-dos-donts/index.md b/docs/en/12-appendices/01-implementation-dos-donts/index.md deleted file mode 100644 index 3e6a5c81..00000000 --- a/docs/en/12-appendices/01-implementation-dos-donts/index.md +++ /dev/null @@ -1,13 +0,0 @@ -[Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){ align=right width=180 } - -Implementation demands technical knowledge, skill and experience. -There is no substitute for experience, but learning from past mistakes and the experience of others can go a long way. -This section of the Developer Guide is a collection of Do's and Don'ts, -some of which may be directly relevant to any given project and some of which will be less so. -It is worth considering all of these Do's and Don'ts and picking out the ones that will be of most use. - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue0740]. - -[issue0740]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-appendices/01-implementation-dos-donts/00-toc diff --git a/docs/en/12-appendices/02-verification-dos-donts/01-secure-environment.md b/docs/en/12-appendices/02-verification-dos-donts/01-secure-environment.md deleted file mode 100644 index 1f394b00..00000000 --- a/docs/en/12-appendices/02-verification-dos-donts/01-secure-environment.md +++ /dev/null @@ -1,59 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to creating a secure environment, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -* The WEB-INF directory tree contains web application classes, pre-compiled JSP files, server side libraries, - session information, and files such as `web.xml` and `webapp.properties`. - So be sure the code base is identical to production. - Ensuring that we have a “secure code environment” is also an important part of - an application secure code inspection. - -* Use a “deny all” rule to deny access and then grant access on need basis. - -* In Apache HTTP server, ensure directories like WEB-INF and META-INF are protected. - If permissions for a directory and subdirectories are specified in `.htaccess` file, - ensure that it is protected using the “deny all” rule. - -* While using Struts framework, ensure that JSP files are not accessible directly - by denying access to `*.jsp` files in `web.xml`. - -* Maintain a clean environment. remove files that contain source code but are not used by the application. - -* Ensure production environment does not contain any source code / development tools - and that the production environment contains only compiled code / executables. - -* Remove test code / debug code (that might contain backdoors). - Commented code can also be removed as at times, it might contain sensitive data. Remove file metadata e.g., .git - -* Set “Deny All” in security constraints (for the roles being set up) - while setting up the application on the web server. - -* The listing of HTTP methods in security constraints works in a similar way to deny-listing. - Any verb not explicitly listed is allowed for execution. Hence use “Deny All” - and then allow the methods for the required roles. - This setting carries weightage while using “Anonymous User” role. - For example, in Java, remove all `` elements from `web.xml` files. - -* Configure web and application server to disallow HEAD requests entirely. - -* Comments on code and Meta tags pertaining to the IDE used or technology used to develop the application - should be removed. Some comments can divulge important information regarding bugs in code - or pointers to functionality. This is particularly important with server side code such as JSP and ASP files. - -* Search for any calls to the underlying operating system or file open calls and examine the error possibilities. - -* Remove unused dependencies, unnecessary features, components, files, and documentation. - -* Only obtain components from official sources over secure links. - Prefer signed packages to reduce the chance of including a modified, malicious component - -* Monitor for libraries and components that are unmaintained or do not create security patches for older versions. - If patching is not possible, consider deploying a virtual patch to monitor, detect, - or protect against the discovered issue. - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140201] or [edit on GitHub][edit140201]. - -[edit140201]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/02-verification-dos-donts/01-secure-environment.md -[issue140201]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-appendices/02-verification-dos-donts/01-secure-environment diff --git a/docs/en/12-appendices/02-verification-dos-donts/02-system-hardening.md b/docs/en/12-appendices/02-verification-dos-donts/02-system-hardening.md deleted file mode 100644 index 1431ecde..00000000 --- a/docs/en/12-appendices/02-verification-dos-donts/02-system-hardening.md +++ /dev/null @@ -1,65 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to system hardening, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -* The WEB-INF directory tree contains web application classes, pre-compiled files, server side libraries, - session information, and files such as `web.xml` and `webapp.properties`. Secure these files - -* In Apache HTTP server, ensure directories like WEB-INF and META-INF are protected. - If permissions for a directory and subdirectories are specified in `.htaccess` file, - ensure that it is protected using the “deny all” rule. - -* While using Struts framework, ensure that JSP files are not accessible directly - by denying access to `.jsp` files in `web.xml`. - -* Maintain a clean environment. Remove files that contain source code but are not used by the application. - Remove unused dependencies, unnecessary features, components, files, and documentation. - -* Ensure production environment does not contain any source code / development tools - and that the production environment contains only compiled code / executables. - -* Remove test code / debug code (that might contain backdoors). - Commented code can also be removed as at times it might contain sensitive data. - Remove file metadata (e.g. `.git`) - -* Set “Deny All” in security constraints (for the roles being set up) - while setting up the application on the web server. - -* The listing of HTTP methods in security constraints works in a similar way to deny-listing. - Any verb not explicitly listed is allowed for execution. - Hence use “Deny All” and then allow the methods for the required roles. - This setting is particularly important using “Anonymous User” role. - For example, in Java, remove all `` elements from `web.xml` files. - -* 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 - -* Configure web and application server to disallow HEAD requests entirely. - -* Comments on code and Meta tags pertaining to the IDE used or technology used to develop the application - should be removed. - -* Some comments can divulge important information regarding bugs in code or pointers to functionality. - This is particularly important with server side code such as JSP and ASP files. - -* Search for any calls to the underlying operating system or file open calls and examine the error possibilities. - -* Only obtain components from official sources over secure links. - Prefer signed packages to reduce the chance of including a modified, malicious component - -* Monitor for libraries and components that are unmaintained or do not create security patches for older versions. - If patching is not possible, consider deploying a virtual patch to monitor, detect, - or protect against the discovered issue. - -* Remove backup or old files that are not in use - -* Change/disable all default account passwords - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140202] or [edit on GitHub][edit140202]. - -[edit140202]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/02-verification-dos-donts/02-system-hardening.md -[issue140202]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-appendices/02-verification-dos-donts/02-system-hardening diff --git a/docs/en/12-appendices/02-verification-dos-donts/03-open-source-software.md b/docs/en/12-appendices/02-verification-dos-donts/03-open-source-software.md deleted file mode 100644 index 8eeba498..00000000 --- a/docs/en/12-appendices/02-verification-dos-donts/03-open-source-software.md +++ /dev/null @@ -1,101 +0,0 @@ -Here is a collection of Do's and Don'ts when it comes to Open Source software, gathered from practical experiences. -Some of these are language specific and others have more general applicability. - -* Static Code Analysis (for licensing and dependencies) - * Consuming open source software has a heavy dependency on the license - under which the open source software is available. - * Following are some URLs to licensing details: - * `https://choosealicense.com/licenses/` - * `https://tldrlegal.com/` - * `https://creativecommons.org/licenses/by/4.0/` - -It is important for the organization to have a policy statement for consumption of open source software. -From a licensing perspective and the implication of using a open source software incorrectly, -maintain a procedure for approval of usage of selected open source software. -This could be in the form of a workflow or obtaining security approvals for the chosen open source software -We realize it could be challenging, but if feasible, maintain a list of approved open source software - -* Address vulnerabilities with: Binaries / pre-compiled code / packages - where source code sharing is not a part of the license (Examples executables / NuGets) - * Where possible use version pinning - * Where possible use integrity verification - * Check for vulnerabilities for the selected binaries in vulnerability disclosure databases like - * CVE database (`https://www.cve.org/CVERecord/SearchResults?query=bouncy+castle`) - * VulnDB (`https://vuldb.com/?id.173918`) - * If within the budget of your organization, use an SCA tool to scan for vulnerabilities - * Always vet and perform due-diligence on third-party modules that you install - in order to confirm their health and credibility. - * Hold-off on upgrading immediately to new versions; allow new package versions some time to circulate - before trying them out. - * Before upgrading, make sure to review change log and release notes for the upgraded version. - * When installing packages make sure to add the --ignore-scripts suffix to disable the execution - of any scripts by third-party packages. - * Consider adding ignore-scripts to your `.npmrc` project file, or to your global npm configuration. - * If you use npm, run `npm outdated`, to see which packages are out of date - * Typosquatting is an attack that relies on mistakes made by users, such as typos. - With typosquatting, bad actors could publish malicious modules to the npm registry with names - that look much like existing popular modules.To address this vulnerability verify your packages - before consuming them - -* Address vulnerabilities with: where source code sharing is a part of the license - * GitHub CodeQL / third party tool - * If within the budget of your organization, use an SCA tool to scan for vulnerabilities - -* Security Testing: Binaries / pre-compiled code / packages - where source code sharing is not a part of the license (Examples executables / NuGets) - * Perform Dynamic application analysis - * Perform Pen testing - * Verify which tokens are created for your user or revoke tokens in cases of emergency; - use npm token list or npm token revoke respectively. - -* Security Testing: where source code sharing is a part of the license - * Perform Static code analysis - * Perform Dynamic application analysis - * Perform Pen testing. - -* Third Party Software and Libraries (hive off to OWASP Dependency Tracker) - * Address supply chain risk with: Binaries / pre-compiled code / packages - where source code sharing is not a part of the license (Examples executables / NuGets) - * Use signed binaries / packages - * Reference private feed in your code - * Use controlled scopes - * Lock files - * Avoid publishing secrets to the npm registry (secrets may end up leaking into source control - or even a published package on the public npm registry) - -* Address supply chain risk with: where source code sharing is a part of the license - * [GitHub]Check for dependency graph - * [GitHub]Dependabot alerts - * [GitHub]Commit and tag signatures - -* Monitor Dependencies: Binaries / pre-compiled code / packages - where source code sharing is not a part of the license (Examples executables / NuGets) - * Use dependency graphs - * Enable repeatable package restores using lock files - -* Monitor Dependencies: where source code sharing is a part of the license - * [GitHub]Check for dependency graph - * [GitHub] Secret scanning - -* Maintaining open source software/components: Binaries / pre-compiled code / packages - where source code sharing is not a part of the license - * Monitor for deprecated packages - * Use dependency graphs - * Lock files - * Monitor vulnerabilities with: - * Check for vulnerabilities for the selected binaries in vulnerability disclosure databases like - * CVE database (`https://www.cve.org/CVERecord/SearchResults?query=bouncy+castle`) - * VulnDB (`https://vuldb.com/?id.173918`) - * If within the budget of your organization, use an SCA tool to scan for vulnerabilities - -* Copying source code off public domain (internet) - For example source code that is on a blog or in discussion forums like stacktrace or snippets of example on writeups - *******Don’t do it!!!******* - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing -then [submit an issue][issue140203] or [edit on GitHub][edit140203]. - -[edit140203]: https://github.com/OWASP/DevGuide/blob/main/docs/en/12-appendices/02-verification-dos-donts/03-open-source-software.md -[issue140203]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-appendices/02-verification-dos-donts/03-open-source-software diff --git a/docs/en/12-appendices/02-verification-dos-donts/index.md b/docs/en/12-appendices/02-verification-dos-donts/index.md deleted file mode 100644 index 47812209..00000000 --- a/docs/en/12-appendices/02-verification-dos-donts/index.md +++ /dev/null @@ -1,14 +0,0 @@ -![Developer guide logo](../../../assets/images/dg_logo_bbd.png "OWASP Developer Guide"){ align=right width=180 } - -[Verification][sammv] is one of the business functions described by the [OWASP SAMM][samm]. - -Verification takes skill and knowledge, so it is important to build on the existing experience -contained in these Do's and Dont's. - ----- - -The OWASP Developer Guide is a community effort; if there is something that needs changing then [submit an issue][issue1402]. - -[issue1402]: https://github.com/OWASP/DevGuide/issues/new?labels=enhancement&template=request.md&title=Update:%2012-appendices/02-verification-dos-donts/00-toc -[samm]: https://owaspsamm.org/about/ -[sammv]: https://owaspsamm.org/model/verification/