The Open Web Application Security Project (OWASP) is a non-profit organisation based in the United States that aims to inform company owners, developers, and consumers about the dangers of web application vulnerabilities. OWASP is a technical forum where everyone can join and contribute to the creation of a knowledge base for application protection. All of the materials are licenced as free and open source software. The top 10 initiative, which provides the OWASP top 10 vulnerabilities lists, is an example of the organization’s function.
OWASP publishes a list of the top 10 web application security vulnerabilities that are widely abused by hackers (ranked by risk) every few years, along with guidelines for dealing with these attacks. The list serves as an identification guide for security personnel and organisations, allowing them to better consider their current security situation and become better prepared to identify and minimise risks.
OWASP Top 10 Vulnerabilities
OWASP issues an open call for data to the market, and organisations that do safe code tests, penetration testing, and other related services send in their data anonymously. After that, the information is compiled to determine the frequency of each risk, and each vulnerability is given a score based on its exploitability, prevalence, detectability, and technological effects.
Let’s take a peek at the latest OWASP top 10 threats list (from 2017) and how to mitigate these dangers.
Injection bugs can result in a variety of undesirable and tragic results, ranging from verbose error messages to the leakage of sensitive details. SQL injection, LDAP injections, and file system injections are examples of injection weaknesses. Injection errors, which were added to the OWASP list in 2013, exist when a programme accepts user-supplied data (in a form area or a search query) and sends it to the backend database or server without sufficient input validation tests. Without sufficient input sanitization, a hacker might create a string with the intent of manipulating the programme, and the query will be executed on the server.
For server-side input validation, use a mix of parameterized requests, stored procedures, performance escaping, and whitelists.
In the event of a successful injection attack, use database controls including LIMIT to avoid mass exposure.
Broken authentication, including injection, has been in the OWASP top 10 vulnerability list since 2013. Through compromising passwords, session tokens, and other authentication information, attackers may impersonate legitimate users. The technological ramifications are important. You will theoretically have access to all services on their website or application if you could log in as anyone else.
Use a combination of tactics to mitigate your risks:
- Multi-factor authentication can be implemented (MFA).
- Where possible, without using the default credentials.
- Good password protocols should be implemented.
- As a prevention measure, use controls like delayed missed logins, randomised session IDs, session timeouts, and so on.
- Make a note of any unsuccessful authentication attempts.
Sensitive Data Exposure
Financial documents, health records, user passwords, and other personal data that should normally be encrypted or hidden is exposed in plaintext as a result of this weakness. This means that hackers could use man-in-the-middle (MitM) attacks to steal data in transit to obtain access to certain information. Over the last few years, exposing sensitive data has become more popular. As a result, it has risen three spots from its previous list ranking in 2013.
- Determine the level of sensitivity of the application data being handled, stored, or exchanged, and apply controls accordingly.
- Enforce coding and use common algorithms and key control.
- Disable caching for confidential data responses and stop saving data that isn’t needed.
XML External Entities (XXE)
XXE makes use of XML parsers in a web application to process and execute payloads that are used as external references in the XML text. Based on the statistics provided by organisations using static analysis software, this vulnerability was added to the list. They’ve seen that this flaw in XML processing has slowly gained momentum and has become a more significant challenge to web applications over the last couple of years.
An intruder can launch a denial of service (DoS) or SSRF attack by adding or changing these entities in an XML file and pointing them to a malicious source. Internal devices can be scanned, ports can be scanned, data can be extracted, and so on.
An attacker trying to steal data from the server is depicted in the following OWASP attack scenario:
- To avoid aggressive data in XML documents, implement server-side input authentication, sanitization tests, and other steps.
- Disable the processing of XML foreign entities and DTDs.
- Timeouts should be included, and any location where uploads are rendered should be checked.
- Avoid serialisation of confidential files, use simpler formats like JSON, and patch all XML processors and libraries.
Broken Access Control
In the most recent OWASP vulnerabilities list, two groups from the 2013 list combined into fragmented access control: missing feature level access control and unreliable direct object references. Broken access control is a flaw in the access control mechanism that allows attackers to circumvent authorization and obtain privileged user access. An application might, for example, allow users to change which account they are logging into simply by changing a portion of the URL.
- Deny all other services by default, with the exception of public resources, and keep records of access control violations to notify administrators.
- Access security tests can be implemented and reused in the programme, with cross-origin resource sharing (CORS) implementation being minimised.
This definition encompasses the incorrect installation of a broad range of controls that protect application data. This flaw can be caused by misconfiguring protection headers, ignoring verbose error messages that leak confidential information, failing to repair or update programmes, and using default settings. Such misconfigurations can be detected using dynamic programme security monitoring (DAST).
- Implement a safe installation procedure that includes device hardening. Remove (or don’t instal) any features or frameworks that aren’t in usage.
- Implement a zero-trust paradigm with a “segmented programme architecture” that requires only the desired actions while preventing the remainder. With segmentation, containerization, and ACLs, this helps to provide a safe distinction between components or tenants.
- Be sure to check all permissions, upgrade settings, and apply updates as well.
Cross-Site Scripting (XSS)
Cross-site scripting has dropped from third place in 2013 to seventh place in 2017 on the OWASP top 10 vulnerabilities list, not that it has gotten any worse, but because other vulnerabilities also taken precedence. It’s also a common flaw, accounting for more than two-thirds of all programme vulnerabilities reported to OWASP for the 2017 chart. In essence, the attacker injects a script into the website output of another web application. The browser is tricked into thinking the script is part of the website and executes it.
An attacker might, for example, give a victim an email with a malicious connection that seems to come from a reputable source. The code is executed in the victim’s web browser after they click the connection, and it can be used to steal session cookies, user passwords, or deliver malware.
Use frameworks that filter out XSS by default, such as the new Ruby on Rails.
As a mitigating step, use data escape strategies, use context-sensitive encoding, and allow content protection policy (CSP).
Serialization is the process of transforming an object from programme code into a stream of bytes or a format that can be used for various uses such as transferring data over the Internet or storing data on a disc. Deserialization, on the other hand, is the process of transforming serialised data into objects that can be used by the programme. This attack occurs when these data structures are tampered with, resulting in severe effects such as a distributed denial of service (DDoS) attack or remote code execution when deserialized at the other end.
- Accepting serialised objects from untrusted sources is not a good idea.
- During deserialization, perform integrity checks and apply strict sort restrictions.
- When tracking deserialization, keep track of all anomalies and delays, and block all network access to containers or servers that deserialize.
Using Components with Known Vulnerabilities
The common problem of using components such as libraries to enforce a certain feature without first checking their validity or using modified versions of those components is addressed in this portion of the OWASP top 10 vulnerabilities chart. The exploitability score varies based on the type and location of the flaw. If a flaw in a public-facing web server is more exploitable than a vulnerability in a less accessible feature or library, for example. Attackers search for security vulnerabilities in these modules, and when developers reuse them through many websites, a vulnerability exploited on one page may expose hundreds of others.
- Just use materials from official suppliers, and keep a current inventory. Remove all redundant dependencies, functions, or elements.
- For both client and server-side modules, as well as their dependencies, keep an eye out for version changes and fixes.
- Track sources such as CVE for bugs in the components on a regular basis.
Insufficient Logging & Monitoring
Organizations must record incidents that are of concern to them in the form of a web application in order to detect data breaches. The average time it takes for a security violation to be discovered is more than six months, leaving criminals plenty of time to cause mayhem. In your web application, logging refers to tracking the existence of an event or a security incident, such as multiple failed login attempts from the same IP address. Monitoring, on the other hand, entails maintaining a constant watch on these logs in order to escalate to the incident management (IR) team for prompt intervention.
- Ensure that all unauthorised events (such as failed logins, access control failures, input authentication failures, and so on) are logged in a manner that can be fed into a centralised log management solution to detect malicious accounts.
- To avoid tampering or deletion, keep comprehensive audit trails for critical transactions.
- Create a roadmap for responding to and recovering from an incident.
Injection, XSS, and other issues begin to surface in the list of OWASP vulnerabilities year after year as a result of the errors we continue to make when writing code and checking. To prevent a bias for functionality over protection when transferring instructions to developers, management must adopt a security-driven mentality. It’s past time for defence to stop being an afterthought in the software development life cycle and become an integral part of the process from the beginning.