Web Security Guidelines

1. Introduction

In today's digital age, the internet has become an integral part of our everyday lives, connecting people and businesses across the globe. With the rapid expansion of web-based services, ensuring the security of websites, applications, and user data has become more crucial than ever. This document aims to provide a comprehensive set of guidelines to help developers, administrators, and organizations implement effective web security measures to safeguard against potential threats and vulnerabilities.

The importance of web security cannot be overstated, as data breaches, identity theft, and cyberattacks have the potential to cause significant financial and reputational damage to individuals and businesses alike. Therefore, adhering to the best practices outlined in these guidelines is critical to maintaining a secure online environment.

This document covers key web security concepts, common threats and vulnerabilities, and best practices for designing, developing, and maintaining secure web applications. The guidelines provided in this document are based on industry standards and best practices, as well as recommendations from respected organizations such as the Open Web Application Security Project (OWASP) and the National Institute of Standards and Technology (NIST).

It is important to note that web security is an ongoing process that requires regular monitoring, updating, and adapting to emerging threats and technologies. By adhering to these guidelines and adopting a proactive approach to web security, you can significantly reduce the risk of attacks and protect your online assets.

2. Scope

These Web Security Guidelines encompass various aspects of web security, catering to a wide range of audiences involved in the development, deployment, and maintenance of web applications and services. The scope of this document includes, but is not limited to:

1. Web application security: Addressing common vulnerabilities, attack vectors, and best practices for secure design, development, and deployment of web applications, including authentication, authorization, input validation, session management, and data protection.
2. Infrastructure and network security: Providing guidance on securing the underlying infrastructure that hosts web applications, including server hardening, secure configuration, network segmentation, and monitoring.
3. Secure coding practices: Emphasizing the importance of incorporating security throughout the development lifecycle, from planning to deployment, and offering recommendations for secure coding techniques and tools.
4. Security testing and assessment: Outlining approaches considering OWASP standards to identify and remediate vulnerabilities in web applications and infrastructure, including vulnerability scanning, penetration testing, and security audits.

Please note that while these guidelines strive to provide comprehensive and up-to-date information, they cannot cover every possible scenario or threat. Therefore, it is essential to continually update your knowledge, stay informed about emerging threats, and adapt your web security practices accordingly.

Note: Guidelines marked with ** is only applicable for application/systems which are not using centralized Identity management solutions like Okta or Active Directory

3. Security Guidelines

3.1 Session Management

3.1.1? ?Ensure That Session Identifiers Are Sufficiently Random, Session tokens must be generated by secure random functions and must be of a sufficient length so as to withstand analysis and prediction.

3.1.2? ?Regenerate Session Tokens, Session tokens should be regenerated when the user authenticates to the application and when the user privilege level changes. Additionally, should the encryption status change, the session token should always be regenerated.

3.1.3? ?Implement an Idle Session Timeout, when a user is not active, the application should automatically log the user out. Be aware that Ajax applications may make recurring calls to the application effectively resetting the timeout counter automatically. Below are the recommended timeout periods.

• 15 minutes for high security applications
• 30 minutes for medium security applications
• 1 hour for low security applications

3.1.4? ?Implement an Absolute Session Timeout, Users should be logged out after an extensive amount of time (e.g., 4-8 hours) has passed since they logged in. This helps mitigate the risk of an attacker using a hijacked session.

3.1.5? ?Destroy Sessions at Any Sign of Tampering, Unless the application requires multiple simultaneous sessions for a single user, implement features to detect session cloning attempts. Should any sign of session cloning be? ? ? ? ? ? detected, the session should be destroyed, forcing the real user to re-authenticate.

3.1.6? ?Invalidate the Session after Logout, when the user logs out of the application the session and corresponding data on the server must be destroyed. This ensures that the session cannot be accidentally revived.

3.1.7? ?Place a Logout Button on Every Page, the logout button or logout link should be easily accessible to the user on every page after they have authenticated.

