Embed Size (px)
Citation preview
Contributors
2012 v2 Bünyamin Demir, Emin İslam Tatlı, Onur Yılmaz, Emre Süren, Oğuzhan Topgül
2010 v1
TranslationsEnglish Emin İslam Tatlı
Turkey Web Security Community - webguvenligi.orgWeb Application Security Check List
v2.0 - January 2012
Web Application Security Check List is a documentation project of OWASP Turkey. It provides 61 security controls that need to be integrated within web applications. It targets mainly auditors but is helpful for application developers, IT-architects, project managers, system administrators and database administrators as well. The security controls are integrated within an Excel-tool with graphical representation support.
The first version of the check list was published in 2010 in Turkish whereas the second and current version of the check list was published with many enhancements in January 2012 in Turkish and English.
The main characteristics of the check list are as follows:
• Each security control has Category, Responsible Person, ASVS (Application Security Verification Standard) Category, Risk Level and Status sections.• The categories of the check list are based on the categories of OWASP Testing Guide.• For each security control in the checklist, a verification requirement from OWASP ASVS is assigned.• Risk levels (Critical-High-Medium-Low) are used for defining criticality of each security control.• A tool in Excel was implemented for the check list. A status flag (Yes/No/---) is used for tracking activation status of each security control.• The security flag enables to display the security status of an IT-system visually with graphics for different categories as well as for overall system. If a securitycontrol is out-of-scope for the relevant system (e.g. web services are not implemented within the system), its status is assigned as "---" and it would not be evaluated for graphics.
For your comments and suggestions, you can contact us via checklist(at)webguvenligi.org
Bedirhan Urgun, Bünyamin Demir, Onur Yılmaz, Kubilay Onur Güngör, A. Kadir Altan, Volkan Altan, Muharrem Aydın, Canberk Bolat
Bünyamin Demir, Emin İslam Tatlı, Onur Yılmaz, Emre Süren, Oğuzhan Topgül
Emin İslam Tatlı
Turkey Web Security Community - webguvenligi.orgWeb Application Security Check List
v2.0 - January 2012
Web Application Security Check List is a documentation project of OWASP Turkey. It provides 61 security controls that need to be integrated within web applications. It targets mainly auditors but is helpful for application developers, IT-architects, project managers, system administrators and database administrators as well. The security controls are integrated within an Excel-tool with graphical representation support.
The first version of the check list was published in 2010 in Turkish whereas the second and current version of the check list was published with many enhancements
Each security control has Category, Responsible Person, ASVS (Application Security Verification Standard) Category, Risk Level and Status sections.The categories of the check list are based on the categories of OWASP Testing Guide.For each security control in the checklist, a verification requirement from OWASP ASVS is assigned.Risk levels (Critical-High-Medium-Low) are used for defining criticality of each security control.A tool in Excel was implemented for the check list. A status flag (Yes/No/---) is used for tracking activation status of each security control.The security flag enables to display the security status of an IT-system visually with graphics for different categories as well as for overall system. If a security
control is out-of-scope for the relevant system (e.g. web services are not implemented within the system), its status is assigned as "---" and it would not be
For your comments and suggestions, you can contact us via checklist(at)webguvenligi.org
Bedirhan Urgun, Bünyamin Demir, Onur Yılmaz, Kubilay Onur Güngör, A. Kadir Altan, Volkan Altan, Muharrem
No Category
1 Information Gathering
2 Information Gathering
3 Information Gathering4 Information Gathering
5 Configuration Management
6 Configuration Management
7 Configuration Management
8 Configuration Management
9 Configuration Management
10 Configuration Management
11 Configuration Management
12 Configuration Management
13 Configuration Management14 Authentication
15 Authentication
16 Authentication
17 Authentication
18 Authentication19 Authentication
20 Authentication
21 Authentication
22 Authentication
23 Session Management
24 Session Management25 Session Management
26 Session Management
27 Session Management
28 Session Management
29 Session Management
30 Session Management31 Authorization
32 Authorization
33 Authorization
34 Authorization
35 Authorization
36 Authorization
37 Authorization
38 Authorization
39 Business Logic
40 Business Logic
41 Business Logic
42 Business Logic
43 Business Logic
44 Business Logic
45 Data Validation
46 Data Validation
47 Data Validation
48 Data Validation
49 Data Validation
50 Data Validation
51 Data Validation
52 Data Validation
53 Data Validation54 Data Validation55 Data Validation
56 Data Validation
57 Data Validation
58 Denial of Service
59 Denial of Service
60 Web Services
61 Web Services
Control Responsibility
SA
D SA
Directory listing should be disabled on application and web servers. SA
D SA
SA
All HTTP methods except GET and POST should be disabled if they are not in use. SA
D SA
D SA
Default user accounts should be removed from applications, systems and databases. D SA
D SA
SA
SA
SSL renegotiation feature should be disabled against DoS and MITM attacks. SA
D SA
D
D SA
D SA
Salt value should be used as well by the generation of password hashes. D SA
D SA
All critical activities within applications should be logged at application and server levels. D SA
D
D SA
D SA
An inactivity timeout should be set up for sessions. SA
D SA
D SA
D SA
D SA
Critical information about system components (e.g. server name, version, installed program versions, etc.) of web, application and database servers should be obscured and not revealed via HTTP responses or error messages.Error messages of web applications and application-server default error messages should not be displayed in details to clients.
Sensitive links which should not be indexed by search engines should be listed within robots.txt files. On the other hand, if a critical webpage (e.g. administration panel) is not explicitly linked within the web application, it should not be included within robot.txt files as well.
All latest patches should be installed for application frameworks, application servers, database and web servers as soon as possible they are available.
Access to non-public resources (e.g. backup files, development test files) should be restricted for certain users and unnecessary applications (e.g. default web server sites, demo applications) should be removed.Security features of application frameworks (e.g. ASP.NET, PHP, STRUTS) should be enabled.
HTTP/HTML attributes (e.g. autocomplete, cache-control, pragma) should be enabled and configured accordingly to prevent storage of sensitive information like passwords within caches.Weak SSL algorithms should be disabled and only secure algorithms should be allowed for secure communication over SSL.Cross-Domain policies (for Flash crossdomain.xml and for SilverLight clientaccesspolicy.xml) should be configured in a secure manner. Allowing access to all domains should be prevented if not required.
Only strong and complex passwords should be allowed for administrators and clients to use.Passwords and secret question-answer of password retrieval functions should never be stored in plain text.Any critical data (e.g. password, credit card, personal data) should be exchanged between clients and servers only over secure HTTPS protocol.Authentication and authorization should be performed on server-side for any access to non-public resources.
Users should be forced to change their initial password, which they get within an envelope or via email, by their first access to system.
A common message should be used for authentication failures to prevent user enumeration attacks. An example of such a message would be "Username and/or Password is wrong".All successful and unsuccessful authentication attempts and access attempts to resources should be logged.Unique values (e.g. session identifiers, token etc.) used for session management should be generated via secure random number generators.
After each authentication and reauthentication, a new session id should be created and the old session id should be invalidated. After logging out, the session id should be invalidated as well.
Solutions like tokens, captchas should be integrated for critical operations in order prevent Cross-Site-Request-Forgery (CSRF) attacks.The domain and path for cookies containing authenticated session identifiers should be set to an appropriately restricted value for the site.httponly attribute should be set on cookies. In addition, secure attribute should be set on cookies for HTTPS communications.
D SA
Logout links should be available within all pages of accessed applications. D
D
SA
SA
SA
D
SA
SA
SA
D
D
D
D
D SA
SA
D
D
D
D
D
User inputs regarding file access operations should be normalized and validated. D
D
D
User inputs used for LDAP queries should be sanitized before connection. D
User inputs used for XPath queries should be sanitized. D
D
After successful authentication operations, users should be redirected via HTTP 302 to internal pages.
Parameter manipulations within GET/POST requests should be taken into consideration and unauthorized access to legal user resources by attackers should be prevented.
A System user that owns an application process should have access right only to the directory of the application.Database user should have access only to the database resources that are used by the application.Database user should be able access to the database server only through the relevant application server IP address.Synchronization mechanisms over critical resources, objects and methods should be implemented to prevent race-conditions.Web-based statistics applications installed on servers should only be accessible for authorized users. Restricted URLs, functions, object references, services, application data, user information and security configuration files should be accessible for authorized users and roles.
If a user does not need an access right anymore (e.g. leaving company, changing role within the project), the access right should be withdrawn as soon as possible.
The current password should always be asked to users for password change functionalities.Password retrieval functionalities should be supported with secret questions and similar arguments.Password retrieval functionalities should not send user names and passwords back within emails. Instead, a link with certain lifetime should be sent that prompts a dialog for password change.Names of critical directories like administration panels should not be easily guessable (e.g. admin, administration). When applications are transferred from a development/integration environment into a production environment, unnecessary resources (e.g. test codes, demo applications, backup files) should be excluded. Source files should be excluded as well if they are not required. Comments should be removed from source files. Integrity of transferred files should be checked and guaranteed.
It should be checked if sensitive files and resources belonging to application domain are not indexed via Google/Bing search engines and not accessible to third parties.
All user inputs should be validated on server-site. White-lists should be preferred for validation instead of black-lists. Each input should be encoded to a common character set before validation (canonicalization).User inputs should be escaped and validated before using as a part of command execution.Prepared statement, parameterized query, bind variables and whitelist data validation should be implemented to prevent SQL injection attacks.Output Escaping/Encoding should be applied on all user inputs before they are displayed on their screens. For additional security, user inputs can be checked for type, length and content.User inputs regarding arithmetic operations should be checked and validated for minimum and maximum values.
By the operation of a file upload, name, length, type and content of the file should be checked.User inputs used for HTTP redirects should be validated by using whitelist method to prevent phishing attacks (open redirect problem).
CR/LF characters sent within user inputs should not be directly appended within HTTP Responses on the application side (CRLF injection attack). User inputs should be properly sanitized.
D
D
D
D
D SA
SA
Appropriate solutions against frame busting and clickjacking attacks should be implemented within web applications.Penetration testing of a web application should be performed before the application becomes online.CAPTCHA or similar anti-automation security controls should be implemented within HTML forms to prevent DoS, brute-forcing and dictionary attacks.
A timeout for search functionalities should be enabled against SQL Wildcard attacks which force databases to perform CPU-intensive queries by using several search wildcards like "%" or "*".
Authentication should be activated for accessing to web services implemented with SOAP, Restful, XML-RPC or similar technologies.
Web services implemented by using common frameworks should be secured against typical XML attacks (e.g. external entity, a billion laughs, XML bomb, etc.) and parameter manipulation attacks.
Responsibility ASVS Risk Level Status
DAMedium ---
Error Handling and Logging Medium ---
Access Control Medium ---Access Control Medium ---
Critical ---
Access Control Medium ---
Access Control High ---
High ---
DA Authentication High ---
Session Management High ---
Cryptography High ---
Access Control Medium ---
Cryptography High ---Cryptography Critical ---
Critical ---
Communication Security Critical ---
Authentication High ---
Cryptography High ---Authentication High ---
Error Handling and Logging Critical ---
Authentication High ---
Authentication High ---
Session Management Critical ---
Session Management High ---Session Management High ---
Access Control High ---
Session Management High ---
Session Management High ---
Data Protection
Data Protection
Data Protection
Data Protection
Session Management Medium ---
Session Management Medium ---Access Control Critical ---
Access Control High ---
DA Access Control High ---
DA Access Control High ---
Access Control High ---
Access Control Medium ---
Access Control High ---
Access Control High ---
Authentication High ---
Authentication Medium ---
Authentication High ---
Access Control Medium ---
Data Protection High ---
Data Protection High ---
Input Validation High ---
Output Encoding/Escaping Critical ---
Output Encoding/Escaping Critical ---
Output Encoding/Escaping High ---
Input Validation High ---
Output Encoding/Escaping High ---
Input Validation High ---
Input Validation High ---
Output Encoding/Escaping High ---Output Encoding/Escaping High ---Input Validation High ---
Output Encoding/Escaping Medium ---
Input Validation High ---
Authentication High ---
Input Validation Medium ---
Authentication Critical ---
Output Encoding/Escaping High ---
Yes
No
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
Yes 0
No 0
0
0
Information Gathering
YesNo
Configuration Management
Yes No
Session Management
Yes No
Authorization
Yes No
Data Validation
YesNo
Denial of Service
YesNo
Total Result
YesNo
Configuration Management
Yes No
Authentication
Yes No
Authorization
Yes No
Business Logic
Yes No
Denial of Service
YesNo
Web Services
Yes No
Total Result
YesNo
CategoriesInformation GatheringConfiguration Management
AuthenticationSession ManagementAuthorizationBusiness LogicData ValidationDenial of Service
Web Services
ASVSV1 - Security Architecture Documentation RequirementsV2 - Authentication Verification Requirements
V3 - Session Management Verification RequirementsV4 - Access Control Verification RequirementsV5 - Input Validation Verification RequirementsV6 - Output Encoding/Escaping Verification RequirementsV7 - Cryptography Verification RequirementsV8 - Error Handling and Logging Verification Requirements
V9 - Data Protection Verification RequirementsV10 - Communication Security Verification RequirementsV11 - HTTP Security Verification RequirementsV12 - Security Configuration Verification RequirementsV13 - Malicious Code Search Verification RequirementsV14 - Internal Security Verification Requirements
Responsible Risk LevelSystem Administrator (SA) Critical (4)Database Administrator (DA) High (3)
Developer (D) Medium (2)Low (1)
