Web Application Security - Best Practises & Checklist (2023)

Table of Contents

• Why web application security is so important?
• Key questions before the web apps project start
• Web application security when planning solution architecture
  • Application authentication and authorization
  • Production data access and usage policies
  • Framework and monitoring
• Web application firewalls during the development lifecycle
• Conclusion

Application authentication and authorization

• What kind of authentication strategy are you planning to use?
• Are you going to implement SSO?
• What about MFA?
• What authentication libraries / 3rd party services are to be used?
• Who will create new users in the system?
• How are you going to authenticate your APIs?
• Do you need APIs at all?
• What APIs are going to be used for - Server-to-Client or Sever-to-Server communication?
• How are you going to invalidate tokens if needed? How often?
• Are there permission levels / ACLs necessary to be introduced at the application level? How and Who will be in control of them?

Production data access and usage policies

• For local development - do you need to use production data at all or can you live with seeded data or fixtures?
• For staging and/or QA - do you need to use production data here? Do you need to obfuscate it? How, at which stage and what fields do you need to obfuscate?
• For production - how are you going to access data to debug some specific problems? Who will be able to do that? Do you need "impersonate user" functionality? Do you need to ask users for permission do do that?
• Who might have unintentional access to the production data stored? Which developers? Any 3rd party (eg. Hosting services / Cloud provider)?
• If and what data should be encrypted at rest?

Framework and monitoring

• What application framework are you going to use? What are the key conventions to be followed to maximise benefits of framework built-in security measures?
• What policy / procedure for continuously updating libraries / framework are you going to introduce, if any?
• Do you allow GitHub to scan your repository for vulnerabilities related to outdated dependencies?
• What do application logs contain and where this data is going to be stored, for how long and who will be able to access it?

Broken Access Control

Broken Access Control vulnerabilities are common in modern applications since the design and implementation of access control mechanisms rely on a highly complex ecosystem of multiple components and processes. In such a complex, changing ecosystem, security and development teams should apply several legal, organizational, and business logic to ensure the tech stack is watertight and has no room left for hackers to exploit the system.

1. Deny access to functionality by default.
2. Use Access control lists and role-based authentication mechanisms.
3. Do not just hide functions.
4. Constant interactive application security testing and Auditing of Access Controls.

Cryptographic Failures

In short, insufficient cryptography is cryptography that can be easily compromised and does not provide a sufficient level of security. The basic concept behind cryptography is not to create ciphers that are impossible to crack, but to create ciphers that are impossible to crack within a reasonable timeframe given the computational power currently available. In other words, it may not be impossible to crack from a conceptual standpoint, but it’d be excessively difficult and impractical to do so. So insufficient cryptography generally means cryptography that can be cracked in a reasonable amount of time with the hardware available to the attacker.

1. Classify data processed, stored, or transmitted by an application, to understand what data you need to defend, and identify appropriate controls.
2. Make sure to encrypt all data classified as "sensitive".
3. Wherever possible, use encryption that provides forward secrecy, to ensure data encrypted in the past can’t be decrypted if session keys are exposed.
4. Independently verify the effectiveness of encryption configuration and settings.

Injection

Injection flaws occur when untrusted user data are sent to the web application as part of a command or query. The attacker’s hostile data can trick the web application into executing unintended commands or accessing unauthorized data. Injection occurs when a hacker feeds malicious input into the web application that is then acted on (processed) in an unsafe manner. This is one of the oldest attacks against web applications, but it’s still the king of the vulnerabilities because it is still widespread and very damaging.

1. Validating user inputs by creating an allow-list (whitelist) for valid statements and configuring inputs for user data by context.
2. Use prepared statements with parameterized queries that help distinguish between code and user input and do not mistake statements for commands.
3. Using stored procedures that are defined and stored in the database and called from the web application.
4. Limiting special characters to disallow string concatenation.

Injection vulnerabilities can pop up in all sorts of places within the web application that allows the user to provide malicious input. Some of the most common injection attacks target the following functionality:

• Structured query language (SQL) queries
• Lightweight directory access protocol (LDAP) queries
• XML path language (XPATH) queries
• Operating system (OS) commands

Insecure Design

Insecure Design is a new category for 2021, with a focus on application security risk related to design flaws. If we genuinely want to "move left" as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.