3.1.8? ?Cookies shall not be used to obtain sensitive, private or confidential information, users shall be made aware of the fact that cookies are used, and users shall be able to delete cookies, if wanted

3.1.9? ?Use Secure Cookie Attributes (HttpOnly, Secure and SameSite Flags), the session cookie should be set with both the HttpOnly and the Secure flags. This ensures that the session id will not be accessible to client-side scripts,? ? ? and it will only be transmitted over HTTPS, respectively. In addition, the SameSite attribute should be set to with either lax or straight mode to reduce the risk of Cross Site Request Forgery

3.1.10? ?Set the Cookie Expiration Time, the session cookie should have a reasonable expiration time. Non-expiring session cookies should be avoided

3.1.11? ?Third party cookies shall be evaluated before being allowed to be used for web sites and applications

3.1.12? ?Unless required, cookies associated with subdomains shall be stored at subdomain level

3.2 Data Protection and Storage

3.2.1 Use HTTPS Everywhere, SSL/HTTPS access to all pages shall be enforced, and any links on sites shall be HTTPS links. If higher levels of security are required based on the results of the risk assessment, at a minimum TLS shall be enforced.

3.2.2 Use the Strict-Transport-Security Header, The Strict-Transport-Security header ensures that the browser does not talk to the server over HTTP. This helps reduce the risk of HTTP downgrade attacks as implemented by the SSL sniff tool.

3.2.3 The login session shall be encrypted using TLS1 (other types of encryption can be used in case of higher security requirements, based on the risk assessment results). Obsolete or vulnerable sessions being prone to security downgrades shall not be used.

3.2.4 All administrative access to databases via the front-end interfaces shall be encrypted.

3.2.5 Disable Data Caching Using Cache Control Headers and Autocomplete, Browser data caching should be disabled using the cache control HTTP headers or meta tags within the HTML page. Additionally, sensitive input fields, such as the login form, should have the autocomplete=off setting in the HTML form to instruct the browser not to cache the credentials.

3.2.6 **Store User Passwords Using a Strong, Iterative, Salted Hash. User passwords must be stored using secure hashing techniques with strong algorithms like PBKDF2, bcrypt, or SHA-512. Simply hashing the password a single time does not sufficiently protect the password. Use adaptive hashing (a work factor), combined with a randomly generated salt for each user to make the hash strong.

3.2.7 Database content and app data shall be encrypted based on the results of data governance assessment.

3.2.8 Securely handle file uploads and storage: Ensure uploaded and stored files are not accessible through the interface they were uploaded from. Generate non-guessable, non-configurable file names, and follow documented naming conventions. Do not reveal file paths to users, and prevent the execution of files in the storage directory.

3.2.9 Uploaded files shall be securely stored in a directory that is inaccessible through the interface they were uploaded, ensuring that the file path is not revealed to the user.

3.2.10 To maintain security and prevent unauthorized access, uploaded files shall undergo a validation process to ensure their validity based on the stated file extension, checked mime type, verified content type, allowed file types, and sizes. Additionally, the files shall be assigned new names that follow documented conventions, ensuring that the new names are not guessable or resemble configuration file names.

3.3 Identity Management

3.3.1 Identity Management, integrate application with centralized identity and access management tool like Active Directory or Okta for authentication and user account management. Avoid local user accounts.

3.3.2 **User IDs shall not be incremented.

3.3.3 The use of external non-government identity providers shall be avoided, where possible.

3.3.4 Business to Consumer (B2C) accounts, use identity provider like Okta Customer Identity or Azure AD B2C for managing B2C user accounts. Local accounts should be avoided in all cases unless legacy system limitation.

3.3.5 Account lifecycle, user account provisioning, update, and deletion should be managed through the identity provider.

3.3.6 **Account provisioning process should include validation of provided email id or mobile number before account activation.

