5 Most Common Application Vulnerabilities and How to Mitigate Them

Sometimes you don’t know what you don’t know, but the good news is that there is guidance for organizations who wish to find the vulnerabilities in their applications before the attacker does.

In response to escalating cybersecurity attacks, we pioneered the forensic practice in 2010. In our work helping organizations secure their applications across the tech stack, we have gained technical information about the vulnerabilities identified in applications and the respective best practices in cybersecurity that help mitigate the vulnerabilities.

For the past several months, however, we have investigated our forensic data for application security with a new urgency, for it seems to us that the new ways of working have opened new attack vectors to cybercriminals.

Based on years of our collective forensic data from over 1000 investigations, this blog post will help you understand where vulnerabilities could arise in the applications and give you a basic idea of how to “think like a hacker” when testing the security posture of applications. In addition, we try to inject the development and testing teams with a healthy dose of paranoia by offering best practices for application security that are essential for QA managers, testing experts, tech leads and information security managers.

1. Structured Query Language (SQL)/Database Queries

This is the most common area of application vulnerability specifically due to the use of multiple databases in conjunction with multiple applications. SQL Injection attacks take place due to a flaw in the code of applications where the attacker successfully retrieves, alters, deletes data, executes SQL commands, or alters server configurations. In the reconnaissance stage, the hacker looks for spots in the application where they can inject undesired values to SQL commands.

For example, the attacker may use a string value for server queries to inject an escape sequence. The following is a potential SQL query for searching customers in a database:

SELECT * FROM customer WHERE name='” + strName + “‘; DROP TABLE customer;”

If the above SQL string input is not validated, it can execute a command to delete the customer table with the string name.

How to secure applications from SQL Injection attacks?

This specific application vulnerability has a lot in relation with SQL being natural-language oriented, or better put, human-oriented programming language. Therefore, it is important that anything passed to the SQL server is sanitized to prevent such attacks. It is best done by looking for areas of the application where it connects to a database and passing unusual values as a part of the application security testing program. Moreover, testing experts must always try to make sure that parameterized queries are used, and least privileges are given to applications for reading or inserting data to databases. Additionally, robust testing tools can be used for dynamic analysis and static analysis that help in discovering application vulnerabilities at the code level.

2. Broken Authentication

URL rewriting, application timeout not set properly, passwords not properly salted and hashed, or predictable login credentials are just a few causes of a broken authentication, in most cases of breaches at least. The prevalence of broken authentication in application (in)security is widespread. It is due to the weak implementation of identity and access controls. Certainly, session management forms the bedrock of the modern-day applications, but they are also not positioned well for many applications.

The landscape of broken authentication in applications as we see it

The logic behind this approach is uncomplicated and best illustrated with an example. Most authentication-based attacks take place due to the consistent use of plain passwords as the only credentials for an application. Once considered a best practice for application security, password complexity requirements and regular rotation have become obsolete for the new age cyberattacks. Fortunately, the PCI DSS standard (and other similar regulatory standards) have mandated the use of multi-factor authentication as an application security control.

Application security team action

To think like a hacker, the testing teams must understand that “what password the user knows” or “who the user is” isn’t enough for the authentication of applications. “Where the user is located” and “what the user is performing” are relevant for the authentication too. Identification of personal patterns including contextual evaluations of user behaviour, geolocations, biometrics and tokens are equally important. Risk-based authentication is relevant.

Some of the application security best practices for testing broken authentication are:

• Check the existence of multi-factor authentication for credential stuffing, brute force, etc.
• Admin users are allocated specific deployment credentials.
• Check that credential recovery and API pathways are hardened.
• Limit the number of failed login credentials.
• Session IDs are not recorded or stored in public interfaces.

3. Cross-Site Scripting (CSS)

Cross-site scripting, CSS, or commonly abbreviated XSS, is the concept that gives attackers the ability to push malicious scripts into dynamic webpages. In many cases, these malicious programs inserted by hackers are disguised as legitimate data. Part of the problem is that the validity of scripts is not checked before execution – and can be programmed to steam passwords or reformat databases.

