blog-6-most-critical-risks-3
Authors: Benedetto Marco Serinelli,
Meriem Benyahya,
Niels A. Nijdam 
The Open Web Application Security Project (OWASP) Top 10 is a standard awareness document1 that widely describes web applications' most critical security risks. The analysis below gives insight into such vulnerabilities, as depicted in Figure 1.

Injection vulnerabilities occur when an adversary is able to put untrusted data into the interpreters, such as SQL, NoSQL, and Object–Relational Mapping (ORM), leading to data loss, data corruption, unauthorized data access, and Denial of Service (DoS) attacks. Countermeasures like escaping malicious characters before calling the interpreter, dynamic queries and commands, stored procedures, and Uniform Resource Locator (URL) parameters implementations provide more robust protection to the systems. Additionally, data must be separated from commands and queries to prevent injection vulnerabilities. Further mitigation techniques would be:

  • Using a safe Application Programming Interface (API).
  • Implementing a server-side input validation.
  • Escaping special character functions.
  • Programming language syntax to control the number of output results like LIMIT keyword for SQL. 

Broken access risks happen when an attacker accesses a large number of user credentials where they can launch brute force and dictionary attacks. In preparation for such attacks, the information is maliciously and stealthily gathered, targeting sensitive information like institutional email addresses [1, 2]. Such risks are associated with social fraud and identity theft. To countermeasure broken access risks, multi-factor authentication can be recommended. Other solutions can be considered, such as
  • Weak password detector
  • Strong password policies (password length, case sensitive, alphanumeric combination, symbols, password rotation, prohibition of user, company and institution details, and the comparison with password dictionaries2)
  • Strong recovery procedure
  • Server-side session management
  • Limit or delay login attempts. 

Broken access control risks lead to unauthorized information disclosure and an elevation of privilege. In other words, such risks allow an attacker to act as a user without being logged in or an administrator when logged in as a user with the motivation to create, read, update or delete records. In addition, the vulnerabilities include metadata manipulation like tampering with a JSON Web Token (JWT) access control token or a cookie and misconfiguring Cross-Origin Resource Sharing (CORS). To mitigate broken access control risks, it is required to deny all resources, implement a resilient access control mechanism, minimize the CORS, disable webserver directory listeners, ensure metadata files and use the JWT server-side invalidation session.

Sensitive data exposure takes place when personal information is not protected or shielded enough. If not encrypted or anonymized, sensitive data can be stolen as clear text, and attacks like Man-In-The-Middle (MIMT) may occur. Sensitive data includes Personal Identifiable Information (PII) such as health records, credentials, personal data, and payment card information which must be protected by laws or regulations like European Union (EU) General Data Protection Regulation (GDPR). Strong encryption algorithms such as Rivest–Shamir–Adleman (RSA) and Advanced Encryption Standard (AES) can prevent data exposure. 

XML External Entities (XXE) risks are caused when web-applications parse Extensible Markup Language (XML) inputs. This attack happens when an adversary uploads malicious XML file contents leading to DoS attacks, an internal system scan, or a remote request from a server. For example, the Security Assertion Markup Language (SAML) web-application authentication for a Single Sign-On (SSO) is an XML assertion identification that may hide XXE vulnerabilities. The mitigation strategies against such attacks are the use of less complex data structure (such as JavaScript Object Notation (JSON)), up-of-date XML processor and libraries, Simple Object Access Protocol (SOAP) version 1.2 or higher, server-side input validation, and sanitation XML through XML Schema (XSD) validation.

Cross-Site Scripting (XSS) risks are recognized by automatic tools [1, 2], used by an adversary to spread malware and to manipulate the browser's Document Object Model (DOM). The risks are associated with three kinds of vector attacks. The first is Reflected XSS, which allows an adversary to execute malicious HyperText Markup Language (HTML) or JavaScript code inside the user browser. The second one, the Stored XSS, permits an attacker to inject and store malicious code on the server-side. Finally, the DOM XSS enables an adversary to manipulate the DOM inside the browser. The use of frameworks, such as Ruby on Rails or React, which automatically escape XSS, could prevent the associated risks. Untrusted Hypertext Transfer Protocol (HTTP) requests data should be avoided. Also, context-sensitive encoding and Content Security Policy (CSP) should be implemented to mitigate XSS risks.

Security misconfiguration risks are hidden in any application layers from network to application. They may take place at the level of network protocols, application server, database management, custom code, libraries, container, virtual machine, or virtualization daemon. An adversary takes automated scanners in advantage to detect security misconfigurations, obtaining unauthorized access and high Operating System (OS) privilege afterward [1, 2]. Moreover, the web application could be vulnerable due to unnecessary ports, services, accounts, default passwords, default settings and if server services are set, enabled, and unchanged. Security configurations, such as solid development, quality assurance, and strong production environment procedures with different accounts and passwords are key mitigation solutions. Minimal environments, installing only compulsory and necessary services, could also countermeasure security misconfiguration risks. Furthermore, framework and platform samples, components documentation must be uninstalled and wiped because of the hidden flaws inside them. Continuously updates must be done for keeping up-to-date tools, services, and platforms, installing official security patches.

Insecure Deserialization risks are associated with a hostile object deserialization process, provided by an adversary input, to execute remote code from the server-side or alter web application logic. The risks are harmful due to the large use of the reading object process for a number of features, such as database fetching, caching/persistence, file system handling, HTTP cookies, HTML form parameters, web service, and message brokers. The deserialization process should be done through integrity checks (via Hashing for Message Authentication (HMAC) algorithm 3), such as digital signature, strict type constraints, and in an isolated environment with low privilege.

Third-party assesses vulnerabilities can be exploited by an adversary as a stepping stone to perform other attacks. Scanner tools can help an adversary find vulnerabilities in the OS server, web application server, database management, libraries, and components [1, 2]. Unused dependencies, modules, components, and libraries must be removed to decrease the third-party resources vulnerability risks. A continuous inventory could always be updated to keep track of all client and server assessments, including version and indirect dependencies. Lastly, the needed assesses should be updated and through official releases that could prevent vulnerabilities through security patches.

Insufficient logging and monitoring are the shortcomings when a successful attack occurs after compromising a web application. An adversary usually starts an attack with probe activities to find the vulnerabilities and attack vector [1, 2]. Logging and monitoring should be recorded in a detailed and clear way to prevent initial adversary activities or to describe adversary steps after attacks through forensic analysis. Logging should be done for all kinds of failures, such as login attempts, access control failure, server-side input validation, and deserialization process. On the other hand, monitoring should ensure integrity controls such as preventing tampering and deletion. Although an adversary could clean their own tracks after attacks [1, 2], the backup log procedures should be implemented. As described above, logging and monitoring actions could prevent a wide type of attacks, including scanning assessment attacks to broken access control.

The most critical risks for web-based applications are briefly described to increase the developer's awareness about web implementation and design. The nIoVe platform puts in place the above-described countermeasures for providing and employing

  • Secure and resilient framework
  • Secure deserialization (via secure hashes and message digests)
  • Secure protocols as a concept (SSH File Transfer Protocol (SFTP) and Hypertext Transfer Protocol Secure (HTTPS)
  • Secure encryption and strong anonymization for the PII following the EU GDPR. 

References

[1] D. Teixeira, A. Singh, and M. Agarwal, Metasploit Penetration Testing Cookbook. No. 11, Packt Publishing Ltd, 2013. [2] D. Kennedy, J. O. Gorman, D. Kearns, and M. Aharoni, Metasploit.

[2] D. Kennedy, J. O. Gorman, D. Kearns, and M. Aharoni, Metasploit.