3.3.7 **Password complexity, Implement organization approved Password complexity for application local account. Refer to section 2.3.1 under Cybersecurity & Resilience Policy Manual v3.0 for password complexity details.

3.3.8 **Registration to 3rd party MFA provider like Microsoft Authenticator to be enforced during the user account activation process.

3.4 Authentication

3.4.1? ?**Develop a Strong Password Reset System, Password reset systems shall include sending link over registered email id, additionally verification to be done using OTP. Additionally, any password reset option must not reveal whether or not an account is valid, preventing username harvesting.

3.4.2? ?**User shall be sent an email at the pre-registered email address if his/her account is locked, or password is reset/change

3.4.3? ?**Implement Account Lockout against Brute Force Attacks, account lockout needs to be implemented to guard against brute forcing attacks against both the authentication and password reset functionality. After 5 consecutive failed attempts on a specific user account, the account should be locked for a period of time or until manually unlocked

3.4.4? ?Login error messages shall be generic in nature to prevent user ID enumeration or password brute force. E.g., Username or Password is invalid

3.4.5? ?**Multifactor authentication shall be used

3.4.6? ?CAPTCHA or HIP controls shall be implemented on the login page to prevent brute force attacks

3.4.7? ?Store Database Credentials and API keys Securely, Modern web applications usually consist of multiple layers. The business logic tier (processing of information) often connects to the data tier (database). The authentication credentials in the business logic tier must be stored in a centralized location that is locked down. The same applies to accessing APIs providing services to support your application.

3.4.8? ?Applications and Middleware Should Run with Minimal Privileges, If an application becomes compromised it is important that the application itself and any middleware services be configured to run with minimal privileges. For instance, while the application layer or business layer needs the ability to read and write data to the underlying database, administrative credentials that grant access to other databases or tables should not be provided

3.5 Access Control

3.5.1? ?Apply the Principle of Least Privilege, all access decisions will be based on the principle of least privilege. If not explicitly allowed, then access should be denied

3.5.2? ?Authorization controls shall be enforced on every request to the application or site

3.5.3? ?Authorization to access any resource (including files, protected URLs, protected functions, services and application data) shall be verified prior to granting access to that resource. Only trusted resources shall be accessed

3.5.4? ?Cross-Origin Resource Sharing (CORS) implementation shall follow strict rules of allowing only authorized nodes to access the resources

3.5.5? ?Access by external parties such as (developers, system engineers, support) shall not be granted on production servers. If such access is necessary, it shall only be provided for a set pre-determined timeframe with justification and following Cyber Security approval

3.5.6? ?Access permission shall be managed through Active Directory security groups instead of direct permission assignment

3.6 Input and Output Handling

3.6.1? ?Validate input on Client and Server side, Client-side validation can help catch errors before they are sent to the server, but it should not be relied upon as the only form of validation, since attackers can bypass it. Server-side validation is essential for security, as it checks all data coming from the client

3.6.2? ?Use a whitelist approach, define a strict set of allowed characters or input patterns and reject any input that does not match this criteria. This is a more secure method than using a blacklist, which attempts to block only known malicious inputs

3.6.3? ?Validate Uploaded Files, when accepting file uploads from the user make sure to validate the size of the file, the file type, and the file contents as well as ensuring that it is not possible to override the destination path for the file

3.6.4? ?Limit input length, restrict the length of user input to avoid buffer overflow attacks or excessive resource consumption

3.6.5? ?Encode data with a consistent character set (e.g., UTF-8) prior to validation

3.6.6? ?Canonicalize input data, before validating input, convert it into a canonical form (e.g., by decoding URL-encoded characters) to prevent bypassing validation using different character representations

3.6.7? ?Use prepared statements or parameterized queries, this helps prevent SQL injection attacks by separating user input from SQL code, ensuring that the input is treated as data and not executable code

