Essential web application security checklist
A web application or web application is an application that runs on a remote system and is served over the Internet through a browser.
The main components of a web application are application code, server, database, transport, browser, presentation logic, and users. To completely secure web applications and protect system and customer data, you must understand the security risk at each layer and design a strategy to fully harden each layer.
Most developers believe that implementing a security or authentication and authorization framework in an application is sufficient to ensure application security; this is an overly simplistic view of application security (AppSec) requirements. There are several additional vectors needed to secure 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 elements that play a vital role.
A security framework performs two essential functions.
- Prevent unauthenticated requests from accessing secure features such as web pages and corporate data.
- Prevent authenticated requests from accessing unauthorized features such as unauthorized web pages and commercial data.
These challenges seem simple, but they are known to cause a lot of app issues. Consequently to the Top 10 OWASP APIs, broken authentication is ranked number two of frequently exploited flaws. The permission problem is nothing but a privilege escalation caused by the incorrect implementation and mapping of roles, scopes and permission to the proper resources such as web pages, internal services , etc. These well-known flaws have negatively impacted many large organizations, including behemoths like Microsoft, in breaching Microsoft Office 365, for example.
Security constraints are very common in business logic code. Separating security from code is difficult, and many developers don’t even realize how often they include security in their working code. For instance, consider Dropbox file sharing functionality. It allows you to share files in many ways, including with your friends, colleagues, groups, public group, editable group, internet public, etc. As you can see, most of these features are nothing more than security constraints most likely distributed across the codebase. . To ensure that your application does not leak commercial data to unauthorized users, you will need to test each function with security in mind.
Database access logic
The most significant application flaws over the past two decades have come from SQL, NoSQL, commands, and similar injection issues. There are a few best practices you should follow when integrating databases and similar systems.
First, use database credentials with basic privileges that support your data access needs; avoid credentials that can do more like delete tables, collections, databases, etc.
Databases are robust and feature-rich systems. They let you perform complex programming operations, including dynamic queries that can read, modify, and delete any data without proper permission checks. You should use standard best practices such as prepared statements when writing code against databases.
Application servers like Weblogic, Tomcat, IIS, etc. have played a vital role in the past. They supported critical features such as hot deployments, high availability (HA), mapping sessions, load balancing, etc. These systems were also prime targets for attack; most exploits looked for misconfigured systems or systems that did not change default credentials. With the wide adoption of containers, serverless and Kubernetes, developers are moving away from using application servers for new cloud-native workloads. The best practice is to use Kubernetes or a serverless architecture to deploy your applications.
Most applications run in virtual machines, on on-premises bare metal servers, or in the cloud. These systems are under constant attack from malicious actors trying to exploit misconfigured ports, vulnerable packages, SSH, etc. The best practice is to properly configure security groups and restrict access to ports and services to limited administrative IP addresses.
Running non-SSL web applications was an often used and acceptable practice in the past. But it allowed for man-in-the-middle attacks and other vectors. More recently, however, this attack vector has grown significantly stronger as most browsers no longer even render non-SSL or misconfigured SSL sites, 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 to implement IP, device, and browser reconnaissance techniques, including multi-factor authentication (MFA).
Application Security Summary
Web application security is complex and requires a layered approach to address all potential vulnerabilities.
● Tested the correct implementation of authentication and authorization functions at each code change.
● Tested the correct 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 the application against injection categories using Dynamic Application Security Testing (DAST) and similar tools.
● Modernize your application servers, use container orchestration frameworks like Kubernetes and follow its best practices to ensure security.
● Proper configuration of security groups is required to restrict port and SSH access to administrative personnel.
● Follow standard SSL best practices.
● Perform bad input rejection (not just sanitization) to avoid XSS and other issues.
● Implement MFA, device, IP address, and browser awareness to avoid user account takeover issues.