https://wiki.owasp.org/api.php?action=feedcontributions&user=Simone+onofri&feedformat=atomOWASP - User contributions [en]2024-03-29T06:26:56ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=OWASP_Testing_Guide_v4_Table_of_Contents&diff=164269OWASP Testing Guide v4 Table of Contents2013-12-04T00:19:33Z<p>Simone onofri: </p>
<hr />
<div>{{OWASP Breakers}}<br />
__NOTOC__<br />
<br />
'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br><br />
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br><br />
<br />
Back to the OWASP Testing Guide Project:<br />
http://www.owasp.org/index.php/OWASP_Testing_Project<br />
<br />
'''Updated: 15th February 2013'''<br />
<br />
[[ OWTGv4 Contributors list|'''Contributors List]]<br />
<br />
----<br />
<br />
<br />
The following is a DRAFT of the Toc based on the feedback already received.<br />
<br />
== Table of Contents ==<br />
<br />
==[[Testing Guide Foreword|Foreword by Eoin Keary]]== <br />
[To review--> Eoin Keary -> Done!!]<br />
<br />
==[[Testing Guide Frontispiece |1. Frontispiece]]== <br />
[To review--> Mat]<br />
<br />
'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]''' <br />
[To review--> Mat]<br />
<br />
'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]''' <br />
[To review--> ]<br />
<br />
<br />
==[[Testing Guide Introduction|2. Introduction]]==<br />
<br />
'''2.1 The OWASP Testing Project'''<br />
<br />
'''2.2 Principles of Testing'''<br />
<br />
'''2.3 Testing Techniques Explained''' <br />
<br />
2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]<br />
<br />
2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]<br />
<br />
==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==<br />
<br />
'''3.1. Overview'''<br />
<br />
'''3.2. Phase 1: Before Development Begins '''<br />
<br />
'''3.3. Phase 2: During Definition and Design'''<br />
<br />
'''3.4. Phase 3: During Development'''<br />
<br />
'''3.5. Phase 4: During Deployment'''<br />
<br />
'''3.6. Phase 5: Maintenance and Operations'''<br />
<br />
'''3.7. A Typical SDLC Testing Workflow '''<br />
<br />
==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==<br />
<br />
[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]<br />
<br />
[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]<br />
<br />
<br />
[[Testing Information Gathering|'''4.2 Information Gathering ''']]<br />
<br />
[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"<br />
<br />
[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"<br />
<br />
[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"<br />
<br />
[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"<br />
<br />
[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"<br />
<br />
[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"<br />
<br />
[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"<br />
<br />
[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"<br />
<br />
[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''<br />
<br />
<br />
[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
<br />
[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]<br />
<br />
[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"<br />
<br />
[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"<br />
<br />
[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"<br />
<br />
[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"<br />
<br />
[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"<br />
<br />
[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"<br />
<br />
[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"<br />
<br />
[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]<br />
<br />
[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"<br />
<br />
[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new<br />
<br />
<br />
[[Testing Identity Management|'''4.4 Identity Management Testing''']]<br />
<br />
[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New<br />
<br />
[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New<br />
<br />
[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New<br />
<br />
[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"<br />
<br />
[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)<br />
<br />
[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New<br />
<br />
[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New<br />
<br />
[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New<br />
<br />
[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New<br />
<br />
<br />
<br />
[[Testing for authentication|'''4.5 Authentication Testing ''']] <br />
<br />
[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"<br />
<br />
[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"<br />
<br />
[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"<br />
<br />
[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"<br />
<br />
[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"<br />
<br />
[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"<br />
<br />
[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"<br />
<br />
[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel<br />
<br />
[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"<br />
<br />
[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)<br />
<br />
<br />
[[Testing for Authorization|'''4.6 Authorization Testing''']] <br />
<br />
[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New<br />
<br />
[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"<br />
<br />
[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"<br />
<br />
[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"<br />
<br />
[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"<br />
<br />
[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"<br />
<br />
[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)<br />
<br />
[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)<br />
<br />
[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"<br />
<br />
<br />
[[Testing for Session Management|'''4.7 Session Management Testing''']]<br />
<br />
[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"<br />
<br />
[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)<br />
<br />
[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"<br />
<br />
[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"<br />
<br />
[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"<br />
<br />
[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]<br />
<br />
[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"<br />
<br />
[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]<br />
<br />
[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]<br />
<br />
[[Testing for Session puzzling (OTG-SESS-010)|4.7.10 Testing for Session puzzling (OTG-SESS-010)]]<br />
<br />
<br />
[[Testing for Data Validation|'''4.8 Data Validation Testing''']] <br />
<br />
[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"<br />
<br />
[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"<br />
<br />
[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"<br />
<br />
[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"<br />
<br />
[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"<br />
<br />
[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''<br />
<br />
[[Testing for Oracle|4.8.6.1 Oracle Testing]]<br />
<br />
[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]<br />
<br />
[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]<br />
<br />
[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]<br />
<br />
[[Testing for MS Access |4.8.6.5 MS Access Testing]]<br />
<br />
[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]<br />
<br />
[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"<br />
<br />
[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"<br />
<br />
[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"<br />
<br />
[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"<br />
<br />
[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"<br />
<br />
[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"<br />
<br />
[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"<br />
<br />
[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]] [Alexander Antukh]<br />
<br />
[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]] [Alexander Antukh]<br />
<br />
[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"<br />
<br />
[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"<br />
<br />
[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]<br />
<br />
[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]<br />
<br />
[[Testing for Format String|4.8.15.3 Testing for Format string]]<br />
<br />
[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"<br />
<br />
[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" [Juan Galiana]<br />
<br />
<br />
<br />
[[Error Handling|'''4.9 Error Handling''']]<br />
<br />
[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"<br />
<br />
[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"<br />
<br />
<br />
[[Cryptography|'''4.10 Cryptography''']]<br />
<br />
[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"<br />
<br />
[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" [Simone Onofri]<br />
<br />
[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"<br />
<br />
[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]<br />
<br />
[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]<br />
<br />
[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]<br />
<br />
[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]] [Simone Onofri]<br />
<br />
[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]<br />
<br />
<br />
[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test<br />
<br />
[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"<br />
<br />
[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]<br />
<br />
<br />
[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]<br />
Business Logic<br><br />
<br />
[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]] <br />
<br />
[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]] <br />
<br />
XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]<br />
<br />
[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates) <br />
<br />
XXXX[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.5 Test tamper evidence (OTG-BUSLOGIC-005)]] [New!] - [Combine with test Integrity Checks as an example]<br />
<br />
[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]<br />
<br />
[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]] <br />
<br />
XXXX[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.10 Test bypass of correct sequence (OTG-BUSLOGIC-010)]] [New!]- [Combine with Testing for the Circumvention of Work Flows as an example]<br />
<br />
[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]] <br />
<br />
[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]] <br />
<br />
[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]] <br />
<br />
[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]] <br />
<br />
<br />
<br />
[[Denial of Service|'''4.13 Denial of Service''']]<br />
<br />
[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br><br />
<br />
[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]<br />
<br />
[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)" <br />
<br />
[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]<br />
<br />
[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]<br />
<br />
<br />
<br />
[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston] <br />
<br />
[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"<br />
<br />
[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"<br />
<br />
[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"<br />
<br />
[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"<br />
<br />
[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"<br />
<br />
[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"<br />
<br />
[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"<br />
<br />
[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"<br />
<br />
[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"<br />
<br />
[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"<br />
<br />
<br />
[[Client Side Testing|'''4.15 Client Side Testing''']] [New!] <br />
<br />
[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]<br />
<br />
[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.15.2 Test Cross Origin Resource Sharing (OTG-CLIENT-002)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]<br />
<br />
[[Testing for Cross site flashing (OWASP-DV-004)|4.15.3 Testing for Cross Site Flashing (OTG-CLIENT-003)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"<br />
<br />
[[Testing for Clickjacking (OWASP-CS-004)|4.15.4 Testing for Clickjacking (OTG-CLIENT-004)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]<br />
<br />
[[Testing WebSockets (OTG-CLIENT-005)|4.15.5 Testing WebSockets (OTG-CLIENT-005)]] [Ryan Dewhurst]<br />
<br />
[[Test Web Messaging (OTG-CLIENT-006)|4.15.6 Test Web Messaging (OTG-CLIENT-006)]] [Juan Galiana]<br />
<br />
[[Test Local Storage (OTG-CLIENT-007)|4.15.7 Test Local Storage (OTG-CLIENT-007)]] [Juan Galiana]<br />
<br />
==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]== <br />
<br />
[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==<br />
<br />
* Black Box Testing Tools [To review--> Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==<br />
* Whitepapers [To review--> David Fern]<br />
* Books [To review--> David Fern]<br />
* Useful Websites [To review--> David Fern]<br />
<br />
==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]== <br />
<br />
* Fuzz Categories [To review--> Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
<br />
==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]== <br />
[To review--> Amro AlOlaqi] '''Ready to be reviewed'''<br />
<br />
----<br />
<br />
<br />
[[Category:OWASP Testing Project]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&diff=164268Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)2013-12-04T00:18:10Z<p>Simone onofri: </p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanist must have not limitations and vulnerabilities, as explained in the broader article "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection" [1] and in other OWASP documentation [2], [3], [4], [5].In fact consider adding a security control or safeguard is an addition to the attack surface.<br />
However a specific test is needed to ensure if the control is missing and sensitive data is transmitted via unencrypted channel. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission. Such as:<br />
* Information used in Authentication (e.g. Credentials, PINs, Session Ids, Tokens, Cookies…)<br />
* Information protected by Laws, Regulations or specific Organization’s Policy (e.g. Credit Cards, Customers data) <br />
<br />
== Description of the Issue ==<br />
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
== Black Box testing and example ==<br />
Various typologies of information, which must be protected, can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS.<br />
Please refer to specific Tests for full details, for credentials [3] and other kind of data [2].<br />
<br />
=== Example 1. Basic Authentication over HTTP ===<br />
A typical example is the usage of Basic Authentication over HTTP. Also, with Basic Autentication credentials are encoded and not encrypted into HTTP Headers, using curl [5].<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/ <br />
HTTP/1.1 401 Authorization Required <br />
Date: Fri, 01 Aug 2013 00:00:00 GMT <br />
WWW-Authenticate: Basic realm="Restricted Area" <br />
Accept-Ranges: bytes Vary: <br />
Accept-Encoding Content-Length: 162 <br />
Content-Type: text/html <br />
<br />
<html><head><title>401 Authorization Required</title></head> <br />
<body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login credentials! </body></html><br />
</pre><br />
<br />
=== Example 2. Form Authentication over HTTP ===<br />
Another typical example is forms containing passwords transmitted over HTTP. It is possible to find the “http://” or “//” as the protocol in “action” attribute of the form and some input containing passwords or other data.<br />
<br />
<pre><br />
<form action="http://example.com/login"><br />
<label for="username">User:</label> <input type="text" id="username" name="username" value=""/><br /><br />
<label for="password">Password:</label> <input type="password" id="password" name="password" value=""/><br />
<input type="submit" value="Login"/><br />
</form><br />
</pre><br />
<br />
=== Example 3. Cookie containing Session ID over HTTP ===<br />
Session ID Cookie must be transmitted over protected channels. If Cookie have NOT Secure flag [6] it is possible to transmit unencrypted. In this case it can be eavesdropped.<br />
<br />
<pre><br />
https://secure.example.com/login<br />
<br />
POST /login HTTP/1.1<br />
Host: secure.example.com<br />
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0<br />
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br />
Accept-Language: en-US,en;q=0.5<br />
Accept-Encoding: gzip, deflate<br />
Referer: https://secure.example.com/<br />
Content-Type: application/x-www-form-urlencoded<br />
Content-Length: 188<br />
<br />
HTTP/1.1 302 Found<br />
Date: Tue, 03 Dec 2013 21:18:55 GMT<br />
Server: Apache<br />
Cache-Control: no-store, no-cache, must-revalidate, max-age=0<br />
Expires: Thu, 01 Jan 1970 00:00:00 GMT<br />
Pragma: no-cache<br />
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com; httponly<br />
Location: private/<br />
X-Content-Type-Options: nosniff<br />
X-XSS-Protection: 1; mode=block<br />
X-Frame-Options: SAMEORIGIN<br />
Content-Length: 0<br />
Keep-Alive: timeout=1, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html<br />
<br />
----------------------------------------------------------<br />
http://example.com/private<br />
<br />
GET /private HTTP/1.1<br />
Host: example.com<br />
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0<br />
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br />
Accept-Language: en-US,en;q=0.5<br />
Accept-Encoding: gzip, deflate<br />
Referer: https://secure.example.com/login<br />
Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;<br />
Connection: keep-alive<br />
<br />
HTTP/1.1 200 OK<br />
Cache-Control: no-store<br />
Pragma: no-cache<br />
Expires: 0<br />
Content-Type: text/html;charset=UTF-8<br />
Content-Length: 730<br />
Date: Tue, 25 Dec 2013 00:00:00 GMT<br />
----------------------------------------------------------<br />
</pre><br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [1] [https://www.owasp.org/index.php?title=Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002 OWASP Testing Guide - Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-CRYPST-002)]<br />
* [2] [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection OWASP TOP 10 2010 - Insufficient Transport Layer Protection]<br />
* [3] [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure OWASP TOP 10 2013 - Sensitive Data Exposure]<br />
* [4] [https://code.google.com/p/owasp-asvs/wiki/Verification_V10 OWASP ASVS v1.1 - V10 Communication Security Verification Requirements]<br />
* [6] [https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002) OWASP Testing Guide - Testing for Cookies attributes (OTG-SESS-002)]<br />
'''Tools'''<br />
* [5] [http://curl.haxx.se/ curl] can be used to check manually for pages</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-003)&diff=164266Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-003)2013-12-04T00:11:55Z<p>Simone onofri: Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or enc..."</p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
Sensitive data must be protected when it is transmitted through the network. If data is transmitted over HTTPS or encrypted in another way the protection mechanist must have not limitations and vulnerabilities, as explained in the broader article "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection" [1] and in other OWASP documentation [2], [3], [4], [5].In fact consider adding a security control or safeguard is an addition to the attack surface.<br />
However a specific test is needed to ensure if the control is missing and sensitive data is transmitted via unencrypted channel. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission. Such as:<br />
* Information used in Authentication (e.g. Credentials, PINs, Session Ids, Tokens, Cookies…)<br />
* Information protected by Laws, Regulations or specific Organization’s Policy (e.g. Credit Cards, Customers data) <br />
<br />
== Description of the Issue ==<br />
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
== Black Box testing and example ==<br />
Various typologies of information, which must be protected, can be also transmitted in clear text. It is possible to check if this information is transmitted over HTTP instead of HTTPS.<br />
Please refer to specific Tests for full details, for credentials [3] and other kind of data [2].<br />
<br />
=== Example 1. Basic Authentication over HTTP ===<br />
A typical example is the usage of Basic Authentication over HTTP. Also, with Basic Autentication credentials are encoded and not encrypted into HTTP Headers, using curl [5].<br />
<br />
<pre><br />
$ curl -kis http://example.com/restricted/ <br />
HTTP/1.1 401 Authorization Required <br />
Date: Fri, 01 Aug 2013 00:00:00 GMT <br />
WWW-Authenticate: Basic realm="Restricted Area" <br />
Accept-Ranges: bytes Vary: <br />
Accept-Encoding Content-Length: 162 <br />
Content-Type: text/html <br />
<br />
<html><head><title>401 Authorization Required</title></head> <br />
<body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login credentials! </body></html><br />
</pre><br />
<br />
=== Example 2. Form Authentication over HTTP ===<br />
Another typical example is forms containing passwords transmitted over HTTP. It is possible to find the “http://” or “//” as the protocol in “action” attribute of the form and some input containing passwords or other data.<br />
<br />
<pre><br />
<form action="http://example.com/login"><br />
<label for="username">User:</label> <input type="text" id="username" name="username" value=""/><br /><br />
<label for="password">Password:</label> <input type="password" id="password" name="password" value=""/><br />
<input type="submit" value="Login"/><br />
</form><br />
</pre><br />
<br />
=== Example 3. Cookie containing Session ID over HTTP ===<br />
Session ID Cookie must be transmitted over protected channels. If Cookie have NOT Secure flag it is possible to transmit unencrypted. In this case it can be eavesdropped.<br />
<br />
<pre><br />
https://secure.example.com/login<br />
<br />
POST /login HTTP/1.1<br />
Host: secure.example.com<br />
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0<br />
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br />
Accept-Language: en-US,en;q=0.5<br />
Accept-Encoding: gzip, deflate<br />
Referer: https://secure.example.com/<br />
Content-Type: application/x-www-form-urlencoded<br />
Content-Length: 188<br />
<br />
HTTP/1.1 302 Found<br />
Date: Tue, 03 Dec 2013 21:18:55 GMT<br />
Server: Apache<br />
Cache-Control: no-store, no-cache, must-revalidate, max-age=0<br />
Expires: Thu, 01 Jan 1970 00:00:00 GMT<br />
Pragma: no-cache<br />
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com; httponly<br />
Location: private/<br />
X-Content-Type-Options: nosniff<br />
X-XSS-Protection: 1; mode=block<br />
X-Frame-Options: SAMEORIGIN<br />
Content-Length: 0<br />
Keep-Alive: timeout=1, max=100<br />
Connection: Keep-Alive<br />
Content-Type: text/html<br />
<br />
----------------------------------------------------------<br />
http://example.com/private<br />
<br />
GET /private HTTP/1.1<br />
Host: example.com<br />
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0<br />
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br />
Accept-Language: en-US,en;q=0.5<br />
Accept-Encoding: gzip, deflate<br />
Referer: https://secure.example.com/login<br />
Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;<br />
Connection: keep-alive<br />
<br />
HTTP/1.1 200 OK<br />
Cache-Control: no-store<br />
Pragma: no-cache<br />
Expires: 0<br />
Content-Type: text/html;charset=UTF-8<br />
Content-Length: 730<br />
Date: Tue, 25 Dec 2013 00:00:00 GMT<br />
----------------------------------------------------------<br />
</pre><br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [1] [https://www.owasp.org/index.php?title=Testing_for_Weak_SSL/TSL_Ciphers,_Insufficient_Transport_Layer_Protection_(OWASP-EN-002 OWASP Testing Guide - Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-CRYPST-002)]<br />
* [2] [https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection OWASP TOP 10 2010 - Insufficient Transport Layer Protection]<br />
* [3] [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure OWASP TOP 10 2013 - Sensitive Data Exposure]<br />
* [4] [https://code.google.com/p/owasp-asvs/wiki/Verification_V10 OWASP ASVS v1.1 - V10 Communication Security Verification Requirements]<br />
<br />
'''Tools'''<br />
* [5] [http://curl.haxx.se/ curl] can be used to check manually for pages</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=164203Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2013-12-03T17:13:59Z<p>Simone onofri: </p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
Sensitive data must be protected when it is transmitted through the network. These data includes credentials and credit cards. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. Use of these protocols ensure not only confidentiality but also authentication. Servers are authenticated using digital certificates, and it is also possibile to use client certificate for mutual authentication. <br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
== Description of the Issue == <br />
If control is missed and HTTP protocol is used to transmit sensitive information is a vulnerability [2] (e.g. credentials transmitted over HTTP [3]) and there are a specific OWASP Testing Guide v4’s test.<br />
<br />
If SSL/TLS service is present it is good but it increments the attack surface and some vulnerabilities insist on it, such as:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
Other vulnerabilities linked to this is:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTP and HTTP content in the same page, which can be used to Leak information.<br />
<br />
===Sensitive data transmitted in clear-text===<br />
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
===Weak SSL/TSL Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control, for example, whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates, like follow:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this Guide, we will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
Let is examine each check more in detail. <br />
<br />
* Each browser comes with a preloaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as Infrastructure vulnerability if software is not up to date [4]. Futhermore for a correct protection of data during transmission Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
Also there are some attacks can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
== Black Box testing and example ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various typologies of information which must be protected can be also transmitted in clear text. It is possible to check if these information is transmitted over HTTP instead of HTTPS.<br />
<br />
Please refer to specific Tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Authentication over HTTP. Also because with Basic Authentication, after login, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
===Testing for Weak SSL/TSL Ciphers/Protocols/Keys vulnerabilities===<br />
Large number of available cipher suites and quick progress in cryptanalysis makes judging a SSL server a non-trivial task. At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
A most complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks, but it is ok the use with at least 128 bit key.<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
Following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
Some tools and scanners both commercial - e.g. Tenable Nessus [27] - and free - e.g. SSLAudit [28] or SSLScan [29], and other used into examples - can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way is also to check them manually with openssl [30] or using tool’s output as an input for manual evaluation using the references on the bottom on the Test to stay updated.<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
First step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
In this example we search for SSL services using nmap with “-sV” option, used for identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
openssl [30] can be used for testing manually SSL/TLS. In this example we try to initiate a renegotiation by client [m] connecting to server with openssl - writing the fist line of an HTTP request, in a new line typing “R”, waiting for renegotiaion and completing the HTTP request - and check if secure renegotiaion is supperted looking server output. Using manual request it is also possible to see if Compression is enabled for TLS in order to check for CRIME [13], check for ciphers and other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
Now we can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
And we can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
TestSSLServer [32] is a script which permits to check cipher suite and also BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that sould be disabled. It is really interesting a first fix for BEAST was the usage of RC4, but this is discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
sslyze [33] is a python script which permits also mass scan and XML output. Follows an example of a regular scan. Is one of the most complete and versatile tool for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade your browser because also CA certs expire and, in every release of the browser, these are been renewed.<br />
Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match namewise with the site to which they should refer. By clicking on the padlock which appears in the browser window when visiting an HTTPS site, you can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, you probably have installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
Some tools, as in previous examples, check also for certificate validity.<br />
<br />
====Example 7. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, we have inserted an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. <br />
The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting an .it site and the certificate was issued to a .com site! Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different – Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come preloaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. A part from others discussed in other parts of the Guide, the another one is possible when the server provide the website both with the HTTP and HTTPS protocols, and permit to an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
====Surf Jacking====<br />
Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
The following is a scenario of how the attack can take place:<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later (ab)use.<br />
To test if a website is vulnerable is sufficient to proceed like follow:<br />
# Check if website supports both HTTP and HTTPS protocol<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
====SSL Strip====<br />
Often applications supports both HTTP and HTTPS. As for usability or because users do not use to type “https://www.example.com”. Often users go into an HTTPS website from link or a redirect. Typically also home banking site have a similar configuration with an iframed login or a form with action attribute over HTTPS but the page under HTTP.<br />
An attacker in a privileged position - as described in SSL strip [8] - can incercept traffic when user is into HTTP and manipulate it to get a Man-In-The-Middle attack under HTTPS.<br />
To test if application is vulnerable is sufficient the website supports both HTTP and HTTPS.<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TSL Cipher Suites===<br />
Check the configuration of the web servers which provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
====Example 8. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
which has some sub-keys like Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
====Example 9: Apache====<br />
To check the cipher suites and protocols supported by Apache2 web server open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level; however, there may be additional communication paths protected by SSL (for example, towards the DBMS). You should check the application architecture to identify all SSL protected channels.<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [33] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=164202Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2013-12-03T17:13:10Z<p>Simone onofri: </p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
Sensitive data must be protected when it is transmitted through the network. These data includes credentials and credit cards. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. Use of these protocols ensure not only confidentiality but also authentication. Servers are authenticated using digital certificates, and it is also possibile to use client certificate for mutual authentication. <br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
== Description of the Issue == <br />
If control is missed and HTTP protocol is used to transmit sensitive information is a vulnerability [2] (e.g. credentials transmitted over HTTP [3]) and there are a specific OWASP Testing Guide v4’s test.<br />
<br />
If SSL/TLS service is present it is good but it increments the attack surface and some vulnerabilities insist on it, such as:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
Other vulnerabilities linked to this is:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTP and HTTP content in the same page, which can be used to Leak information.<br />
<br />
===Sensitive data transmitted in clear-text===<br />
If the application transmits sensitive information via unencrypted channels - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
===Weak SSL/TSL Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control, for example, whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates, like follow:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this Guide, we will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
Let is examine each check more in detail. <br />
<br />
* Each browser comes with a preloaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as Infrastructure vulnerability if software is not up to date [4]. Futhermore for a correct protection of data during transmission Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
Also there are some attacks can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
== Black Box testing and example ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various typologies of information which must be protected can be also transmitted in clear text. It is possible to check if these information is transmitted over HTTP instead of HTTPS.<br />
<br />
Please refer to specific Tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Autentication over HTTP. Also because with Basic Autentication, after login, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
===Testing for Weak SSL/TSL Ciphers/Protocols/Keys vulnerabilities===<br />
Large number of available cipher suites and quick progress in cryptanalysis makes judging a SSL server a non-trivial task. At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
A most complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks, but it is ok the use with at least 128 bit key.<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
Following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
Some tools and scanners both commercial - e.g. Tenable Nessus [27] - and free - e.g. SSLAudit [28] or SSLScan [29], and other used into examples - can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way is also to check them manually with openssl [30] or using tool’s output as an input for manual evaluation using the references on the bottom on the Test to stay updated.<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
First step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
In this example we search for SSL services using nmap with “-sV” option, used for identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
openssl [30] can be used for testing manually SSL/TLS. In this example we try to initiate a renegotiation by client [m] connecting to server with openssl - writing the fist line of an HTTP request, in a new line typing “R”, waiting for renegotiaion and completing the HTTP request - and check if secure renegotiaion is supperted looking server output. Using manual request it is also possible to see if Compression is enabled for TLS in order to check for CRIME [13], check for ciphers and other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
Now we can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
And we can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
TestSSLServer [32] is a script which permits to check cipher suite and also BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that sould be disabled. It is really interesting a first fix for BEAST was the usage of RC4, but this is discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
sslyze [33] is a python script which permits also mass scan and XML output. Follows an example of a regular scan. Is one of the most complete and versatile tool for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade your browser because also CA certs expire and, in every release of the browser, these are been renewed.<br />
Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match namewise with the site to which they should refer. By clicking on the padlock which appears in the browser window when visiting an HTTPS site, you can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, you probably have installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
Some tools, as in previous examples, check also for certificate validity.<br />
<br />
====Example 7. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, we have inserted an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. <br />
The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting an .it site and the certificate was issued to a .com site! Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different – Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come preloaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. A part from others discussed in other parts of the Guide, the another one is possible when the server provide the website both with the HTTP and HTTPS protocols, and permit to an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
====Surf Jacking====<br />
Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
The following is a scenario of how the attack can take place:<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later (ab)use.<br />
To test if a website is vulnerable is sufficient to proceed like follow:<br />
# Check if website supports both HTTP and HTTPS protocol<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
====SSL Strip====<br />
Often applications supports both HTTP and HTTPS. As for usability or because users do not use to type “https://www.example.com”. Often users go into an HTTPS website from link or a redirect. Typically also home banking site have a similar configuration with an iframed login or a form with action attribute over HTTPS but the page under HTTP.<br />
An attacker in a privileged position - as described in SSL strip [8] - can incercept traffic when user is into HTTP and manipulate it to get a Man-In-The-Middle attack under HTTPS.<br />
To test if application is vulnerable is sufficient the website supports both HTTP and HTTPS.<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TSL Cipher Suites===<br />
Check the configuration of the web servers which provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
====Example 8. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
which has some sub-keys like Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
====Example 9: Apache====<br />
To check the cipher suites and protocols supported by Apache2 web server open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level; however, there may be additional communication paths protected by SSL (for example, towards the DBMS). You should check the application architecture to identify all SSL protected channels.<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [33] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_(OTG-CRYPST-001)&diff=157287Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)2013-08-24T09:51:19Z<p>Simone onofri: </p>
<hr />
<div>{{Template:OWASP Testing Guide v4}}<br />
<br />
<br />
== Brief Summary ==<br />
Sensitive data must be protected when it is transmitted through the network. These data includes credentials and credit cards. As a rule of thumb if data must be protected when it is stored, it must be protected also during transmission. <br />
<br />
HTTP is a clear-text protocol and it is normally secured via an SSL/TLS tunnel, resulting in HTTPS traffic [1]. Use of these protocols ensure not only confidentiality but also authentication. Servers are authenticated using digital certificates, and it is also possibile to use client certificate for mutual authentication. <br />
<br />
Even if high grade ciphers are today supported and normally used, some misconfiguration in server can be used to force the use of a weak cipher - or at worst no encryption - permitting to an attacker to gain access to the supposed secure communication channel. Other misconfiguration can be used for a Denial of Service attack.<br />
<br />
== Description of the Issue == <br />
If control is missed and HTTP protocol is used to transmit sensitive information is a vulnerability [2] (e.g. credentials transmitted over HTTP [3]) and there are a specific OWASP Testing Guide v4’s test.<br />
<br />
If SSL/TLS service is present it is good but it increments the attack surface and some vulnerabilities insist on it, such as:<br />
* SSL/TLS protocols, ciphers, keys and renegotiation must be properly configured.<br />
* Certificate validity must be ensured.<br />
Other vulnerabilities linked to this is:<br />
* Software exposed must be updated due to possibility of known vulnerabilities [4].<br />
* Usage of Secure flag for Session Cookies [5].<br />
* Usage of HTTP Strict Transport Security (HSTS) [6].<br />
* The presence of HTTP and HTTPS both, which can be used to intercept traffic [7], [8].<br />
* The presence of mixed HTTP and HTTP content in the same page, which can be used to Leak information.<br />
<br />
===Sensitive data transmitted in clear-text===<br />
If the application transmits sensitive information via unencrypted channes - e.g. HTTP - it is a vulnerability. Typically it is possible to find BASIC authentication over HTTP, input password sent via HTTP and, in general, other information considered by regulations, laws or organization policy.<br />
<br />
===Weak SSL/TSL Ciphers/Protocols/Keys===<br />
Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of at most 40 bits, a key length which could be broken and would allow the decryption of communications. Since then cryptographic export regulations have been relaxed the maximum key size is 128 bits.<br />
It is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. To reach this goal SSL-based services should not offer the possibility to choose weak cipher suite. A cipher suite is specified by an encryption protocol (e.g. DES, RC4, AES), the encryption key length (e.g. 40, 56, or 128 bits), and a hash algorithm (e.g. SHA, MD5) used for integrity checking.<br />
Briefly, the key points for the cipher suite determination are the following: <br />
# The client sends to the server a ClientHello message specifying, among other information, the protocol and the cipher suites that it is able to handle. Note that a client is usually a web browser (most popular SSL client nowadays), but not necessarily, since it can be any SSL-enabled application; the same holds for the server, which needs not to be a web server, though this is the most common case [9].<br />
#The server responds with a ServerHello message, containing the chosen protocol and cipher suite that will be used for that session (in general the server selects the strongest protocol and cipher suite supported by both the client and server). <br />
<br />
It is possible (for example, by means of configuration directives) to specify which cipher suites the server will honor. In this way you may control, for example, whether or not conversations with clients will support 40-bit encryption only.<br />
<br />
#The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
#The server sends a ServerHelloDone message and waits for a client response.<br />
#Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
===SSL certificate validity – client and server===<br />
<br />
When accessing a web application via the HTTPS protocol, a secure channel is established between the client and the server. The identity of one (the server) or both parties (client and server) is then established by means of digital certificates. So, once the cipher suite is determined, the “SSL Handshake” continues with the exchange of the certificates, like follow:<br />
# The server sends its Certificate message and, if client authentication is required, also sends a CertificateRequest message to the client.<br />
# The server sends a ServerHelloDone message and waits for a client response.<br />
# Upon receipt of the ServerHelloDone message, the client verifies the validity of the server's digital certificate.<br />
<br />
In order for the communication to be set up, a number of checks on the certificates must be passed. While discussing SSL and certificate based authentication is beyond the scope of this Guide, we will focus on the main criteria involved in ascertaining certificate validity: <br />
<br />
* Checking if the Certificate Authority (CA) is a known one (meaning one considered trusted);<br />
* Checking that the certificate is currently valid;<br />
* Checking that the name of the site and the name reported in the certificate match.<br />
<br />
Let is examine each check more in detail. <br />
<br />
* Each browser comes with a preloaded list of trusted CAs, against which the certificate signing CA is compared (this list can be customized and expanded at will). During the initial negotiations with an HTTPS server, if the server certificate relates to a CA unknown to the browser, a warning is usually raised. This happens most often because a web application relies on a certificate signed by a self-established CA. Whether this is to be considered a concern depends on several factors. For example, this may be fine for an Intranet environment (think of corporate web email being provided via HTTPS; here, obviously all users recognize the internal CA as a trusted CA). When a service is provided to the general public via the Internet, however (i.e. when it is important to positively verify the identity of the server we are talking to), it is usually imperative to rely on a trusted CA, one which is recognized by all the user base (and here we stop with our considerations; we won’t delve deeper in the implications of the trust model being used by digital certificates). <br />
<br />
* Certificates have an associated period of validity, therefore they may expire. Again, we are warned by the browser about this. A public service needs a temporally valid certificate; otherwise, it means we are talking with a server whose certificate was issued by someone we trust, but has expired without being renewed. <br />
<br />
* What if the name on the certificate and the name of the server do not match? If this happens, it might sound suspicious. For a number of reasons, this is not so rare to see. A system may host a number of name-based virtual hosts, which share the same IP address and are identified by means of the HTTP 1.1 Host: header information. In this case, since the SSL handshake checks the server certificate before the HTTP request is processed, it is not possible to assign different certificates to each virtual server. Therefore, if the name of the site and the name reported in the certificate do not match, we have a condition which is typically signaled by the browser. To avoid this, IP-based virtual servers must be used. [33] and [34] describe techniques to deal with this problem and allow name-based virtual hosts to be correctly referenced. <br />
<br />
===Other vulnerabilities===<br />
The presence of a new service, listening in a separate tcp port may introduce vulnerabilities such as Infrastructure vulnerability if software is not up to date [4]. Futhermore for a correct protection of data during transmission Session Cookie must use the Secure flag [5] and some directives should be sent to the browser to accept only secure traffic (e.g. HSTS [6], CSP [9]). <br />
<br />
Also there are some attacks can be used to intercept traffic if the web server exposes the application on both HTTP and HTTPS [6], [7] or in case of mixed HTTP and HTTPS resources in the same page.<br />
<br />
== Black Box testing and example ==<br />
<br />
===Testing for sensitive data transmitted in clear-text===<br />
Various typologies of information which must be protected can be also transmitted in clear text. It is possible to check if these information is transmitted over HTTP instead of HTTPS.<br />
<br />
Please refer to specific Tests for full details, for credentials [3] and other kind of data [2]. <br />
<br />
=====Example 1. Basic Authentication over HTTP=====<br />
A typical example is the usage of Basic Autentication over HTTP. Also because with Basic Autentication, after login, credentials are encoded - and not encrypted - into HTTP Headers.<br />
<pre><br />
$ curl -kis http://example.com/restricted/<br />
HTTP/1.1 401 Authorization Required<br />
Date: Fri, 01 Aug 2013 00:00:00 GMT<br />
WWW-Authenticate: Basic realm="Restricted Area"<br />
Accept-Ranges: bytes<br />
Vary: Accept-Encoding<br />
Content-Length: 162<br />
Content-Type: text/html<br />
<br />
<html><head><title>401 Authorization Required</title></head><br />
<body bgcolor=white><br />
<h1>401 Authorization Required</h1><br />
<br />
Invalid login credentials!<br />
<br />
</body></html><br />
</pre><br />
<br />
===Testing for Weak SSL/TSL Ciphers/Protocols/Keys vulnerabilities===<br />
Large number of available cipher suites and quick progress in cryptanalysis makes judging a SSL server a non-trivial task. At the time of writing these criteria are widely recognized as minimum checklist:<br />
* Weak ciphers must not be used (e.g. less than 128 bits [10]; no NULL ciphers suite, due to no encryption used; no Anonymous Diffie-Hellmann, due to not provides authentication).<br />
* Weak protocols must be disabled (e.g. SSLv2 must be disabled, due to known weaknesses in protocol design [11]).<br />
* Renegotiation must be properly configured (e.g. Insecure Renegotiation must be disabled, due to MiTM attacks [12] and Client-initiated Renegotiation must be disabled, due to Denial of Service vulnerability [13]).<br />
* No Export (EXP) level cipher suites, due to can be easly broken [10].<br />
* X.509 certificates key length must be strong (e.g. if RSA or DSA is used the key must be at least 1024 bits).<br />
* X.509 certificates must be signed only with secure hashing algoritms (e.g. not signed using MD5 hash, due to known collision attacks on this hash).<br />
* Keys must be generated with proper entropy (e.g, Weak Key Generated with Debian) [14].<br />
A most complete checklist includes:<br />
* Secure Renegotiation should be enabled.<br />
* MD5 should not be used, due to known collision attacks, but it is ok the use with at least 128 bit key.<br />
* RC4 should not be used, due to crypto-analytical attacks [15].<br />
* Server should be protected from BEAST Attack [16].<br />
* Server should be protected from CRIME attack, TLS compression must be disabled [17].<br />
* Server should support Forward Secrecy [18].<br />
<br />
Following standards can be used as reference while assessing SSL servers:<br />
* PCI-DSS v2.0 in point 4.1 requires compliant parties to use "strong cryptography" without precisely defining key lengths and algorithms. Common interpretation, partially based on previous versions of the standard, is that at least 128 bit key cipher, no export strength algorithms and no SSLv2 should be used [19].<br />
* Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] and SSL Threat Model [20] has been proposed to standardize SSL server assessment and configuration. But is less updated than the SSL Server tool [21].<br />
* OWASP has a lot of resources about SSL/TLS Security [22], [23], [24], [25]. [26].<br />
<br />
Some tools and scanners both commercial - e.g. Tenable Nessus [27] - and free - e.g. SSLAudit [28] or SSLScan [29], and other used into examples - can be used to assess SSL/TLS vulnerabilities. But due to evolution of these vulnerabilities a good way is also to check them manually with openssl [30] or using tool’s output as an input for manual evaluation using the references on the bottom on the Test to stay updated.<br />
<br />
====Example 2. SSL service recognition via nmap====<br />
First step is to identify ports which have SSL/TLS wrapped services. Typically tcp ports with SSL for web and mail services are - but not limited to - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).<br />
In this example we search for SSL services using nmap with “-sV” option, used for identify services and it is also able to identify SSL services [31]. Other options are for this particular example and must be customized. Often in a Web Application Penetration Test scope is limited to port 80 and 443.<br />
<br />
<pre><br />
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up, received user-set (0.20s latency).<br />
Not shown: 89 filtered ports<br />
Reason: 89 no-responses<br />
PORT STATE SERVICE REASON VERSION<br />
21/tcp open ftp syn-ack Pure-FTPd<br />
22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)<br />
25/tcp open smtp syn-ack Exim smtpd 4.80<br />
26/tcp open smtp syn-ack Exim smtpd 4.80<br />
80/tcp open http syn-ack<br />
110/tcp open pop3 syn-ack Dovecot pop3d<br />
143/tcp open imap syn-ack Dovecot imapd<br />
443/tcp open ssl/http syn-ack Apache<br />
465/tcp open ssl/smtp syn-ack Exim smtpd 4.80<br />
993/tcp open ssl/imap syn-ack Dovecot imapd<br />
995/tcp open ssl/pop3 syn-ack Dovecot pop3d<br />
Service Info: Hosts: example.com<br />
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .<br />
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds<br />
</pre><br />
<br />
====Example 3. Checking for Certificate information, Weak Ciphers and SSLv2 via nmap====<br />
nmap has two scripts for checking Certificate information, Weak Ciphers and SSLv2 [31].<br />
<br />
<pre><br />
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com<br />
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST<br />
Nmap scan report for www.example.com (127.0.0.1)<br />
Host is up (0.090s latency).<br />
rDNS record for 127.0.0.1: www.example.com<br />
PORT STATE SERVICE<br />
443/tcp open https<br />
| ssl-cert: Subject: commonName=www.example.org<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 1024<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
465/tcp open smtps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
993/tcp open imaps<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
995/tcp open pop3s<br />
| ssl-cert: Subject: commonName=*.exapmple.com<br />
| Issuer: commonName=*******<br />
| Public Key type: rsa<br />
| Public Key bits: 2048<br />
| Not valid before: 2010-01-23T00:00:00+00:00<br />
| Not valid after: 2020-02-28T23:59:59+00:00<br />
| MD5: *******<br />
|_SHA-1: *******<br />
| ssl-enum-ciphers: <br />
| SSLv3: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
| TLSv1.0: <br />
| ciphers: <br />
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong<br />
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong<br />
| TLS_RSA_WITH_RC4_128_SHA - strong<br />
| compressors: <br />
| NULL<br />
|_ least strength: strong<br />
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds<br />
</pre><br />
<br />
====Example 4 Checking for Client-initiated Renegotiation and Secure Renegotiation via openssl (manually)====<br />
openssl [30] can be used for testing manually SSL/TLS. In this example we try to initiate a renegotiation by client [m] connecting to server with openssl - writing the fist line of an HTTP request, in a new line typing “R”, waiting for renegotiaion and completing the HTTP request - and check if secure renegotiaion is supperted looking server output. Using manual request it is also possible to see if Compression is enabled for TLS in order to check for CRIME [13], check for ciphers and other vulnerabilities. <br />
<br />
<pre><br />
$ openssl s_client -connect www2.example.com:443<br />
CONNECTED(00000003)<br />
depth=2 ******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
---<br />
Certificate chain<br />
0 s:******<br />
i:******<br />
1 s:******<br />
i:******<br />
2 s:******<br />
i:******<br />
---<br />
Server certificate<br />
-----BEGIN CERTIFICATE-----<br />
******<br />
-----END CERTIFICATE-----<br />
subject=******<br />
issuer=******<br />
---<br />
No client certificate CA names sent<br />
---<br />
SSL handshake has read 3558 bytes and written 640 bytes<br />
---<br />
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA<br />
Server public key is 2048 bit<br />
Secure Renegotiation IS NOT supported<br />
Compression: NONE<br />
Expansion: NONE<br />
SSL-Session:<br />
Protocol : TLSv1<br />
Cipher : DES-CBC3-SHA<br />
Session-ID: ******<br />
Session-ID-ctx: <br />
Master-Key: ******<br />
Key-Arg : None<br />
PSK identity: None<br />
PSK identity hint: None<br />
SRP username: None<br />
Start Time: ******<br />
Timeout : 300 (sec)<br />
Verify return code: 20 (unable to get local issuer certificate)<br />
---<br />
</pre><br />
Now we can write the first line of an HTTP request and then R in a new line.<br />
<pre><br />
HEAD / HTTP/1.1<br />
R<br />
</pre><br />
Server is renegotiating<br />
<pre><br />
RENEGOTIATING<br />
depth=2 C******<br />
verify error:num=20:unable to get local issuer certificate<br />
verify return:0<br />
</pre><br />
And we can complete our request, checking for response.<br />
<pre><br />
HEAD / HTTP/1.1<br />
<br />
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. )<br />
Connection: close<br />
Pragma: no-cache<br />
Cache-Control: no-cache<br />
Content-Type: text/html<br />
Content-Length: 1792 <br />
<br />
read:errno=0<br />
</pre><br />
Even if the HEAD is not permitted, Client-intiated renegotiaion is permitted.<br />
<br />
====Example 5. Testing supported Cipher Suites, BEAST and CRIME attacks via TestSSLServer====<br />
TestSSLServer [32] is a script which permits to check cipher suite and also BEAST and CRIME attacks. BEAST (Browser Exploit Against SSL/TLS) exploits a vulnerability of CBC in TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) exploits a vulnerability of TLS Compression, that sould be disabled. It is really interesting a first fix for BEAST was the usage of RC4, but this is discouraged due to a crypto-analytical attack to RC4 [15].<br />
<br />
An online tool to check for these attacks is SSL Labs, but can be used only for internet facing servers. Also consider that target data will be stored on SSL Labs server and also will result some connection from SSL Labs server [21].<br />
<br />
<pre><br />
$ java -jar TestSSLServer.jar www3.example.com 443<br />
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2<br />
Deflate compression: no<br />
Supported cipher suites (ORDER IS NOT SIGNIFICANT):<br />
SSLv3<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
(TLSv1.0: idem)<br />
(TLSv1.1: idem)<br />
TLSv1.2<br />
RSA_WITH_RC4_128_SHA<br />
RSA_WITH_3DES_EDE_CBC_SHA<br />
DHE_RSA_WITH_3DES_EDE_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA<br />
RSA_WITH_AES_256_CBC_SHA<br />
DHE_RSA_WITH_AES_256_CBC_SHA<br />
RSA_WITH_AES_128_CBC_SHA256<br />
RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA<br />
DHE_RSA_WITH_AES_128_CBC_SHA256<br />
DHE_RSA_WITH_AES_256_CBC_SHA256<br />
RSA_WITH_CAMELLIA_256_CBC_SHA<br />
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA<br />
TLS_RSA_WITH_SEED_CBC_SHA<br />
TLS_DHE_RSA_WITH_SEED_CBC_SHA<br />
TLS_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_RSA_WITH_AES_256_GCM_SHA384<br />
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<br />
----------------------<br />
Server certificate(s):<br />
******<br />
----------------------<br />
Minimal encryption strength: strong encryption (96-bit or more)<br />
Achievable encryption strength: strong encryption (96-bit or more)<br />
BEAST status: vulnerable<br />
CRIME status: protected<br />
<br />
</pre><br />
<br />
====Example 6. Testing SSL/TLS vulnerabilities with sslyze====<br />
sslyze [33] is a python script which permits also mass scan and XML output. Follows an example of a regular scan. Is one of the most complete and versatile tool for SSL/TLS testing.<br />
<br />
<pre><br />
./sslyze.py --regular example.com:443<br />
<br />
REGISTERING AVAILABLE PLUGINS<br />
-----------------------------<br />
<br />
PluginHSTS<br />
PluginSessionRenegotiation<br />
PluginCertInfo<br />
PluginSessionResumption<br />
PluginOpenSSLCipherSuites<br />
PluginCompression<br />
<br />
<br />
<br />
CHECKING HOST(S) AVAILABILITY<br />
-----------------------------<br />
<br />
example.com:443 => 127.0.0.1:443<br />
<br />
<br />
<br />
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443<br />
---------------------------------------------------<br />
<br />
* Compression :<br />
Compression Support: Disabled<br />
<br />
* Session Renegotiation :<br />
Client-initiated Renegotiations: Rejected<br />
Secure Renegotiation: Supported<br />
<br />
* Certificate :<br />
Validation w/ Mozilla's CA Store: Certificate is NOT Trusted: unable to get local issuer certificate<br />
Hostname Validation: MISMATCH <br />
SHA1 Fingerprint: ******<br />
<br />
Common Name: www.example.com <br />
Issuer: ******<br />
Serial Number: **** <br />
Not Before: Sep 26 00:00:00 2010 GMT <br />
Not After: Sep 26 23:59:59 2020 GMT <br />
<br />
Signature Algorithm: sha1WithRSAEncryption <br />
Key Size: 1024 bit <br />
X509v3 Subject Alternative Name: {'othername': ['<unsupported>'], 'DNS': ['www.example.com']}<br />
<br />
* OCSP Stapling :<br />
Server did not send back an OCSP response. <br />
<br />
* Session Resumption :<br />
With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total attempts).<br />
With TLS Session Tickets: Supported<br />
<br />
* SSLV2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* SSLV3 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits HTTP 200 OK <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: None <br />
<br />
* TLSV1_1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-SHA socket.timeout - timed out <br />
ECDH-ECDSA-AES256-SHA socket.timeout - timed out <br />
<br />
* TLSV1_2 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: None <br />
<br />
Accepted Cipher Suite(s): None <br />
<br />
Undefined - An unexpected error happened: <br />
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out <br />
<br />
* TLSV1 Cipher Suites :<br />
<br />
Rejected Cipher Suite(s): Hidden <br />
<br />
Preferred Cipher Suite: <br />
RC4-SHA 128 bits Timeout on HTTP GET <br />
<br />
Accepted Cipher Suite(s): <br />
CAMELLIA256-SHA 256 bits HTTP 200 OK <br />
RC4-SHA 128 bits HTTP 200 OK <br />
CAMELLIA128-SHA 128 bits HTTP 200 OK <br />
<br />
Undefined - An unexpected error happened: <br />
ADH-CAMELLIA256-SHA socket.timeout - timed out <br />
<br />
<br />
<br />
SCAN COMPLETED IN 9.68 S<br />
------------------------<br />
</pre><br />
<br />
===Testing SSL certificate validity – client and server===<br />
Firstly upgrade your browser because also CA certs expire and, in every release of the browser, these are been renewed.<br />
Examine the validity of the certificates used by the application. Browsers will issue a warning when encountering expired certificates, certificates issued by untrusted CAs, and certificates which do not match namewise with the site to which they should refer. By clicking on the padlock which appears in the browser window when visiting an HTTPS site, you can look at information related to the certificate – including the issuer, period of validity, encryption characteristics, etc. If the application requires a client certificate, you probably have installed one to access it. Certificate information is available in the browser by inspecting the relevant certificate(s) in the list of the installed certificates. <br />
These checks must be applied to all visible SSL-wrapped communication channels used by the application. Though this is the usual https service running on port 443, there may be additional services involved depending on the web application architecture and on deployment issues (an HTTPS administrative port left open, HTTPS services on non-standard ports, etc.). Therefore, apply these checks to all SSL-wrapped ports which have been discovered. For example, the nmap scanner features a scanning mode (enabled by the –sV command line switch) which identifies SSL-wrapped services. The Nessus vulnerability scanner has the capability of performing SSL checks on all SSL/TLS-wrapped services. <br />
<br />
Some tools, as in previous examples, check also for certificate validity.<br />
<br />
====Example 7. Testing for certificate validity (manually)====<br />
Rather than providing a fictitious example, we have inserted an anonymized real-life example to stress how frequently one stumbles on https sites whose certificates are inaccurate with respect to naming. <br />
The following screenshots refer to a regional site of a high-profile IT company. <br />
<br />
We are visiting an .it site and the certificate was issued to a .com site! Internet Explorer warns that the name on the certificate does not match the name of the site. <br />
<br />
[[Image:SSL Certificate Validity Testing IE Warning.gif]]<br />
''Warning issued by Microsoft Internet Explorer''<br />
<br />
The message issued by Firefox is different – Firefox complains because it cannot ascertain the identity of the .com site the certificate refers to because it does not know the CA which signed the certificate. In fact, Internet Explorer and Firefox do not come preloaded with the same list of CAs. Therefore, the behavior experienced with various browsers may differ.<br />
<br />
[[Image:SSL Certificate Validity Testing Firefox Warning.gif]]<br />
''Warning issued by Mozilla Firefox''<br />
<br />
===Testing for other vulnerabilities===<br />
As mentioned previously there are other types of vulnerabilities that are not related with the SSL/TLS protocol used, the cipher suites or Certificates. A part from others discussed in other parts of the Guide, the another one is possible when the server provide the website both with the HTTP and HTTPS protocols, and permit to an attacker to force a victim into using a non-secure channel instead of a secure one.<br />
<br />
====Surf Jacking====<br />
Surf Jacking attack [7] was first presented by Sandro Gauci and permits to an attacker to hijack an HTTP session even when the victim’s connection is encrypted using SSL or TLS.<br />
The following is a scenario of how the attack can take place:<br />
<br />
The following is a scenario of how the attack can take place:<br />
* Victim logs into the secure website at https://somesecuresite/.<br />
* The secure site issues a session cookie as the client logs in.<br />
* While logged in, the victim opens a new browser window and goes to http:// examplesite/<br />
* An attacker sitting on the same network is able to see the clear text traffic to http://examplesite.<br />
* The attacker sends back a "301 Moved Permanently" in response to the clear text traffic to http://examplesite. The response contains the header “Location: http://somesecuresite /”, which makes it appear that examplesite is sending the web browser to somesecuresite. Notice that the URL scheme is HTTP not HTTPS.<br />
* The victim's browser starts a new clear text connection to http://somesecuresite/ and sends an HTTP request containing cookie in the HTTP header in clear text<br />
* The attacker sees this traffic and logs the cookie for later (ab)use.<br />
To test if a website is vulnerable is sufficient to proceed like follow:<br />
# Check if website supports both HTTP and HTTPS protocol<br />
# Check if cookies do not have the “Secure” flag<br />
<br />
====SSL Strip====<br />
Often applications supports both HTTP and HTTPS. As for usability or because users do not use to type “https://www.example.com”. Often users go into an HTTPS website from link or a redirect. Typically also home banking site have a similar configuration with an iframed login or a form with action attribute over HTTPS but the page under HTTP.<br />
An attacker in a privileged position - as described in SSL strip [8] - can incercept traffic when user is into HTTP and manipulate it to get a Man-In-The-Middle attack under HTTPS.<br />
To test if application is vulnerable is sufficient the website supports both HTTP and HTTPS.<br />
<br />
== Gray Box testing and example ==<br />
<br />
===Testing for Weak SSL/TSL Cipher Suites===<br />
Check the configuration of the web servers which provide https services. If the web application provides other SSL/TLS wrapped services, these should be checked as well. <br />
<br />
====Example 8. Windows Server==== <br />
Check the configuration on a Microsoft Windows Server (2000, 2003 and 2008) using the registry key:<br />
<pre>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\</pre><br />
which has some sub-keys like Ciphers, Protocols and KeyExchangeAlgorithms.<br />
<br />
====Example 9: Apache====<br />
To check the cipher suites and protocols supported by Apache2 web server open the ssl.conf file and search for the SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,SSLInsecureRenegotiation and SSLCompression directives.<br />
<br />
===Testing SSL certificate validity – client and server===<br />
Examine the validity of the certificates used by the application at both server and client levels. The usage of certificates is primarily at the web server level; however, there may be additional communication paths protected by SSL (for example, towards the DBMS). You should check the application architecture to identify all SSL protected channels.<br />
<br />
==References==<br />
'''OWASP Resources'''<br />
* [5] [OWASP Testing Guide - Testing for cookie attributes (OTG-SESS-002)|https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)]<br />
* [4][OWASP Testing Guide - Test Network/Infrastructure Configuration (OTG-CONFIG-001)|https://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management_(OWASP-CM-003)]<br />
* [6] [OWASP Testing |https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)][Guide - Testing for Missing HSTS header (OTG-CONFIG-009)|https://www.owasp.org/index.php/Testing_for_Missing_HSTS_header]<br />
* [2] [OWASP Testing Guide - Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|https://www.owasp.org/index.php?title=Testing_for_Sensitive_information_sent_via_unencrypted_channels_(OTG-CRYPST-007)&action=edit&redlink=1]<br />
* [3] [OWASP Testing Guide - Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|https://www.owasp.org/index.php/Testing_for_Credentials_Transported_over_an_Encrypted_Channel_(OWASP-AT-001)]<br />
* [9] [OWASP Testing Guide - Test Content Security Policy (OTG-CONFIG-008)|https://www.owasp.org/index.php/Testing_for_Content_Security_Policy_weakness]<br />
* [22] [OWASP Cheat sheet - Transport Layer Protection|https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]<br />
* [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure|https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure]<br />
* [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection|https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection]<br />
* [25] [OWASP ASVS 2009 - Verification 10|https://code.google.com/p/owasp-asvs/wiki/Verification_V10]<br />
* [26] [OWASP Application Security FAQ - Cryptography/SSL|https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Cryptography.2FSSL]<br />
<br />
'''Whitepapers'''<br />
* [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176)|http://www.ietf.org/rfc/rfc5246.txt]<br />
* [33] [RFC2817 - Upgrading to TLS Within HTTP/1.1|]<br />
* [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions|http://www.ietf.org/rfc/rfc6066.txt]<br />
* [11] [SSLv2 Protocol Multiple Weaknesses |http://osvdb.org/56387]<br />
* [12] [Mitre - TLS Renegotiation MiTM|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555]<br />
* [13] [Qualys SSL Labs - TLS Renegotiation DoS|https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks]<br />
* [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices|https://www.ssllabs.com/projects/best-practices/index.html]<br />
* [14] [Qualys SSL Labs - SSL Server Rating Guide|https://www.ssllabs.com/projects/rating-guide/index.html]<br />
* [20] [Qualys SSL Labs - SSL Threat Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]<br />
* [18] [Qualys SSL Labs - Forward Secrecy|https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy]<br />
* [15] [Qualys SSL Labs - RC4 Usage|https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what]<br />
* [16] [Qualys SSL Labs - BEAST|https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls]<br />
* [17] [Qualys SSL Labs - CRIME|https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls]<br />
* [7] [SurfJacking attack|https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf]<br />
* [8] [SSLStrip attack|http://www.thoughtcrime.org/software/sslstrip/]<br />
* [19] [PCI-DSS v2.0|https://www.pcisecuritystandards.org/security_standards/documents.php]<br />
<br />
'''Tools'''<br />
* [21][Qualys SSL Labs - SSL Server Test|https://www.ssllabs.com/ssltest/index.html]: internet facing scanner<br />
* [27] [Tenable - Nessus Vulnerability Scanner|http://www.tenable.com/products/nessus]: includes some plugins to test different SSL related vulnerabilities, Certificates and the presence of HTTP Basic authentication without SSL.<br />
* [32] [TestSSLServer|http://www.bolet.org/TestSSLServer/]: a java scanner - and also windows executable - includes tests for cipher suites, CRIME and BEAST<br />
* [33] [sslyze|https://github.com/iSECPartners/sslyze]: is a python script to check vulnerabilities in SSL/TLS.<br />
* [28] [SSLAudit|https://code.google.com/p/sslaudit/]: a perl script/windows executable scanner which follows Qualys SSL Labs Rating Guide.<br />
* [29] [SSLScan|http://sourceforge.net/projects/sslscan/] with [SSL Tests|http://www.pentesterscripting.com/discovery/ssl_tests]: a SSL Scanner and a wrapper in order to enumerate SSL vulnerabilities.<br />
* [31] [nmap|http://nmap.org/]: can be used primary to identify SSL-based services and then to check Certificate and SSL/TLS vulnerabilities. In particular it has some scripts to check [Certificate and SSLv2|http://nmap.org/nsedoc/scripts/ssl-cert.html] and supported [SSL/TLS protocols/ciphers|http://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html] with an internal rating.<br />
* [30] [curl|http://curl.haxx.se/] and [openssl|http://www.openssl.org/]: can be used to query manually SSL/TLS services<br />
* [9] [Stunnel|http://www.stunnel.org]: a noteworthy class of SSL clients is that of SSL proxies such as stunnel available at which can be used to allow non-SSL enabled tools to talk to SSL services)<br />
<br />
[[Category:Cryptographic Vulnerability]]<br />
[[Category:SSL]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Web_Application_Security_Testing_Cheat_Sheet&diff=137677Web Application Security Testing Cheat Sheet2012-10-16T10:40:32Z<p>Simone onofri: </p>
<hr />
<div>= DRAFT CHEAT SHEET - WORK IN PROGRESS =<br />
<br />
= Introduction =<br />
<br />
This cheat sheet provides a checklist of tasks to be performed when performing a blackbox security test of a web application.<br />
<br />
= Purpose =<br />
<br />
This checklist is intended to be used as an aide memoire for experienced pentesters and should be used in conjunction with the [[:Category:OWASP Testing Project|OWASP Testing Guide]]. It will be updated as the [[OWASP_Application_Testing_guide_v4|Testing Guide v4]] is progressed.<br />
<br />
The intention is that this guide will be available as an XML document, with scripts that convert it into formats such as pdf, Media Wiki markup, HTML etc. <br />
<br />
This will allow it to be consumed within security tools as well as being available in a format suitable for printing.<br />
<br />
All feedback or offers of help will be appreciated - and if you have specific chances you think should be made, just get stuck in.<br />
<br />
= The Checklist =<br />
<br />
== Information Gathering ==<br />
* Manually explore the site<br />
* Spider/crawl for missed or hidden content<br />
* Check for files that expose content, such as robots.txt, sitemap.xml, .DS_Store<br />
* Check the caches of major search engines for publicly accessible sites<br />
* Check for differences in content based on User Agent (eg, Mobile sites, access as a Search engine Crawler)<br />
* Perform Web Application Fingerprinting<br />
* Identify technologies used<br />
* Identify user roles<br />
* Identify application entry points<br />
* Identify client-side code<br />
* Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)<br />
* Identify co-hosted and related applications<br />
* Identify all hostnames and ports<br />
* Identify third-party hosted content<br />
<br />
== Configuration Management ==<br />
* Check for commonly used application and administrative URLs<br />
* Check for old, backup and unreferenced files<br />
* Check HTTP methods supported and Cross Site Tracing (XST)<br />
* Test file extensions handling<br />
* Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS)<br />
* Test for policies (e.g. Flash, Silverlight, robots)<br />
* Test for non-production data in live environment, and vice-versa<br />
* Check for sensitive data in client-side code (e.g. API keys, credentials)<br />
<br />
== Secure Transmission ==<br />
* Check SSL Version, Algorithms, Key length<br />
* Check for Digital Certificate Validity (Duration, Signature and CN)<br />
* Check credentials only delivered over HTTPS<br />
* Check session tokens only delivered over HTTPS<br />
* Check if HTTP Strict Transport Security (HSTS) in use<br />
== Authentication ==<br />
* Test for user enumeration<br />
* Test for authentication bypass<br />
* Test for bruteforce protection<br />
* Test password quality rules<br />
* Test remember me functionality<br />
* Test for autocomplete on password forms/input <br />
* Test password reset and/or recovery<br />
* Test password change process<br />
* Test CAPTCHA<br />
* Test multi factor authentication<br />
* Test for logout functionality presence<br />
* Test for cache management on HTTP (eg Pragma, Expires, Max-age)<br />
* Test for default logins<br />
* Test for user-accessible authentication history<br />
* Test for out-of channel notification of account lockouts and successful password changes<br />
* Test for consistent authentication across applications with shared authentication schema / SSO<br />
== Session Management ==<br />
* Establish how session management is handled in the application (eg, tokens in cookies, token in URL)<br />
* Check session tokens for cookie flags (httpOnly and secure)<br />
* Check session cookie scope (path and domain)<br />
* Check session cookie duration (expires and max-age)<br />
* Check session termination after a maximum lifetime<br />
* Check session termination after relative timeout<br />
* Check session termination after logout<br />
* Test to see if users can have multiple simultaneous sessions<br />
* Test session cookies for randomness<br />
* Confirm that new session tokens are issued on login, role change and logout<br />
* Test for consistent session management across applications with shared session management<br />
* Test for session puzzling<br />
* Test for CSRF and clickjacking<br />
== Authorization ==<br />
* Test for path traversal<br />
* Test for bypassing authorization schema<br />
* Test for vertical Access control problems (a.k.a. Privilege Escalation)<br />
* Test for horizontal Access control problems (between two users at the same privilege level)<br />
* Test for missing authorization<br />
== Data Validation ==<br />
* Test for Reflected Cross Site Scripting<br />
* Test for Stored Cross Site Scripting<br />
* Test for DOM based Cross Site Scripting<br />
* Test for Cross Site Flashing<br />
* Test for HTML Injection<br />
* Test for SQL Injection<br />
* Test for LDAP Injection<br />
* Test for ORM Injection<br />
* Test for XML Injection<br />
* Test for XXE Injection<br />
* Test for SSI Injection<br />
* Test for XPath Injection<br />
* Test for XQuery Injection<br />
* Test for IMAP/SMTP Injection<br />
* Test for Code Injection<br />
* Test for Command Injection<br />
* Test for Overflow (Stack, Heap and Integer)<br />
* Test for Format String<br />
* Test for incubated vulnerabilities<br />
* Test for HTTP Splitting/Smuggling<br />
* Test for HTTP Verb Tampering<br />
* Test for Open Redirection<br />
* Test for Local File Inclusion<br />
* Test for Remote File Inclusion<br />
* Compare client-side and server-side validation rules<br />
* Test for NoSQL injection<br />
* Test for HTTP parameter pollution<br />
* Test for auto-binding<br />
== Denial of Service ==<br />
* Test for anti-automation<br />
* Test for account lockout<br />
* Test for HTTP protocol DoS<br />
== Business Logic ==<br />
* Test for feature misuse<br />
* Test for lack of non-repudiation<br />
* Test for trust relationships<br />
* Test for integrity of data<br />
* Test segregation of duties<br />
== Cryptography ==<br />
* Check if data which should be encrypted is not<br />
* Check for wrong algorithms usage depending on context<br />
* Check for weak algorithms usage<br />
* Check for proper use of salting<br />
* Check for randomness functions<br />
== Risky Functionality - File Uploads ==<br />
* Test that acceptable file types are whitelisted<br />
* Test that file size limits, upload frequency and total file counts are defined and are enforced<br />
* Test that file contents match the defined file type<br />
* Test that all file uploads have Anti-Virus scanning in-place.<br />
* Test that unsafe filenames are sanitised<br />
* Test that uploaded files are not directly accessible within the web root<br />
* Test that uploaded files are not served on the same hostname/port<br />
* Test that files and other media are integrated with the authentication and authorisation schemas<br />
== Risky Functionality - Card Payment ==<br />
* Test for known vulnerabilities and configuration issues on Web Server and Web Application<br />
* Test for default or guessable password<br />
* Test for non-production data in live environment, and vice-versa<br />
* Test for Injection vulnerabilities <br />
* Test for Buffer Overflows<br />
* Test for Insecure Cryptographic Storage<br />
* Test for Insufficient Transport Layer Protection<br />
* Test for Improper Error Handling<br />
* Test for all vulnerabilities with a CVSS v2 score > 4.0<br />
* Test for Authentication and Authorization issues<br />
* Test for CSRF<br />
== HTML 5==<br />
* Test Web Messaging<br />
* Test for Web Storage SQL injection<br />
<br />
= Other Formats =<br />
<br />
* Current cheat sheet in DradisPro template format [https://github.com/raesene/OWASP_Web_App_Testing_Cheatsheet_Converter/blob/master/OWASP_Web_Application_Testing_Cheat_Sheet.xml on github]<br />
<br />
= Authors and primary contributors =<br />
<br />
[[User:Simon Bennetts|Simon Bennetts]]<br/><br />
[[User:Raesene|Rory McCune]] <br/><br />
Colin Watson<br/><br />
Simone Onofri<br/><br />
<br />
All the authors of theTesting Guide v3<br />
<br />
= Other Contributors =<br />
<br />
<br />
= Related articles =<br />
<br />
OWASP [[:Category:OWASP Testing Project|Testing Guide]]<br />
<br />
Mozilla [https://wiki.mozilla.org/WebAppSec/Web_Security_Verification Web Security Verification]<br />
<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]] [[Category:OWASP_Breakers]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Web_Application_Security_Testing_Cheat_Sheet&diff=135211Web Application Security Testing Cheat Sheet2012-09-02T23:26:35Z<p>Simone onofri: </p>
<hr />
<div>= DRAFT CHEAT SHEET - WORK IN PROGRESS =<br />
<br />
= Introduction =<br />
<br />
This cheat sheet provides a checklist of tasks to be performed when performing a blackbox security test of a web application.<br />
<br />
= Purpose =<br />
<br />
This checklist is intended to be used as an aide memoire for experienced pentesters and should be used in conjunction with the [[:Category:OWASP Testing Project|OWASP Testing Guide]]. It will be updated as the [[OWASP_Application_Testing_guide_v4|Testing Guide v4]] is progressed.<br />
<br />
The intention is that this guide will be available as an XML document, with scripts that convert it into formats such as pdf, Media Wiki markup, HTML etc. <br />
<br />
This will allow it to be consumed within security tools as well as being available in a format suitable for printing.<br />
<br />
It is currently at a very early stage, but any feedback or offers of help will be appreciated.<br />
<br />
= The Checklist =<br />
<br />
== Information Gathering ==<br />
* Manually explore the site<br />
* Spider/crawl for missed or hidden content<br />
* Check for files that expose content, such as robots.txt, sitemap.xml, .DS_Store<br />
* Check the caches of major search engines for publicly accessible sites<br />
* Check for differences in content based on User Agent (eg, Mobile sites, access as a Search engine Crawler)<br />
* Perform Web Application Fingerprinting<br />
* Identify technologies used<br />
* Identify user roles<br />
* Identify application entry points<br />
* Identify client-side code<br />
* Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)<br />
* Identify co-hosted and related applications<br />
* Identify all hostnames and ports<br />
* Identify third-party hosted content<br />
<br />
== Configuration Management ==<br />
* Check for commonly used application and administrative URLs<br />
* Check for old, backup and unreferenced files<br />
* Check HTTP methods supported and Cross Site Tracing (XST)<br />
* Test file extensions handling<br />
* Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS)<br />
* Test for policies (e.g. Flash, Silverlight, robots)<br />
* Test for non-production data in live environment, and vice-versa<br />
* Check for sensitive data in client-side code (e.g. API keys, credentials)<br />
<br />
== Secure Transmission ==<br />
* Check SSL Version, Algorithms, Key length<br />
* Check for Digital Certificate Validity (Duration, Signature and CN)<br />
* Check credentials only delivered over HTTPS<br />
* Check session tokens only delivered over HTTPS<br />
* Check if HTTP Strict Transport Security (HSTS) in use<br />
== Authentication ==<br />
* Test for user enumeration<br />
* Test for authentication bypass<br />
* Test for bruteforce protection<br />
* Test password quality rules<br />
* Test remember me functionality<br />
* Test for autocomplete on password forms/input <br />
* Test password reset and/or recovery<br />
* Test password change process<br />
* Test CAPTCHA<br />
* Test multi factor authentication<br />
* Test for logout functionality presence<br />
* Test for cache management on HTTP (eg Pragma, Expires, Max-age)<br />
* Test for default logins<br />
* Test for user-accessible authentication history<br />
* Test for out-of channel notification of account lockouts and successful password changes<br />
* Test for consistent authentication across applications with shared authentication schema / SSO<br />
== Session Management ==<br />
* Establish how session management is handled in the application (eg, tokens in cookies, token in URL)<br />
* Check session tokens for cookie flags (httpOnly and secure)<br />
* Check session cookie scope (path and domain)<br />
* Check session cookie duration (expires and max-age)<br />
* Check session termination after a maximum lifetime<br />
* Check session termination after relative timeout<br />
* Check session termination after logout<br />
* Test to see if users can have multiple simultaneous sessions<br />
* Test session cookies for randomness<br />
* Confirm that new session tokens are issued on login, role change and logout<br />
* Test for consistent session management across applications with shared session management<br />
* Test for session puzzling<br />
* Test for CSRF and clickjacking<br />
== Authorization ==<br />
* Test for path traversal<br />
* Test for bypassing authorization schema<br />
* Test for vertical Access control problems (a.k.a. Privilege Escalation)<br />
* Test for horizontal Access control problems (between two users at the same privilege level)<br />
* Test for missing authorization<br />
== Data Validation ==<br />
* Test for Reflected Cross Site Scripting<br />
* Test for Stored Cross Site Scripting<br />
* Test for DOM based Cross Site Scripting<br />
* Test for Cross Site Flashing<br />
* Test for HTML Injection<br />
* Test for SQL Injection<br />
* Test for LDAP Injection<br />
* Test for ORM Injection<br />
* Test for XML Injection<br />
* Test for XXE Injection<br />
* Test for SSI Injection<br />
* Test for XPath Injection<br />
* Test for XQuery Injection<br />
* Test for IMAP/SMTP Injection<br />
* Test for Code Injection<br />
* Test for Command Injection<br />
* Test for Overflow (Stack, Heap and Integer)<br />
* Test for Format String<br />
* Test for incubated vulnerabilities<br />
* Test for HTTP Splitting/Smuggling<br />
* Test for HTTP Verb Tampering<br />
* Test for Open Redirection<br />
* Test for Local File Inclusion<br />
* Test for Remote File Inclusion<br />
* Compare client-side and server-side validation rules<br />
* Test for NoSQL injection<br />
* Test for HTTP parameter pollution<br />
* Test for auto-binding<br />
== Denial of Service ==<br />
* Test for anti-automation<br />
* Test for account lockout<br />
* Test for HTTP protocol DoS<br />
== Business Logic ==<br />
* Test for feature misuse<br />
* Test for lack of non-repudiation<br />
* Test for trust relationships<br />
* Test for integrity of data<br />
* Test segregation of duties<br />
== Cryptography ==<br />
* Check if data which should be encrypted is not<br />
* Check for wrong algorithms usage depending on context<br />
* Check for weak algorithms usage<br />
* Check for proper use of salting<br />
* Check for randomness functions<br />
== Risky Functionality - File Uploads ==<br />
* Test that acceptable file types are whitelisted<br />
* Test that file size limits, upload frequency and total file counts are defined and are enforced<br />
* Test that file contents match the defined file type<br />
* Test that all file uploads have Anti-Virus scanning in-place.<br />
* Test that unsafe filenames are sanitised<br />
* Test that uploaded files are not directly accessible within the web root<br />
* Test that uploaded files are not served on the same hostname/port<br />
* Test that files and other media are integrated with the authentication and authorisation schemas<br />
== Risky Functionality - Card Payment ==<br />
* Test whether card number are stored<br />
* TBC<br />
== HTML 5==<br />
* Test Web Messaging<br />
* Test for Web Storage SQL injection<br />
<br />
= Authors and primary contributors =<br />
<br />
[[User:Simon Bennetts|Simon Bennetts]]<br/><br />
[[User:Raesene|Rory McCune]] <br/><br />
Colin Watson<br/><br />
Simone Onofri<br/><br />
<br />
All the authors of theTesting Guide v3<br />
<br />
= Other Contributors =<br />
<br />
<br />
= Related articles =<br />
<br />
OWASP [[:Category:OWASP Testing Project|Testing Guide]]<br />
<br />
Mozilla [https://wiki.mozilla.org/WebAppSec/Web_Security_Verification Web Security Verification]<br />
<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]] [[Category:OWASP_Breakers]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Web_Application_Security_Testing_Cheat_Sheet&diff=134089Web Application Security Testing Cheat Sheet2012-08-09T12:27:18Z<p>Simone onofri: </p>
<hr />
<div>= DRAFT CHEAT SHEET - WORK IN PROGRESS =<br />
<br />
= Introduction =<br />
<br />
This cheat sheet provides a checklist of tasks to be performed when performing a blackbox security test of a web application.<br />
<br />
= Purpose =<br />
<br />
This checklist is intended to be used as an aide memoire for experienced pentesters and should be used in conjunction with the [[:Category:OWASP Testing Project|OWASP Testing Guide]]. It will be updated as the [[OWASP_Application_Testing_guide_v4|Testing Guide v4]] is progressed.<br />
<br />
The intention is that this guide will be available as an XML document, with scripts that convert it into formats such as pdf, Media Wiki markup, HTML etc. <br />
<br />
This will allow it to be consumed within security tools as well as being available in a format suitable for printing.<br />
<br />
It is currently at a very early stage, but any feedback or offers of help will be appreciated.<br />
<br />
= The Checklist =<br />
<br />
== Information Gathering ==<br />
* Manually explore the site<br />
* Spider/crawl for missed or hidden content<br />
* Check for files that expose content, such as robots.txt, sitemap.xml, .DS_Store<br />
* Check the caches of major search engines for publicly accessible sites<br />
* Check for differences in content based on User Agent (eg, Mobile sites, access as a Search engine Crawler)<br />
* Perform Web Application Fingerprinting<br />
* Identify technologies used<br />
* Identify user roles<br />
* Identify application entry points<br />
* Identify client-side code<br />
* Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)<br />
* Identify co-hosted and related applications<br />
* Identify all hostnames and ports<br />
* Identify third-party hosted content<br />
<br />
== Configuration Management ==<br />
* Check for commonly used application and administrative URLs<br />
* Check for old, backup and unreferenced files<br />
* Check HTTP methods supported and Cross Site Tracing (XST)<br />
* Test file extensions handling<br />
* Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS)<br />
* Test for policies (e.g. Flash, Silverlight, robots)<br />
* Test for non-production data in live environment, and vice-versa<br />
== Secure Transmission ==<br />
* Check SSL Version, Algorithms, Key length<br />
* Check for Digital Certificate Validity (Duration, Signature and CN)<br />
* Check credentials only delivered over HTTPS<br />
* Check session tokens only delivered over HTTPS<br />
* Check if HTTP Strict Transport Security (HSTS) in use<br />
== Authentication ==<br />
* Test for user enumeration<br />
* Test for authentication bypass<br />
* Test for bruteforce protection<br />
* Test password quality rules<br />
* Test remember me functionality<br />
* Test for autocomplete on password forms/input <br />
* Test password reset and/or recovery<br />
* Test CAPTCHA<br />
* Test multi factor authentication<br />
* Test for logout functionality presence<br />
* Test for cache management on HTTP (eg Pragma, Expires, Max-age)<br />
* Test for default logins<br />
* Test for user-accessible authentication history<br />
* Test for out-of channel notification of account lockouts and successful password changes<br />
* Test for consistent authentication across applications with shared authentication schema / SSO<br />
== Session Management ==<br />
* Establish how session management is handled in the application (eg, tokens in cookies, token in URL)<br />
* Check session tokens for cookie flags (httpOnly and secure)<br />
* Check session cookie scope (path and domain)<br />
* Check session cookie duration (expires and max-age)<br />
* Check session termination after a maximum lifetime<br />
* Check session termination after relative timeout<br />
* Check session termination after logout<br />
* Test to see if users can have multiple simultaneous sessions<br />
* Test session cookies for randomness<br />
* Confirm that new session tokens are issued on login, role change and logout<br />
* Test for consistent session management across applications with shared session management<br />
* Test for session puzzling<br />
* Test for CSRF and clickjacking<br />
== Authorization ==<br />
* Test for path traversal<br />
* Test for bypassing authorization schema<br />
* Test for vertical Access control problems (a.k.a. Privilege Escalation)<br />
* Test for horizontal Access control problems (between two users at the same privilege level)<br />
* Test for missing authorization<br />
== Data Validation ==<br />
* Test for Reflected Cross Site Scripting<br />
* Test for Stored Cross Site Scripting<br />
* Test for DOM based Cross Site Scripting<br />
* Test for Cross Site Flashing<br />
* Test for HTML Injection<br />
* Test for SQL Injection<br />
* Test for LDAP Injection<br />
* Test for ORM Injection<br />
* Test for XML Injection<br />
* Test for XXE Injection<br />
* Test for SSI Injection<br />
* Test for XPath Injection<br />
* Test for XQuery Injection<br />
* Test for IMAP/SMTP Injection<br />
* Test for Code Injection<br />
* Test for Command Injection<br />
* Test for Overflow (Stack, Heap and Integer)<br />
* Test for Format String<br />
* Test for incubated vulnerabilities<br />
* Test for HTTP Splitting/Smuggling<br />
* Test for HTTP Verb Tampering<br />
* Test for Open Redirection<br />
* Test for Local File Inclusion<br />
* Test for Remote File Inclusion<br />
* Compare client-side and server-side validation rules<br />
* Test for NoSQL injection<br />
* Test for HTTP parameter pollution<br />
* Test for auto-binding<br />
== Denial of Service ==<br />
* Test for anti-automation<br />
* Test for account lockout<br />
* Test for HTTP protocol DoS<br />
== Business Logic ==<br />
* Test for feature misuse<br />
* Test for lack of non-repudiation<br />
* Test for trust relationships<br />
* Test for integrity of data<br />
* Test segregation of duties<br />
== Risky Functionality - File Uploads ==<br />
* Test that acceptable file types are whitelisted<br />
* Test that file size limits, upload frequency and total file counts are defined and are enforced<br />
* Test that file contents match the defined file type<br />
* Test that all file uploads have Anti-Virus scanning in-place.<br />
* Test that unsafe filenames are sanitised<br />
* Test that uploaded files are not directly accessible within the web root<br />
* Test that uploaded files are not served on the same hostname/port<br />
* Test that files and other media are integrated with the authentication and authorisation schemas<br />
== Risky Functionality - Card Payment ==<br />
* Test whether card number are stored<br />
* TBC<br />
== HTML 5==<br />
* Test Web Messaging<br />
* Test for Web Storage SQL injection<br />
<br />
= Authors and primary contributors =<br />
<br />
[[User:Simon Bennetts|Simon Bennetts]]<br/><br />
[[User:Raesene|Rory McCune]] <br/><br />
Colin Watson<br/><br />
Simone Onofri<br/><br />
<br />
All the authors of theTesting Guide v3<br />
<br />
= Other Contributors =<br />
<br />
<br />
= Related articles =<br />
<br />
OWASP [[:Category:OWASP Testing Project|Testing Guide]]<br />
<br />
Mozilla [https://wiki.mozilla.org/WebAppSec/Web_Security_Verification Web Security Verification]<br />
<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]] [[Category:OWASP_Breakers]]</div>Simone onofrihttps://wiki.owasp.org/index.php?title=Web_Application_Security_Testing_Cheat_Sheet&diff=134088Web Application Security Testing Cheat Sheet2012-08-09T09:28:48Z<p>Simone onofri: </p>
<hr />
<div>= DRAFT CHEAT SHEET - WORK IN PROGRESS =<br />
<br />
= Introduction =<br />
<br />
This cheat sheet provides a checklist of tasks to be performed when performing a blackbox security test of a web application.<br />
<br />
= Purpose =<br />
<br />
This checklist is intended to be used as an aide memoire for experienced pentesters and should be used in conjunction with the [[:Category:OWASP Testing Project|OWASP Testing Guide]]. It will be updated as the [[OWASP_Application_Testing_guide_v4|Testing Guide v4]] is progressed.<br />
<br />
The intention is that this guide will be available as an XML document, with scripts that convert it into formats such as pdf, Media Wiki markup, HTML etc. <br />
<br />
This will allow it to be consumed within security tools as well as being available in a format suitable for printing.<br />
<br />
It is currently at a very early stage, but any feedback or offers of help will be appreciated.<br />
<br />
= The Checklist =<br />
<br />
== Information Gathering ==<br />
* Manually explore the site<br />
* Spider/crawl for missed or hidden content<br />
* Check for files that expose content, such as robots.txt, sitemap.xml, .DS_Store<br />
* Check the caches of major search engines for publicly accessible sites<br />
* Check for differences in content based on User Agent (eg, Mobile sites, access as a Search engine Crawler)<br />
* Perform Web Application Fingerprinting<br />
* Identify technologies used<br />
* Identify user roles<br />
* Identify application entry points<br />
* Identify client-side code<br />
* Identify multiple versions/channels (e.g. web, mobile web, mobile app, web services)<br />
* Identify co-hosted and related applications<br />
* Identify all hostnames and ports<br />
* Identify third-party hosted content<br />
<br />
== Configuration Management ==<br />
* Check for commonly used application and administrative URLs<br />
* Check for old, backup and unreferenced files<br />
* Check HTTP methods supported and Cross Site Tracing (XST)<br />
* Test file extensions handling<br />
* Test for security HTTP headers (e.g. CSP, X-Frame-Options, HSTS)<br />
* Test for policies (e.g. Flash, Silverlight, robots)<br />
* Test for non-production data in live environment, and vice-versa<br />
== Secure Transmission ==<br />
* Check SSL Version, Algorithms, Key length<br />
* Check for Digital Certificate Validity (Duration, Signature and CN)<br />
* Check credentials only delivered over HTTPS<br />
* Check session tokens only delivered over HTTPS<br />
* Check if HTTP Strict Transport Security (HSTS) in use<br />
== Authentication ==<br />
* Test for user enumeration<br />
* Test for authentication bypass<br />
* Test for bruteforce protection<br />
* Test password quality rules<br />
* Test remember me functionality<br />
* Test for autocomplete on password forms/input <br />
* Test password reset and/or recovery<br />
* Test CAPTCHA<br />
* Test multi factor authentication<br />
* Test for logout functionality presence<br />
* Test for cache management on HTTP (eg Pragma, Expires, Max-age)<br />
* Test for default logins<br />
* Test for user-accessible authentication history<br />
* Test for out-of channel notification of account lockouts and successful password changes<br />
* Test for consistent authentication across applications with shared authentication schema / SSO<br />
== Session Management ==<br />
* Establish how session management is handled in the application (eg, tokens in cookies, token in URL)<br />
* Check session tokens for cookie flags (httpOnly and secure)<br />
* Check session cookie scope (path and domain)<br />
* Check session cookie duration (expires and max-age)<br />
* Check session termination after a maximum lifetime<br />
* Check session termination after relative timeout<br />
* Check session termination after logout<br />
* Test to see if users can have multiple simultaneous sessions<br />
* Test session cookies for randomness<br />
* Confirm that new session tokens are issued on login, role change and logout<br />
* Test for consistent session management across applications with shared session management<br />
* Test for session puzzling<br />
* Test for CSRF and clickjacking<br />
== Authorization ==<br />
* Test for path traversal<br />
* Test for bypassing authorization schema<br />
* Test for vertical Access control problems (a.k.a. Privilege Escalation)<br />
* Test for horizontal Access control problems (between two users at the same privilege level)<br />
* Test for missing authorization<br />
== Data Validation ==<br />
* Test for Reflected Cross Site Scripting<br />
* Test for Stored Cross Site Scripting<br />
* Test for DOM based Cross Site Scripting<br />
* Test for Cross Site Flashing<br />
* Test for HTML Injection<br />
* Test for SQL Injection<br />
* Test for LDAP Injection<br />
* Test for ORM Injection<br />
* Test for XML Injection<br />
* Test for XXE Injection<br />
* Test for SSI Injection<br />
* Test for XPath Injection<br />
* Test for IMAP/SMTP Injection<br />
* Test for Code Injection<br />
* Test for Command Injection<br />
* Test for Overflow (Stack, Heap and Integer)<br />
* Test for Format String<br />
* Test for incubated vulnerabilities<br />
* Test for HTTP Splitting/Smuggling<br />
* Test for HTTP Verb Tampering<br />
* Test for Open Redirection<br />
* Test for Local File Inclusion<br />
* Test for Remote File Inclusion<br />
* Compare client-side and server-side validation rules<br />
* Test for NoSQL injection<br />
* Test for HTTP parameter pollution<br />
* Test for auto-binding<br />
== Denial of Service ==<br />
* Test for anti-automation<br />
* Test for account lockout<br />
* Test for HTTP protocol DoS<br />
== Business Logic ==<br />
* Test for feature misuse<br />
* Test for lack of non-repudiation<br />
* Test for trust relationships<br />
* Test for integrity of data<br />
* Test segregation of duties<br />
== Risky Functionality - File Uploads ==<br />
* Test that acceptable file types are whitelisted<br />
* Test that file size limits, upload frequency and total file counts are defined and are enforced<br />
* Test that file contents match the defined file type<br />
* Test that all file uploads have Anti-Virus scanning in-place.<br />
* Test that unsafe filenames are sanitised<br />
* Test that uploaded files are not directly accessible within the web root<br />
* Test that uploaded files are not served on the same hostname/port<br />
* Test that files and other media are integrated with the authentication and authorisation schemas<br />
== Risky Functionality - Card Payment ==<br />
* Test whether card number are stored<br />
* TBC<br />
== HTML 5==<br />
* Test Web Messaging<br />
* Test for Web Storage SQL injection<br />
<br />
= Authors and primary contributors =<br />
<br />
[[User:Simon Bennetts|Simon Bennetts]]<br/><br />
[[User:Raesene|Rory McCune]] <br/><br />
Colin Watson<br/><br />
All the authors of theTesting Guide v3<br />
<br />
= Other Contributors =<br />
<br />
<br />
= Related articles =<br />
<br />
OWASP [[:Category:OWASP Testing Project|Testing Guide]]<br />
<br />
Mozilla [https://wiki.mozilla.org/WebAppSec/Web_Security_Verification Web Security Verification]<br />
<br />
{{Cheatsheet_Navigation}}<br />
<br />
[[Category:Cheatsheets]] [[Category:OWASP_Breakers]]</div>Simone onofri