Identifying flaws at the design phase is what we call “starting left” insecurity, which is a progression of the popular DevSecOps saying to “shift left”. As OWASP highlights, secure design is as much about culture as well as methodology. This is about changing the mindset around what stage security needs to enter the application development process and it is our fundamental belief that true DevSecOps can only be achieved if security is factored in right at the outset.

1. Implement the security controls properly.
2. Perform security in each step such as on the Unit stage or on the integration stage for the validation of all the flows that can exist and resistant them with the help of Threat modeling if teams are following it.
3. Always implement security controls on different layers such as on the network layer or on the system layer.
4. Divide the users as per their authorization on all the tiers so no one can misuse the authorizations.

Security Misconfiguration

A misconfiguration can occur for various reasons. Modern network infrastructures are exceedingly complex and characterized by constant change; organizations can easily overlook crucial security settings, including new network equipment that might retain default configurations. Even if you've provisioned secure configurations for your endpoints, you should still audit configurations and security controls frequently to identify the inevitable configuration drift. Systems change, new equipment is brought into the network, patches are applied—all contributing to misconfigurations.

1. A repeatable hardening process makes it fast and easy to deploy another environment that is appropriately locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment.
2. A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
3. A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process.
4. A segmented application architecture provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
5. An automated process to verify the effectiveness of the configurations and settings in all environments.

Vulnerable and Outdated Components

The prevalence of vulnerable and outdated components — and the ease of attacks using this vector — make this an especially dangerous category. Almost all modern applications use open-source packages, and information about vulnerabilities related to these packages is widely available. Attackers who figure out what vulnerable packages you're using can use exploits that are already available. That means you have a type of attack that is widespread and straightforward.

1. Remove unused dependencies, unnecessary features, components, files, and documentation.
2. Continuously inventory the versions of both client-side and server-side components
3. Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component
4. Monitor for libraries and components that are unmaintained or do not create security patches for older versions.

Identification and Authentication Failures

Identification and authentication failures can occur when functions related to a user's identity, authentication, or session management are not implemented correctly or not adequately protected by an application. Attackers may be able to exploit identification and authentication failures by compromising passwords, keys, session tokens, or exploit other implementation flaws to assume other users' identities, either temporarily or permanently.

1. Enable and enforce MFA
2. Ensure that default passwords are only for one-time use and are updated as the user logins
3. Enforce a password policy to prevent users from setting weak passwords
4. Rate limit the critical endpoints
5. Get your applications pentester and any code being pushed to production must be reviewed and well tested against such issues

Software and Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that do not protect against integrity violations. This can occur when you use software from untrusted sources and repositories or even software that has been tampered with at the source, in transit, or even the endpoint cache. Attackers can exploit this to potentially introduce unauthorized access, malicious code, or system compromise as part of the following attacks:

• Cache Poisoning
• Code injection
• Command execution
• Denial of Service

1. Always ensure that the app you are using is trusted and uses sane security practices
2. As a developer, ensure that the apps are signed and the trusted data sources are also tamper-proof
3. Ensure that your CI/CD pipelines are secure and any malicious code doesn’t go in
4. Audit the code before it makes it to the production
5. Get your software pen tested frequently to ensure high-security levels

Security Logging and Monitoring Failures

Nearly all major security incidents originate from the exploitation of insufficient logging, unplanned security strategies, or insufficient monitoring. Businesses using mobile apps with insufficient or no logging functions run the risk of attack taking so long to be mitigated that those can do considerable damage to the entire tech stack.

Hackers leverage gaps in logging and monitoring by relying on the fact that security teams will take time to detect and remediate the attack to try and escalate privileges. This section explores the threats associated with insufficient logging & monitoring and the business impacts of a successful attack.

1. Ensure sufficient logging for all authentication failures, including login, access control, and server-side validation.
2. Create context and understand baseline traffic to enable easy identification of suspicious and malicious activity
3. Have an audit trail for critical and high-value transactions to prevent deletion or tampering
4. Backup log files on multiple servers to enable fault tolerance
5. Authenticate access to logs
6. Automate monitoring and alerts for log events

SSRF - Server Side Request Forgery

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

1. Sanitize and validate all client-supplied input data
2. Enforce the URL schema, port, and destination with a positive allow list
3. Do not send raw responses to clients
4. Disable HTTP redirections
5. Be aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions

Tags:

software development outsourcing