3.6.8? ?Use tokens to prevent forged requests (CSRF protection), to prevent attackers from submitting unauthorized requests on behalf of your users, implement a CSRF protection mechanism. This typically involves generating unique, random tokens for each user session and including these tokens in forms or requests. On the server-side, validate the tokens for each incoming request to ensure that it originates from a legitimate source

3.7 Configuration and Operations

3.7.1? ?Harden the Infrastructure, all components of infrastructure that support the application should be configured according to security best practices and hardening guidelines. All services, ports and accounts unnecessary for the actions carried out shall be disabled. Apply Geo-Fence, WAF, LB wherever applicable.

3.7.2? ?Use Valid HTTPS Certificates, HTTPS certificates should be signed by a reputable certificate authority. The name on the certificate should match the FQDN of the website. The certificate itself should be valid and not expired

3.7.3? ?The debugging function shall be disabled

3.7.4? ?Version numbers or details that may lead to the discovery of vulnerabilities shall not be exposed

3.7.5? ?Web configuration files (where applicable) shall be encrypted and any server-side configuration files shall have proper access permissions

3.7.6? ?Critical applications shall not be run on shared hosting or on weak web application containerization

3.7.7? ?Webserver processes shall run under a non-privileged user ID

3.7.8? ?Databases shall not allow root access or be run with root privileges

3.8 Error Handling and Logging

3.8.1? ?All Authentication, Authorization, Administrative activities shall be logged

3.8.2? ?Access to databases for all user types shall be logged

3.8.3? ?Logs shall not contain any confidential or private information (such as passwords or personally identifiable information). Sensitive logging information shall be identified and well structured, moreover, this information shall be encrypted

3.8.4? ?Logs shall be kept for at least 6 months, and at least as long as the results of the risk assessment determine

3.8.5? ?Error handling shall be tested; sensitive information shall not be displayed on error pages; generic error pages and global handlers shall be used to catch unhandled exceptions

3.8.6? ?Error messages shall not include the nature of the error

3.8.7? ?Custom generated error message shall not indicate the cause of the problem, such as an incorrect user name or password

3.9 Hosting Server

3.9.1? ?It shall be ensured that the hosting server’s operating system has the latest updates, patches and service packs

3.9.2? ?Web root folder shall be situated on a different file system from the operating system and directory traversal shall be disabled

3.9.3? ?Default administrator accounts for applications and databases shall be disabled and replaced by a non-privileged administrator account

3.9.4? ?Developers shall not allow plain text storage of system passwords

3.9.5? ?Web application firewall shall be in place for the hosting server. Web application shall only be published over internet if there is business requirement and shall be Geo-Fence based on the risk assessment

3.9.6? ?Weak ciphers shall be disabled on servers. For example, SSL v2, SSL v3, and TLS protocols prior to 1.2 have known weaknesses and are not considered secure. Additionally, disable the NULL, RC4, DES, CBC and MD5 cipher suites. Ensure all key lengths are greater than 128 bits, use secure renegotiation, and disable compression

3.10 Miscellaneous

3.10.1? ?The username and password and any other user information shall not be stored on the user machine

3.10.2? ?Applications shall utilize libraries from reputable sources, adhere to agreed-upon library versions, install all security patches, and proactively avoid deprecated libraries

3.10.3? ?Conduct security testing using tools like Veracode and Qualys both during and after development to ensure the application meets security standards. Periodic testing should also be conducted after major releases to ensure vulnerabilities did not get introduced during the update process. Remediate top 10 vulnerabilities at minimum

3.10.4? ?Chatbots used shall not access the organization's systems and must employ encrypted channels. The storage of sensitive and private information collected through chatbots shall align with a risk assessment

3.10.5? ?A backup schedule shall be defined, and it shall be ensured that applications and their data have been successfully backed up

3.10.6? ?An incident handling plan should be drafted and tested on a regular basis

3.10.7? ?Segregate where necessary development, testing and production processing facilities to mitigate the risk impacting the production systems from unauthorized intentional or unintentional access or change