1.OBJECTIVE: This document has been drawn up to specific rules required to be complied by all software developers, database and system administrator and all steps required to be controlled in order to ensure complete security of application software developed and being developed at ZSR Patlayıcı San. A.Ş.

2. SCOPE: This policy contains all rules required to be complied by all academic and administrative personnel that conduct activities such as development, maintenance and support of the applications developed by the Data Processing Department of ZSR Patlayıcı San. A.Ş. (e.g. web pages, desktop applications, web automations, etc.).

3. OFFICIERS: Web applications in different departments of our company as well as all kinds of infrastructure, hardware and software services required by the academic and administrative departments for any matter in the field of information systems are conducted by Data Processing Department. 

4. APPLICATIONS: Control steps under the following categories of the software products (applications) put into use at ZSR Patlayıcı San. A.Ş. should be verified. Otherwise, concrete indicators for safety of applications would not be available. These categories are listed below under 9 headings:

Data Protection Fault Management and Recording

• Access Control

• Identity Check

• Session Management

• Cryptology

• Communication Security

• Input Control

• Output Coding

4.1.Any data recorded or used by Data Protection Applications should be closed for unauthorized access. To this end, the following steps should be controlled:

4.1.1. Critical information about system components of web, application and database servers (server name and release, program release used, etc.) should be hidden.

4.1.2. Security patches of software used such as application frame, database, application server and web server should be of highest level.

4.1.3. Security features of the application frames used such as ASP.NET, PHP, STRUTS should be activated.

4.1.4. Sensitive data such as passwords used and check questions and answers should not be hidden as open text.

4.1.5. When the applications are transferred from the development environment to the production environment, unnecessary files (e.g. test codes, demo programs, backup files) should be deleted; source code should, if not necessary, be transferred and comment lines in the source codes to be transferred should be deleted. It should be guaranteed that no unwanted change is made in the files during transfer process.

4.2. Fault Management and Logging Applications. When fault is received or any unexpected event occurs, the technical details and logging records concerning faults in the fault messages generated during operation should not be opened to the final user.

4.2.1. Faults occurred during application and predefined fault messages in the application server should not be shown to the user clearly. Document No: KP-05 Issued on: 27.04.2019 REV.NO:00 REV.TAR:00

4.2.2. Critical operations made via application should be recorded both on application level and server level.

4.3. Access Control. No source such as contents, directories, server interfaces, etc. released by the applications should be accessible in an uncontrolled way.

4.3.1. Servers on which the applications run should not list contents of the directories to which they serve.

4.3.2. If there are directories which should not be displayed by the research engines, precaution should be taken for them with robots.txt. However, In order that the links / directories (e.g. administration page) not bridged in the page should not present any security problems, robots.txt file should not be added.

4.3.3. HTTP methods, except for POST/GET, should not be allowed if not required.

4.3.4. Access to the files not necessary for the main system (e.g. files used for backup, archive, test and development) should be prevented and unnecessary applications in the system (e.g. predefined server pages, demo applications) should be removed.

4.3.5. It should be controlled whether policies applied in the configuration files of crossdomain.xml for Flash applications and clientaccesspolicy.xml for SilverLight applications are secure or not.

4.3.6. For critical actions, security precautions such as “token” or “CAPTCHA” should be taken against CSRF attacks.

4.3.7. HTTP parameters in the GET and POST requests should be changed to prevent unauthorized access to the data of third parties.

4.3.8. Authorizations of the system user operating the application should be removed except for those of directory served.

4.3.9. Database user should have access right only to the database sources used by the application.

4.3.10. Database user should be entitled to connect to the database only via IP address of the application server.

4.3.11. In order to prevent Race-Conditions, simultaneous access should not be allowed by synchronization with the critical sources objects and methods.

4.3.12. Access to the applications which are on the server and provide web-based statistics should not be accessible by everybody.

4.3.13. Access to all URL’s, functions, object references, services, application data, user info and security configuration files which require restricted access should be controlled.

4.3.14. In cases when right of authorization is not required (e.g. abandonment of company, change of role in the project, etc.), related rights should be cancelled as soon as possible.

4.3.15. Names of the critical directories such as administration panel should not be easily estimated (admin, administrator, management, panel, etc.).

4.4. Identity Test. Each source opened for access should also use method of identity control.

4.4.1. Predefined user accounts should be removed from the system, database and application.

4.4.2. Identity authentication should be bate on the part of service for access to all special sources and pages.

4.4.3. All controls for authentication of user name and password should prevent attacks of user names listing by giving one type of fault message. For example, one fault message may be “User name and/or password you entered is not correct.”

4.4.4. All successful and failed login actions and attempts of access to the sources should be recorded.

4.4.5. Former password should always be prompted for password updating actions.

4.4.6. The forms I forgot password should be supported by hidden question and similar additional arguments.

4.4.7. E-mail message sent to the user after ‘I forgot password’ actions should not contain user name and password information. Instead, a link with a limited lifetime should be sent and password changing action should be performed from the page to be opened via that link.