Turkey Web Security Community - webguvenligi.

org

Web 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 b applications. It targets mainly auditors but is helpful for application developers, IT-architects, project managers, system administr 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 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 Lev 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 securi The security flag enables to display the security status of an IT-system visually with graphics for different categories as well as control is out-of-scope for the relevant system (e.g. web services are not implemented within the system), its status is assigned a evaluated for graphics. For your comments and suggestions, you can contact us via checklist(at)webguvenligi.org

Contributors 2012 v2 2010 v1 Bnyamin Demir, Emin slam Tatl, Onur Ylmaz, Emre Sren, Ouzhan Topgl

Bedirhan Urgun, Bnyamin Demir, Onur Ylmaz, Kubilay Onur Gngr, A. Kadir A Aydn, Canberk Bolat

Translations English

Emin slam Tatl

Community - webguvenligi.org

n Security Check List January 2012

urkey. It provides 61 security controls that need to be integrated within web s, IT-architects, project managers, system administrators and database administrators al representation support.

he second and current version of the check list was published with many enhancements

n Security Verification Standard) Category, Risk Level and Status sections. ting Guide. WASP ASVS is assigned. ch security control. is used for tracking activation status of each security control. ally with graphics for different categories as well as for overall system. If a security emented within the system), its status is assigned as "---" and it would not be

guvenligi.org

, Onur Ylmaz, Emre Sren, Ouzhan Topgl

, Onur Ylmaz, Kubilay Onur Gngr, A. Kadir Altan, Volkan Altan, Muharrem

No
1 2 3 4

Category
Information Gathering Information Gathering Information Gathering Information Gathering

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Configuration Management Configuration Management Configuration Management Configuration Management Configuration Management Configuration Management Configuration Management Configuration Management Configuration Management Authentication Authentication Authentication Authentication Authentication Authentication Authentication Authentication Authentication Session Management Session Management Session Management

26 27 28 29

Session Management Session Management Session Management Session Management

30 31 32 33 34 35 36 37 38 39 40 41 42 43

Session Management Authorization Authorization Authorization Authorization Authorization Authorization Authorization Authorization Business Logic Business Logic Business Logic Business Logic Business Logic

44 45 46 47 48 49 50 51 52 53 54 55 56 57

Business Logic Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation Data Validation

58 59

Denial of Service Denial of Service

60 61

Web Services Web Services

Control
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. Directory listing should be disabled on application and web servers. 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. All HTTP methods except GET and POST should be disabled if they are not in use. 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. Default user accounts should be removed from applications, systems and databases. 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. SSL renegotiation feature should be disabled against DoS and MITM attacks. 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. Salt value should be used as well by the generation of password hashes. Users should be forced to change their initial password, which they get within an envelope or via email, by their first access to system. All critical activities within applications should be logged at application and server levels. 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. An inactivity timeout should be set up for sessions. 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. After successful authentication operations, users should be redirected via HTTP 302 to internal pages.

Responsibility
SA D SA SA D SA SA SA D D D D SA SA SA SA SA SA SA D D D D D D D D D D SA SA SA D D D D D SA SA SA SA SA SA SA SA SA SA SA

Logout links should be available within all pages of accessed applications. 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. User inputs regarding file access operations should be normalized and validated. 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). User inputs used for LDAP queries should be sanitized before connection. User inputs used for XPath queries should be sanitized. 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. 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.

D D SA SA SA D SA SA SA D D D D

SA

SA D D D D D D D D D D D D D

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.

D D D SA SA

Responsibility ASVS
DA Data Protection Error Handling and Logging Access Control Access Control

Risk Level Status

Medium Medium Medium Medium ---------

Data Protection Access Control Access Control Data Protection DA Authentication Session Management Cryptography Access Control Cryptography Cryptography Data Protection Communication Security Authentication Cryptography Authentication Error Handling and Logging Authentication Authentication Session Management Session Management Session Management

Critical Medium High High High High High Medium High Critical Critical Critical High High High Critical High High Critical High High

-------------------------------------------

Access Control Session Management Session Management Session Management

High High High Medium

---------

Session Management Access Control Access Control DA DA Access Control Access Control Access Control Access Control Access Control Access Control Authentication Authentication Authentication Access Control Data Protection

Medium Critical High High High High Medium High High High Medium High Medium High

-----------------------------

Data Protection Input Validation Output Encoding/Escaping Output Encoding/Escaping Output Encoding/Escaping Input Validation Output Encoding/Escaping Input Validation Input Validation Output Encoding/Escaping Output Encoding/Escaping Input Validation Output Encoding/Escaping Input Validation

High High Critical Critical High High High High High High High High Medium High

-----------------------------

Authentication Input Validation

High Medium

-----

Authentication Output Encoding/Escaping

Critical High

-----

Yes No

Yes No

0 0

Yes No

0 0

Yes No

0 0

Yes

No

Yes No

0 0

Yes No

0 0

Yes No

0 0

Yes No

0 0

Yes No

0 0

0 0

Information Gathering
0% Yes
No

Configuration Management
0%

Session Management
0% Yes No

Authorization
0%

Data Validation
0% Yes No

0% 0%

Denial of Service

Total Result
0%

figuration Management

Authentication
0%

Yes

No

Yes No

Authorization

Business Logic
0% Yes No Yes No

enial of Service

Web Services
0% Yes No Yes No

Total Result

Yes

No

Information Gathering Configuration Management Authentication Session Management Authorization Business Logic Data Validation Denial of Service Web Services

Categories

V1 - Security Architecture Documentation Requirements V2 - Authentication Verification Requirements V3 - Session Management Verification Requirements V4 - Access Control Verification Requirements V5 - Input Validation Verification Requirements V6 - Output Encoding/Escaping Verification Requirements V7 - Cryptography Verification Requirements V8 - Error Handling and Logging Verification Requirements V9 - Data Protection Verification Requirements V10 - Communication Security Verification Requirements V11 - HTTP Security Verification Requirements V12 - Security Configuration Verification Requirements V13 - Malicious Code Search Verification Requirements V14 - Internal Security Verification Requirements

ASVS

System Administrator (SA) Database Administrator (DA) Developer (D)

Responsible

Risk Level
Critical (4) High (3) Medium (2) Low (1)