A web application or web app is an application that runs on a remote system and is delivered over the internet through a browser.
The major components in a web application are application code, server, database, transport, browser, presentation logic and users. To comprehensively secure web applications and protect system and customer data, you must understand the security risk at every layer and devise a strategy to fully harden each layer.
Most developers think implementing a security framework or authentication and authorization in an application is enough to ensure the application’s security; this is an overly simplistic view of application security (AppSec) requirements. There are several additional vectors necessary to securing web applications. Let’s dissect each layer and see what security risks they expose.
Number one in the list is your application itself; this is the most critical layer. It has several key components that play an essential role.
A security framework performs two critical functions.
- Blocking unauthenticated requests from accessing secure functionality like web pages and business data.
- Blocking authenticated requests from accessing non-entitled functionality like non-entitled web pages and business data.
These challenges look straightforward, yet they are known to cause many application problems. Accordingly to the OWASP API Top 10, broken authentication is rated number two in flaws frequently exploited. The authorization issue is nothing but privilege escalation caused by the incorrect implementation and mapping of roles, scopes and authorization to appropriate resources like web pages, internal services, etc. These well-known flaws have negatively impacted many large organizations, including behemoths like Microsoft, in the Microsoft Office 365 breach, for example.
Security constraints are very pervasive in business logic code. It’s tough to separate security from the code, and many developers don’t even realize how often they include security in their functional code. For example, consider Dropbox file sharing functionality. It allows you to share files in many ways, including with your friends, colleagues, groups, group public, group editable, internet public, etc. As you can see, most of this functionality is nothing but security constraints most likely spread across the codebase. To ensure your application is not leaking business data to unauthorized users, you’ll have to test each function with security in mind.
Database Access Logic
The most significant application breaches over the past two decades came from SQL, NoSQL, command and similar injection issues. There are a few best practices you must follow when integrating databases and similar systems.
First, use database credentials with the basic privileges that support your data access needs; avoid credentials that can do more like deleting tables, collections, databases, etc.
Databases are robust and feature-rich systems. They allow you to run complex programming operations including dynamic queries that can read, modify and delete all data without proper entitlement checks. You must use the standard best practices like prepared statements when writing code against databases.
Application servers like Weblogic, Tomcat, IIS, etc., played an essential role in the past. They supported critical functionalities like hot deployments, high availability (HA), mapping sessions, load balancing, etc. These systems were also prime targets for attacks; most exploits looked for misconfigured systems or systems that didn’t change the default credentials. With the wide adoption of containers, serverless and Kubernetes, developers are moving away from using application servers for the new cloud-native workloads. The best practice is to use Kubernetes or serverless architecture to deploy your applications.
Most applications run inside virtual machines, on bare-metal servers on-premises or in the cloud. These systems are constantly under attack by malicious actors trying to exploit poorly configured ports, vulnerable packages, SSH, etc. The best practice is properly configuring the security groups and restricting access to ports and services to limited administrative IPs.
Running web applications on non-SSL was an often-used and acceptable practice in the past. But it allowed man-in-middle attacks and other vectors. More recently, however, this attack vector has hardened significantly because most browsers won’t even render non-SSL or poorly-configured SSL sites anymore, forcing developers to configure SSL correctly.
Brute force, stolen passwords and stolen cookies/sessions are common account takeover exploits. The best practice to counter these exploits is implementing IP, device and browser recognition techniques, including multifactor authentication (MFA).
Application Security Summary
Web application security is complex and requires a layered approach to address all potential vulnerabilities.
● Test correct implementation of authentication and authorization features at every code change.
● Test proper implementation of RBAC and OAuth2.0.
● Business logic flaws are complex; every code change and introduction of new data can introduce a security bug. A comprehensive testing strategy is required to avoid data breaches.
● Test application against injection categories using dynamic application security testing (DAST) and similar tools.
● Modernize your application servers, use the container orchestration frameworks like Kubernetes and follow its best practices to ensure security.
● Proper configuration of security groups is required to restrict access to ports and SSH to admin staff.
● Follow standard SSL best practices.
● Do bad input rejection (not just sanitization) to avoid XSS and other issues.
● Implement MFA, device, IP and browser recognition to safeguard user account takeover issues.