If there is a vulnerability, it will be exploited. That’s why security on a project or in the company looms large especially you work with sensitive customer data. We understand this need and we take care of web applications security at every stage and do our best to expand our knowledge in this matter.
This article is a non-exhaustive list of security measures/precautions that should be considered to be implemented during web application development and legacy application modernization. Even if some of the recommendations are not implemented intentionally (eg. due to limited budget, timeline, resources, etc.), it is valuable to be aware of them and communicate them to the product owner.
Why web application security is so important?
We can differentiate between two types of organizations
In the information security world, this saying is so famous that you don't even know who to attribute it to. It may seem pessimistic, but those who work in incident response, computer forensics or other investigations know it to be all too true.
Recognizing that a security threats (assumption breach) will occur is the basis for preparation and design assumptions to ensure that it proves difficult, time-consuming, costly and risky for someone to gain unauthorized access to networks, applications, data and other systems time-consuming, costly and risky, and that it is possible to detect and respond to such cases quickly.
This means It also means monitoring and logging what happens on your systems so that if a breach is discovered only after the fact, you can at least find out what happened. In order to detect a potential breach, changes and anomalies in the operation of the system are also often monitored.
Assuming that a security breach will occur means preparing in advance for the worst, to limit the damage, reduce the time to detect an event, and minimize corrective actions.
Key questions before the web apps project start
To effectively prepare a security checklist with the most adequate and beneficial security items to be checked, it is crucial to build a full understanding of the security "big-picture". This usually helps in setting the right security goals and constraints. The implementation application security program can bring a lot of benefits but before you should ask yourself some questions:
- What is the business domain of the application? (i.e. financial applications will require higher levels of security)
- Is the app going to be used by the general public or just internal users?
- What types of data do the application store and where is it going to be stored?
- Is any of this data sensitive?
- Do we need to follow any compliance policies, like GDPR?
- Is scraping an issue we should consider preventing?
Web application security when planning solution architecture
Based on the summary built-in in step one, it is important to take this knowledge into account when planning what needs to be implemented and how it is going to be implemented. Questions that might be helpful in this context:
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?
Web application firewalls during the development lifecycle
The following list is extracted from OWASP Top 10 vulnerabilities report from 2021 and should be considered as the primary checklist for vetting own applications security-wise (especially pre-release). Each page referenced below contains further references to detailed attack prevention techniques.
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.
- Deny access to functionality by default.
- Use Access control lists and role-based authentication mechanisms.
- Do not just hide functions.
- Constant interactive application security testing and Auditing of Access Controls.
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.
- Classify data processed, stored, or transmitted by an application, to understand what data you need to defend, and identify appropriate controls.
- Make sure to encrypt all data classified as "sensitive".
- Wherever possible, use encryption that provides forward secrecy, to ensure data encrypted in the past can’t be decrypted if session keys are exposed.
- Independently verify the effectiveness of encryption configuration and settings.
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.
- Validating user inputs by creating an allow-list (whitelist) for valid statements and configuring inputs for user data by context.
- Use prepared statements with parameterized queries that help distinguish between code and user input and do not mistake statements for commands.
- Using stored procedures that are defined and stored in the database and called from the web application.
- 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.
- Implement the security controls properly.
- 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.
- Always implement security controls on different layers such as on the network layer or on the system layer.
- Divide the users as per their authorization on all the tiers so no one can misuse the authorizations.
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.
- 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.
- A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
- A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process.
- A segmented application architecture provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
- An automated process to verify the effectiveness of the configurations and settings in all environments.
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.
- Remove unused dependencies, unnecessary features, components, files, and documentation.
- Continuously inventory the versions of both client-side and server-side components
- Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component
- Monitor for libraries and components that are unmaintained or do not create security patches for older versions.
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.
- Enable and enforce MFA
- Ensure that default passwords are only for one-time use and are updated as the user logins
- Enforce a password policy to prevent users from setting weak passwords
- Rate limit the critical endpoints
- 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 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
- Always ensure that the app you are using is trusted and uses sane security practices
- As a developer, ensure that the apps are signed and the trusted data sources are also tamper-proof
- Ensure that your CI/CD pipelines are secure and any malicious code doesn’t go in
- Audit the code before it makes it to the production
- Get your software pen tested frequently to ensure high-security levels
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.
- Ensure sufficient logging for all authentication failures, including login, access control, and server-side validation.
- Create context and understand baseline traffic to enable easy identification of suspicious and malicious activity
- Have an audit trail for critical and high-value transactions to prevent deletion or tampering
- Backup log files on multiple servers to enable fault tolerance
- Authenticate access to logs
- Automate monitoring and alerts for log events
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.
- Sanitize and validate all client-supplied input data
- Enforce the URL schema, port, and destination with a positive allow list
- Do not send raw responses to clients
- Disable HTTP redirections
- Be aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions
Conclusion
Web app security is important. There are many security risks associated with web application security, but with the right approach, it is easy to prevent or minimize them during the software development lifecycle. So if you're thinking about web application security you need to take a broad approach because everything is vulnerable in some way. Therefore, application security tools, as well as conscious employee education and assessment, should be implemented for a complete process.