|
|
| (218 intermediate revisions by 24 users not shown) |
| Line 1: |
Line 1: |
| − | Page is under construction - michael.coates@owasp.org<br>
| + | __NOTOC__ |
| | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> |
| | | | |
| − | = Introduction =
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | == Benefits ==
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html Transport Layer Protection Cheat Sheet] to see the latest version of the cheat sheet. |
| − | | |
| − | *Confidentiality<br>
| |
| − | *Integrity<br>
| |
| − | *Replay Protection<br>
| |
| − | *End Point Authentication
| |
| − | | |
| − | == Architectural Decision ==
| |
| − | | |
| − | An architectual decision must be made to determine the appropriate method of implementing transport layer security. The most common options available to corporations are Virtual Private Networks (VPN) or a SSL/TLS model commonly used for web applications. This decision will be determined by the business needs of the particular system. For example, a VPN connection may be the best design for a partnership between two companies that includes mutual access to a shared server over a variety of protocols. Conversely, a company hosting an application which will be used exclusively over the HTTP protocol by a variety of Internet users would likely be best served by a SSL/TLS model.
| |
| − | | |
| − | For each security model there are several security considerations which must be properly addressed in order to provide effective transport layer security.
| |
| − | | |
| − | = Rules for VPN<br> =
| |
| − | | |
| − | == Deployment Options<br> ==
| |
| − | | |
| − | *IPSEC VPN
| |
| − | *SSL VPN
| |
| − | | |
| − | = Providing Transport Layer Protection with VPN<br> =
| |
| − | | |
| − | === Rule -<br> ===
| |
| − | | |
| − | = Providing Transport Layer Protection with SSL/TLS<br> =
| |
| − | | |
| − | == SSL vs TLS ==
| |
| − | | |
| − | "The differences between this protocol (TLS) and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0).“ RFC 2246<br><br>
| |
| − | | |
| − | For the purposes of this cheat sheet we will refer to the technology genericly as SSL.
| |
| − | | |
| − | == Deployment Options<br> ==
| |
| − | | |
| − | *Server Certificate
| |
| − | *Server Certificate + Client Certificate
| |
| − | | |
| − | == Secure Server Design <br> ==
| |
| − | | |
| − | === Rule - Use SSL for All Login Pages and All Authenticated Pages<br> ===
| |
| − | | |
| − | The login page and all subsequent authented page must be exclusively accessed over HTTPS. The initial login page, referred to as the "login landing page", must be served over SSL. Failure to utilize SSL for the login landing page can enable an attacker to modify where the login form posts the user password. Failure to utilize SSL for internal pages enables an attacker to view the unencrypted session ID and compromise the user's authenticated session.<br>
| |
| − | | |
| − | === Rule - Use SSL on Any Networks (External and Internal) Transmiting Sensitive Data<br> ===
| |
| − | | |
| − | All networks which transmit sensitive data must utilize SSL or an equivalent transport layer security. Sensitive data which is transmitted over an internal, or partner network must also utilize transport layer security. It is not sufficient to claim that access to the internal network is "restricted to employees". Numerous recent compromises have shown that the internal network can be breached by attackers. In these attacks sniffers have been installed to access unencrypted sensitive data sent on the internal network.<br>
| |
| − | | |
| − | === Rule - Do Not Provide Non-SSL Pages for Secure Content<br> ===
| |
| − | | |
| − | All pages which are available over SSL must be not be available over a non-SSL connection. An attacker executing a man in the middle attack may modify a user's request such that the requested URL is no longer HTTPS but instead HTTP. The attacker could then view the data in the unencrypted response.<br>
| |
| − | | |
| − | === Rule - Do Not Perform Redirects from Non-SSL Page to SSL Login Page ===
| |
| − | | |
| − | A common practice is to redirect users that have requested a non-SSL version of the login page to the SSL version (e.g. http://site.com/login goes to https://site.com/login). Unfortunately this practice creates an additional attack vector for the attacker. A man in the middle attack enables the attacker to intercept the redirect response and modify or replace the redirection with a site of the attackers choosing. <br>
| |
| − | | |
| − | Ultimately, this issue is the responsibility of the user since the website cannot prevent the user from initially typing http://site.com/login. However, a responsible website should display a security warning to the user whenever the non-ssl login page is requested. This security warning should urge the user to always type "HTTPS" into the browser or bookmark the secure login page.<br>
| |
| − | | |
| − | === Rule - Do Not Mix SSL and Non-SSL Content ===
| |
| − | | |
| − | A page that is available over SSL must not contain any content that is provided over the unencrypted HTTP. Even if the primary page is available over SSL, an attacker could intercept the non-SSL portion and inject malicious content into the user's page.
| |
| − | | |
| − | === Rule - Use "Secure" Cookie Flag ===
| |
| − | | |
| − | The "Secure" flag must be set for all user cookies. Failure to use the "secure" flag will enable an attacker to perform a sidejacking attack and compromise the user's authenticated session ID.
| |
| − | | |
| − | == Server Certificate & Protocol Configuration ==
| |
| − | | |
| − | === Rule - Use an Appropriate Certificate Authority for the Application's User Base ===
| |
| − | | |
| − | === Rule - Only Support Strong Cryptographic Algorithms<br> ===
| |
| − | | |
| − | === Rule - Only Support Strong Protocols ===
| |
| − | | |
| − | === Rule - Establish a Strong Private Key for the Server ===
| |
| − | | |
| − | === Rule - Use a Certificate That Supports All Available Domain Names<br> ===
| |
| − | | |
| − | == Client Configuration ==
| |
| − | | |
| − | === Rule - Validate the Server's Certificate<br> ===
| |
| − | | |
| − | === Rule - Perform Certificate Revocatoin List Checking<br> ===
| |
| − | | |
| − | === Rule - Ensure the Trusted Root Store Contains Only Trusted Entries<br> ===
| |
| − | | |
| − | === Rule - Deny Connections if Any SSL Related Errors are Encountered<br> ===
| |
| − | | |
| − | == Additional Controls ==
| |
| − | | |
| − | === Extended Validation Certificates<br> ===
| |
| − | | |
| − | === Client Side Certificates ===
| |
| − | | |
| − | === ===
| |
