Web App Sec Checklist 2012 En

  • View
    37

  • Download
    4

Embed Size (px)

Text of Web App Sec Checklist 2012 En

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

No1 2 3 4

CategoryInformation 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

ControlCritical 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.

ResponsibilitySA 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 exclu