Top 10 2010-A9-Insufficient Transport Layer Protection - Revision history

Wichers at 18:32, 16 October 2010

2010-10-16T18:32:55Z

Wichers at 03:32, 6 May 2010

2010-05-06T03:32:14Z

Neil Smithline at 15:19, 1 May 2010

2010-05-01T15:19:48Z

Neil Smithline at 01:07, 29 April 2010

2010-04-29T01:07:10Z

Neil Smithline at 22:01, 23 April 2010

2010-04-23T22:01:52Z

Wichers at 17:39, 22 April 2010

2010-04-22T17:39:30Z

Wichers at 16:32, 22 April 2010

2010-04-22T16:32:14Z

Neil Smithline at 20:15, 21 April 2010

2010-04-21T20:15:44Z

Neil Smithline at 20:11, 21 April 2010

2010-04-21T20:11:44Z

Neil Smithline: moved Top 10 2010-A9 to Top 10 2010-A9-Insufficient Transport Layer Protection

2010-04-21T15:28:05Z

moved Top 10 2010-A9 to Top 10 2010-A9-Insufficient Transport Layer Protection

@@ Line 15: / Line 15: @@
 {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=9}}
-The best way to find out if an application has insufficient transport layer protection is to verify that:
+The best way to find out if an application has sufficient transport layer protection is to verify that:
 # SSL is used to protect all authentication related traffic.
 # SSL is used for all resources on all private pages and services. This protects all data and session tokens that are exchanged. Mixed SSL on a page should be avoided since it causes user warnings in the browser, and may expose the user’s session ID.

@@ Line 36: / Line 36: @@
 {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=9}}
 {{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 For a more complete set of requirements and problems to avoid in this area, see the [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS requirements on Communications Security (V10)]
 * [[Transport_Layer_Protection_Cheat_Sheet | OWASP Transport Layer Protection Cheat Sheet]]
 * [[Top_10_2007-Insecure_Communications | OWASP Top 10-2007 on Insecure Communications]]

@@ Line 1: / Line 1: @@
 {{Top_10_2010:TopTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A8-Failure to Restrict URL Access|next=A10-Unvalidated Redirects and Forwards}}
-Detecting basic flaws is easy. Just observe the site’s network traffic. More subtle flaws require inspecting the design of the application and the server configuration.
+{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
-| style="text-align: left; border: 2px solid #FFFFFF;" | Such flaws expose individual users’ data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.
+{{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}}
-| style="text-align: left; border: 2px solid #FFFFFF;" | Consider the business value of the data exposed on the communications channel in terms of its confidentiality and integrity needs, and the need to authenticate both participants.
+{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
-|}
+{{Top_10_2010:SummaryTableValue-1-Template|Detectability|EASY}}
-</center>
+{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}
 {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=9}}
 The best way to find out if an application has insufficient transport layer protection is to verify that:

@@ Line 25: / Line 25: @@
 |}
 </center>
-{{Top_10_2010:SubsectionVulnerableTemplate|Insufficient Transport Layer Protection|
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=9}}
 The best way to find out if an application has insufficient transport layer protection is to verify that:
 # SSL is used to protect all authentication related traffic.
@@ Line 32: / Line 32: @@
 # All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.
 # The server certificate is legitimate and properly configured for that server. This includes being issued by an authorized issuer, not expired, has not been revoked, and it matches all domains the site uses.
-}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=9}}
 Providing proper transport layer protection can affect the site design. It’s easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private pages. Others use SSL only on ‘critical’ pages, but this can expose session IDs and other sensitive data. At a minimum, do all of the following:
 # Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.
@@ Line 40: / Line 39: @@
 # Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
 # Backend and other connections should also use SSL or other encryption technologies.
-}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=9}}
 <u>Scenario #1</u>: A site simply doesn’t use SSL for all pages that require authentication. Attacker simply monitors network traffic (like an open wireless or their neighborhood cable modem network), and observes an authenticated victim’s session cookie. Attacker then replays this cookie and takes over the user’s session.
@@ Line 47: / Line 45: @@
 <u>Scenario #3</u>: A site simply uses standard ODBC/JDBC for the database connection, not realizing all traffic is in the clear.
-{{Top_10_2010:SubsectionReferencesTemplate|Insufficient Transport Layer Protection}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=9}}
 {{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
 For a more complete set of requirements and problems to avoid in this area, see the [http://www.owasp.org/index.php/ASVS#tab=Downloads ASVS requirements on Communications Security (V10)]
@@ Line 58: / Line 56: @@
 * [https://www.ssllabs.com/ssldb/index.html SSL Labs Server Test]
 * [http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf Definition of FIPS 140-2 Cryptographic Standard]
+{{Top_10_2010:BottomAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|useprev=2010PrevLink|usenext=2010NextLink|prev=A8-Failure to Restrict URL Access|next=A10-Unvalidated Redirects and Forwards}}
 [[Category:OWASP Top Ten Project]]

@@ Line 3: / Line 3: @@
 {| style="align:center; text-align:center; border:2px solid #4F81BD; background-color:#F2F2F2; padding=2;"
 |- style="background-color: #4F81Bd; color: #FFFFFF;"
-! Threat Agents !! Attack Vectors
+! width="16.5%" | Threat Agents
-! colspan="2" | Security Weakness
+! width="16.5%" | Attack Vectors
-! Technical Impacts
+! width="33%" colspan="2" | Security Weakness
-! Business Impacts
+! width="16.5%" | Technical Impacts
 |-
 | style="background-color: #D9D9D9; color: #000000;" | ______
@@ Line 14: / Line 15: @@
 | style="background-color: #FFB200; color: #000000;" | '''Impact<br>MODERATE
 | style="background-color: #D9D9D9; color: #000000;" | ______
-|-
+|-valign="top"
 | style="text-align: left; border: 2px solid #FFFFFF;" | Consider anyone who can monitor the network traffic of your users. If the application is on the internet, who knows how your users access it. Don’t forget back end connections.
 | style="text-align: left; border: 2px solid #FFFFFF;" | Monitoring users’ network traffic can be difficult, but is sometimes easy. The primary difficulty lies in monitoring the proper network’s traffic while users are accessing the vulnerable site.

← Older revision	Revision as of 15:28, 21 April 2010
(No difference)