Difference between revisions of "Top 10 2010-A9-Insufficient Transport Layer Protection"

From OWASP
Jump to: navigation, search
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Top_10_2010:TopTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}  
+
{{Top_10_2010:TopTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A8-Failure to Restrict URL Access|next=A10-Unvalidated Redirects and Forwards}}
  
<center>
+
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
{| style="align:center; text-align:center; border:2px solid #4F81BD; background-color:#F2F2F2; padding=2;"
+
{{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}}
|- style="background-color: #4F81Bd; color: #000000;"
+
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}
! Threat Agents !! Attack Vectors
+
{{Top_10_2010:SummaryTableValue-1-Template|Detectability|EASY}}
! colspan="2" | Security Weakness
+
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}
! Technical Impact
+
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
! Business Impacts
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
|-  
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
| style="background-color: #D9D9D9; color: #000000;" | ______
+
    <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used.<br/><br/>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.</td>
| style="background-color: #FFFF00; color: #000000;" | Exploitability<br>DIFFICULT
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
| style="background-color: #FFB200; color: #000000;" | Prevalence<br>COMMON
+
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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.</td>
| style="background-color: #FF0000; color: #000000;" | Detectability<br>EASY
+
{{Top_10_2010:SummaryTableEndTemplate}}
| style="background-color: #FFB200; color: #000000;" | Impact<br>MODERATE
+
| style="background-color: #D9D9D9; color: #000000;" | ______
+
|-
+
| 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.
+
| colspan="2" style="text-align: left;border: 2px solid #FFFFFF;" | Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used.
+
  
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:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=9}}
| 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.
+
The best way to find out if an application has sufficient transport layer protection is to verify that:
| 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.
+
|}
+
</center>
+
 
+
{{Top_10_2010:SubsectionVulnerableTemplate|Injection|
+
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.
 
# 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.
 
# 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 33: Line 21:
 
# All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.
 
# 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.
 
# 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}}
 
+
{{Top_10_2010:SubsectionPreventionTemplate|Injection|
+
 
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:
 
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.
 
# Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.
Line 42: Line 28:
 
# Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
 
# 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.
 
# 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}}
 
+
{{Top_10_2010:SubsectionExampleTemplate|Injection|}}
+
 
<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.
 
<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 50: Line 34:
  
 
<u>Scenario #3</u>: A site simply uses standard ODBC/JDBC for the database connection, not realizing all traffic is in the clear.
 
<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:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=9}}
 +
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
  
{{Top_10_2010:SubsectionReferencesTemplate|Injection}}
+
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)].
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
+
* [[Transport_Layer_Protection_Cheat_Sheet | OWASP Transport Layer Protection Cheat Sheet]]
For a more complete set of requirements and problems to avoid in this area, see the [http://www.owasp.org/index.php/ASVS#tab=Download ASVS requirements on Communications Security (V10)]
+
* [[Top_10_2007-Insecure_Communications | OWASP Top 10-2007 on Insecure Communications]]
* [http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet OWASP Transport Layer Protection Cheat Sheet]
+
* [http://www.owasp.org/index.php/Top_10_2007-Insecure_Communications OWASP Top 10-2007 on Insecure Communications]
+
 
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
 
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
* [http://www.owasp.org/index.php/Testing_for_SSL-TLS OWASP Testing Guide: Chapter on SSL/TLS Testing]
+
* [[Testing_for_SSL-TLS | OWASP Testing Guide: Chapter on SSL/TLS Testing]]
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
 
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
 
* [http://cwe.mitre.org/data/definitions/319.html CWE Entry 319 on Cleartext Transmission of Sensitive Information]
 
* [http://cwe.mitre.org/data/definitions/319.html CWE Entry 319 on Cleartext Transmission of Sensitive Information]
 
* [https://www.ssllabs.com/ssldb/index.html SSL Labs Server Test]
 
* [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]
 
* [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]]
<br> {{Top_10_2010:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}
+
 
+
{{Top_10_2010:ToDoTemplate|Spanish translation should be verified by someone who actually knows Spanish}}
+

Latest revision as of 13:32, 16 October 2010

← A8-Failure to Restrict URL Access
Top 10 Introduction
Top 10 Risks
A10-Unvalidated Redirects and Forwards →
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
DIFFICULT
Prevalence
COMMON
Detectability
EASY
Impact
MODERATE
Application / Business Specific
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. 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. Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used.

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.
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. 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.
Am I Vulnerable To 'Insufficient Transport Layer Protection'?

The best way to find out if an application has sufficient transport layer protection is to verify that:

  1. SSL is used to protect all authentication related traffic.
  2. 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.
  3. Only strong algorithms are supported.
  4. All session cookies have their ‘secure’ flag set so the browser never transmits them in the clear.
  5. 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.
How Do I Prevent 'Insufficient Transport Layer Protection'?

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:

  1. Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.
  2. Set the ‘secure’ flag on all sensitive cookies.
  3. Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.
  4. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
  5. Backend and other connections should also use SSL or other encryption technologies.
Example Attack Scenarios

Scenario #1: 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.

Scenario #2: A site has improperly configured SSL certificate which causes browser warnings for its users. Users have to accept such warnings and continue, in order to use the site. This causes users to get accustomed to such warnings. Phishing attack against the site’s customers lures them to a lookalike site which doesn’t have a valid certificate, which generates similar browser warnings. Since victims are accustomed to such warnings, they proceed on and use the phishing site, giving away passwords or other private data.

Scenario #3: A site simply uses standard ODBC/JDBC for the database connection, not realizing all traffic is in the clear.

References

OWASP

For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Communications Security (V10).

External

← A8-Failure to Restrict URL Access
Top 10 Introduction
Top 10 Risks
A10-Unvalidated Redirects and Forwards →

© 2002-2010 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png