Particularly, it is a concern for many banking and financial services applications as they are accessed on web browsers. In a hypothetical example, an attacker may send a trojan URL with client-side scripts that if, clicked by a user, gives the data back to the client.

Source: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)

To avoid XSS attempts, application security testers must explicitly filter user-supplied data before it turns into an output on the user’s web browser. Therefore, what follows is the step to ensuring that HTML tags are not returned to the client. Following functions can be checked by application security experts:

• C/C++: Calls to printf(), fprintf(), and output streams.
• Perl: Calls to print, printf, syswrite, or variables holding user-supplied data.
• PHP: Calls to print, printf, and echo or variables holding user-supplied data.

4. Modular Program and Container Security

Hopefully, all the core functions of applications – logic and programming, will stay within the bounds of the applications. However, with the wide adoption of containerization and orchestration technologies such as Docker, Kubernetes, OpenShift and PCF, modular code is empowered at scale, propelling application programs and functions out of the testing boundaries.

The next wave of application vulnerabilities in containerization

In forward-thinking enterprises, where IoT and edge computing is pervasive, container workloads can span across a broad architecture comprising public cloud, private clouds, and hybrid clouds integrated with on-site servers and VMs through IaaS and PaaS services such as S3 buckets. The point is, containers enable microservices, thereby increasing network traffic and access control complexity. Are containers and modular codes running with increased privileges than normal? Existing firewall rules aren’t enough for a docker environment – a pose of challenge for risk and compliance teams.

How to test modular codes and containers for absolute application security?

Think like a hacker – identify inter-container communications through nano segmentation and secure the ones in the development pipeline that are out of the application runtime environment. So, how your core application interacts with external programs is an important question that must be answered step by step.

• Secure the complete inventory of images, hosts, containers, registries, runtimes, and orchestration platforms.
• Provide an IAM role per container or docker and follow the least privilege rule.
• Scan for any vulnerabilities in the source of modular images.
• Provision all container and modular code security tools in CI/CD pipelines.
• Place container firewalls and policy engines explicitly.

5. Checking Networking and Communication Streams

For an application security tester, all outgoing and incoming network communications are to be treated as vulnerable. For instance, an application code may establish an FTP connection to retrieve an important file. The presence of tainted data can allow an attacker to modify listening server processes and intrude.

The above example is a small but potential vulnerability in applications. Modern enterprises work on ephemeral computing environments that are very dynamic in nature and are equally vulnerable to cyberthreats. Say an ecommerce company is preparing for the Black Friday and has opted for auto-scaling using Azure Autoscale. The trigger can result in the automatic installation of multiple resources such as VPCs, API Management service, Load Balancer, Azure Data Explorer Clusters, Logic Apps with auto provisioned Azure VMs, making it an overextended network infrastructure. Although such automation and auto-scaling of networking elements are the cornerstone of application agility, they require new approaches of application security testing.

How to test network security for applications?

• Secure APIs by evaluating the sensitive data and resources they’re exposing – Amazon API Gateway implements Client-Side SSL Certificates for authentication by the backend.
• Ensure appropriate in-app permissions – Azure Active Directory  provides authentication capabilities for applications.
• Gate admin access based on real-time data – ensure that devices and users are not trusted only on internal networks.
• Ensure all internal communications are encrypted for applications.
• Employ microsegmentation for application network security.
• Hardening and endpoint protection for applications are managed in tandem with changing network environments.

The Evolving Application Security Testing Practices

Reality-be-revealed, security is all or nothing. Besides, application security is a reflex, a way of understanding and facing the modern world cyber threats. Application security squads need that reflex, a pragmatic and proactive approach to manage risks and application vulnerabilities. A certain level of automation needs to be introduced across the application stacks such as threat intelligence, identity management, and scaled code reviews to improve application security vulnerability detection and response. Best practices and a toolkit are just the starting point. With time, it should lead organizations to adopt a ‘security by design’ approach.

Well prepared application security teams and QA testers face reality with staunchness and create solutions from thin air. Other do not. This is the nature of cybersecurity for current day applications.

If you recognize some of the above-mentioned challenges in application security, or if you would like to explore how we can help your company mitigate application vulnerabilities, please do not hesitate to contact us.