Tips to Protect Web Applications

From 200 million in the year 2000 to 3.5 billion users in 2019, the staggering growth is the testimony of the internet’s all-pervasive nature. It has transformed itself from an option to a necessity indispensable for any entity. 

As the world and its economy are fully internet-dependent now, it is fully exposed to the threats of online attacks from malicious hackers, syndicate gangs, spy agencies, or even hostile governments. Earlier, most of the online attacks ended up defacing sites, data thefts, and DoS. More recently, cyber-attacks are more of ransomware nature. Ransomware attacks hijack operations for an exorbitant cost. 

A study report conducted by Sonicwall, 2019 saw a 52% increase in attacks on web applications. Some of the organizations and products which have been considered impregnable viz Apple iPhones or some US defense sites were breached in 2019, albeit with minimal impact. This leads us to conclude that no application or device exposed to the internet is ever secured permanently. A foolproof design based on threat models published threat profiles, and secured design patterns are the building blocks of implementing web applications security.

Most companies invest heavily in network security and firewalls to ensure bad guys are kept at bay. Secured networks are undoubtedly a very important and critical aspect of application security apparatus and should be done with cautious planning. However, the most important aspect of any web application security is its overall design and its implementation. In 2019, of all the successful attacks, 82% of vulnerabilities were found in application code. The focus of this write-up is more design, development, and deployment of web applications. No network security and firewall can safeguard against an ill-designed application. 

Web Application Security Eco-system Encompasses The Following Technologies:

1. Secured design patterns using prominent programming languages.
2. Robust design framework based on OWASP top 10 list of risks. (https://owasp.org/www-project-top-ten/)
3. Secure coding practices. This includes automated code analysis and vulnerability scanners.
4. Thorough security testing at multiple levels. A few testing strategies:
   • Input testing.
   • White box testing. Employing source code analyzers.
   • Black box testing using security scanners for vulnerabilities and penetration. 
   • Brute force attacks testing.
   • DoS attacks testing.
5. Compartmentalized and isolated deployment.
6. Web Application firewalls. (WAF).

As most vulnerabilities are found in application codes, more emphasis on the design of web applications is never a redundant exercise. Web application security can be broadly based on the security framework, which can be broken down into the following segments:

1. Secured and validated Inputs:

The city of Troy was impregnable until the incoming traffic was sanitized. The trojan horse was an unverified input that eventually allowed intruders in. Users interact with a web or mobile application through the interfaces that ask for inputs. This is also the route through which a known hacker breaches the security by the well-known vulnerability of cross-scripting or XSS. 54% of vulnerabilities are attributed to cross-scripting.

Some of the guidelines in this category are:

• All inputs, including form fields, cookies, query strings, HTTP headers, should go through strong validations and trust factor authentication.
• Centralized input validation should be the preferred method to validate inputs. 
• Client-side validations should be completely avoided.
• Validate for type, length, format, and range
• Validate, Filter, scrub, constrain, reject, and sanitize the input data.

A very nice explanation of XSS and steps to prevent it is provided in Google’s documentation, which can be found at Google’s Application Security guidelines.

2. Authentication

If a web application is a vault, authentication is its lock and key. Only authorized users who have the key to the lock can only enter the vault. Managing authentication using strong passwords, 2-way authentication, and/or digital tokens should be securely implemented. Many applications allow the transit of passwords in plaintext. This is a recipe for disaster. Many applications allow SSOs for organization-wide integration. Ensure the authentication policy of ADS, LDAP, or any other directory services have a strong authentication mechanism.

Important guidelines in this category are:

• Create DMZs and partitions between authenticated and identified areas. 
• Use strong passwords and implement strong password policies.
• Do not store credentials in plaintext
• Store credentials in one-way hashes with salt.
• Authentication tokens only through encrypted communication channels.
• Authentication cookies should transfer only over HTTPS connections
• Continuous testing with password hacking tools to eliminate weak passwords.
• SSL, IPSec, DPAPI are used to transmit and secure passwords as far as possible.

3. Authorization

Authentication and authorization always go hand-in-hand. While authentication is about who can log in to the application, authorization is about what one can do after logging in. Can a user start or stop a service? Can a user rename, delete, suspend, or reset passwords of other users and many other levels of permissions? Can a user access the database directly? Can a user access an API. 

Authorization is not just limited to just users, but execution permissions to services, integration with other applications, exposure to APIs, and databases also are an integral aspect of authorization. 

Important guidelines to follow:

• Use the principle of least privilege.
• Provide granular, role-based access.
• Do not expose system-level resources to users. 
• Use strong encryption keys to access system resources.
• Use secured tools, and encrypted if possible, for remote administration.
• Prevent access to session states.

4. Data protection

A web application’s main objective is to access, store, and present data. Access to databases and data storage is vital. Applications store data on primary and secondary storage. Primary storage, like memory and secondary storage, like disks, are equally vulnerable to security breaches. If an intruder gains access to memory addresses, it can access the vital data that the application is processing. When it comes to sensitive data, encryption of data while in transit and at rest becomes absolutely necessary.

Few guidelines in the category are:

• Use persistent cookies for non-sensitive ephemeral data.
• RESTful APIs over HTTP should not be used to transfer sensitive data. 
• Separate data storage from the application engine with strong access controls and encrypted keys. 
• Ensure caches are also on encrypted storage.

5. Failure handling

Usually, when attacks happen, especially the DOS type of attacks, services, or daemons, stop functioning as expected. In case of a function failure, exception handling should ensure graceful failures and swift garbage cleaning to prevent leakages. 

• Sensitive application implementation details, objects, and methods should not be exposed in the event of failures.
• Ensure memory and core dumps are stored in a secured location – encrypted if possible.

6. Audit and logging

Applications should have fully equipped logging and audit functionality to monitor, debug, trace, and audit all activities.

• Monitor, identify and document malicious behavior. Create triggers accordingly.
• Every component and tier must be logged. 
• Ensure strict authorization to access log files
• Backup log files regularly in secured locations. 

Top Web Application Security Issues

a. Server security

Having looked at the design of web applications, let us also look at another important aspect of web applications security – Servers on which the web applications are hosted. Servers are important as they house the web applications. If not configured correctly, they are the first defense that falls apart, leaving the application exposed to threats. Guidelines to secure application servers are as below:

• Hardening, patching, and updating the server. OS is patched regularly with the latest patches. 
• Strong passwords and login audit policies implemented. PAM, NIS, and/or LDAP/ADS/NIS provide a robust login framework for SSOs. Least access privileges are the norm to be followed. 
• Logging and audit of login attempts, successful and unsuccessful.
• Strong, robust, and secured filesystems, volume managers, and drivers. All these components are patched and updated regularly.
• Regular screening of open ports, services, processes, and unused protocols. 
• Removal of redundant kernel modules.
• All protocol communications are secured and encrypted.
• ACLs, Registry, and Policies are preserved and protected with adequate backups.

b. Testing

Even though one may secure the applications and servers at a point in time, as the software stack is updated, new vulnerabilities still creep in. That’s why frequent and in-depth testing is important. Here’s a guideline from OWASP (https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Web_Application_Penetration_Checklist_v1_1.pdf).

No one has the time and skilled staff to execute all such tests repeatedly. Therefore the best approach is to use a combination of frequent automated scans using reliable and comprehensive tools (https://owasp.org/www-community/Vulnerability_Scanning_Tools) and at least quarterly full penetration testing by experts.

Conclusion

As web application development technologies are evolving constantly and new frameworks get adopted, a new set of vulnerabilities get introduced. In this ever-changing environment, continuous in-depth testing and quickly fixing critical issues is your best defense.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.