How to mitigate these 3 new-age web application threats?

Traditional applications layers are rapidly moving towards a more modular design using complex workflows comprising of microservices, complex data, and metadata types & external SaaS utilities. This complex architecture creates a high degree of east-west traffic in addition to the north-south traffic between the user desktop and the client tier. This additional traffic highway, along with the added complexities in design makes cybersecurity more and more difficult.

Since 2003, the Open Web Application Security Project (OWASP) has been updating its list of the 10 most prevalent application security risks in every few years. The purpose of the OWASP Top 10 is to build awareness of the most common exploits hackers use to infiltrate and compromise data within web-based applications. Over the last couple of years, there has been a fundamental shift in the technology and the architecture of applications. Let's take a deeper look and find out why these new vulnerabilities are critical and how to avoid them?

1. Microservices: A boon and a doorway to critical threats at the same time

What are Microservices?

Microservices are built around the micro-modularity. A certain category of applications become much easier to build and maintain when broken down into smaller, modular units. These units, known as containers, can be separately maintained and continuously worked on with the main application made up of the sum of its constituent containers. Breaking down the application into small independent components facilitates efficient development, allowing numerous small teams to adapt, deploy, and scale their respective services independently with minimal downtime. 

Why are these more vulnerable?

A lot of a system’s functionality is directly exposed to the network when using microservices. This puts it in closer reach of potential attackers. The potential threat landscape expands significantly as we are dealing with multiple small containers that function as one. As the source code is used again and again, a vulnerability in one microservice can quickly replicate many times. Hence, sometimes the security challenges that come with a microservices-based architecture can soon start to outweigh the benefits that make this approach so advantageous.

How to mitigate risks involved with Microservices?

• Validate everything: Validate the data coming from all the sources, maybe it is coming from the user or coming from some internal microservice or database and so on. Never trust the incoming data as it could have been polluted. Also, never build query parameters and any validated strings by hand.
• Log everything: Long-lasting logs should be created since the logs are the only place where you could spot the security holes which might would stay in the app for months or even years.
• Tooling: This is especially critical when deploying microservices apps with a new set of management tools, such as Kubernetes. “There’s a knowledge gap around these tools that leads to mistakes around authentication, authorization, hardening and other best practices.”
• Abstraction from a host environment: Since existing endpoint and server security tools don’t have the required access and granularity to adequately monitor microservices, the visibility and control of these microservices become issues. “Since microservices can be scaled up and down rapidly and across different types of infrastructure, it’s a challenge to track them.”
• Dynamic code delivery and updates: By automating testing, code must be vetted to ensure that it represents an acceptable risk in terms of vulnerabilities, malware, hard-coded secrets, etc.

2. XML Vulnerabilities: Attractive targets for the attackers

What is XML?

XML is majorly used for persistent data, exchanging data between a web service and client, and in configuration files.

Why they are more vulnerable?

Many a times critical flaws are left in the application due to a misconfigured XML parser. Its potential ability to process untrusted XML streams, including remote code execution and reading of sensitive data, is what makes XML External Entities (XXE) so dangerous. The successful exploitation of this vulnerability may result in disclosure of sensitive data, denial of service, or an attacker gaining unauthorized access to the system resources. If an XML parser does not block external entity expansion and is able to access the referred content, one user may be able to gain unauthorized access to the data of other users, thus leading to a breach of confidentiality.

How to mitigate XML vulnerabilities?

• Simpler data should be preferred using formats such as JSON over XML
• Sensitive data should not be serialized
• Dependency-check should be used to identify project dependencies and to check if there are any known, publicly disclosed, vulnerabilities
• SOAP 1.2 or higher SOAP versions should be used
• XML external entity and DTD processing in all XML parsers should be disabled in the application (as per the OWASP Cheat Sheet "XXE Prevention")
• Positive ("whitelisting") server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes should be implemented
• XML or XSL file upload functionality should be verified to validate incoming XML using XSD validation or something similar
• Tools such as SAST can be used to detect XXE in source code, although a manual code review is always the best alternative in large, complex applications with multiple integrations
• If none of the above-mentioned measures to control XXE are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks

3. Embracing Single Page Applications

What is SPA?

Single-page applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app. The back-end no longer contains the largest part of the application logic. JavaScript is now the primary language of the web with Node.js running server side and modern web frameworks such as Bootstrap, Electron, Angular, and React running on the client. These allow the creation of highly modular feature-rich front ends

Why are they more vulnerable?

Client-side functionality that has traditionally been delivered server-side brings its own security challenges. In the SPA model, where everything happens on client, DOM-based Cross-site Scripting is a big threat. Single-page application reads something from the URL (may be a URL fragment) uses that information, and puts it on the page. Here there are no server interactions. But for instance, if the fragment contains a certain AngularJS directive is executed in the browser, it can hijack user sessions, deface websites, or redirect the user to malicious sites.

How to mitigate SPA Vulnerability?

• Use the best practices for authentication and session management
• If required, use SSL and separate sensitive data to a secure zone
• Use an authentication token with a well-defined expiration policy, and check the code for security vulnerabilities continuously
• Ensure proper use of CSP directives to instruct the browser to allow or block resources to be loaded and executed
• When using inline scripts use proper hashing mechanisms
• Discourage the use of eval() 
• Use SRI (Subresource Integrity) when using CDN for loading some resources. Using SRI enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. Again, do not forget to hash the file and reference the hash in the script file.
• If required, use HTTP Strict Transport Security (HSTS) response header. It tells the browser that it should only allow HTTPS requests on all subsequent requests. Enforcing this header reduces possible MITM attacks.
• If high level of security is required, use HTTP Public Key Pinning (HPKP). The ability to instruct the browser to verify a set of given cryptographic public keys against the requesting website. Enforcing this header also reduces the possible MITM attacks with forged certificates.