OWASP and Its 10 Vulnerabilities

In this post, we'll discuss10 vulnerabilities of the open web application security project (OWASP) and share some preventive measures to guard against them.

The full form of OWASP is the Open Web Application Security Project. It is a non-profit group that helps a variety of organizations to develop, purchase, and maintain software applications that can be trusted. The educated developers, designers, architects, and business owners all are sought by OWASP to identify the risk associated with the most common web application security vulnerabilities.

OWASP is known as a forum as it supports both open source and commercial security products in which information technology professionals can network and build expertise. The materials which are needed by the organizations are available for the free and open software license.

Top 10 Vulnerabilities of OWASP

OWASP is the open call for data and best for companies to perform secure code reviews, penetration testing, etc., and can send their data anonymously. For producing a frequency of each risk and each vulnerability, the data will be collated and assigned based on the score on its exploitability, prevalence, detectability, and technical impact.

Injection

The sensitive information can be leaked from verbose error messages and injection flaws can lead to major undesirable and disastrous outcomes. The injection flaws are not limited to SQL injection, LDAP injections, or file system injections. Since 2013 the injection flaws in the OWASP list occur when the applications enter into the user-supplied data which will pass onto the blackened database or server without proper input validation checks. The intention of the hacker is of exploiting the application so he/she will craft a string accordingly.

Some preventive measures are:

Use parameterized queries combination, stored procedures, output escaping, and whitelists for validating server-side input.

Use LIMIT (a database control) for preventing mass disclosure in case of a successful injection attack.

Broken Authentication

Since 2013 just like injection, broken authentication also not changed its position in the OWASP top 10 vulnerabilities list. The attackers can impersonate legitimate users if the system authentication is misconfigured by compromising passwords, session tokens, etc. there will be a severe technical impact. You can potentially access all the resources of the website or application if you logged in like anybody else. Below are the preventive measures:

Multi-factor authentication (MFA) should be implemented.

Try to avoid using default credentials.

Password policies should be very strong.

Prevent the pages from delayed failed logins, randomized session IDs, session timeouts, etc.

Sensitive Data Exposure

Most of the data related to financial information, health records, user credentials, etc., come under sensitive data, and in this vulnerability, this type of data should be usually encrypted or kept hidden so that it will be visible as plaintext. The hackers can access this information also by executing man-in-middle (MiM) and stealing the data in transit. In the past several years, the exposure of sensitive data has become more common. Some preventive measures are listed below:

The data which is being processed, stored, or transmitted should classify the application by the level of sensitivity and apply some controls on them accordingly.

Encryption should be enforced.

The standard algorithms and proper key management system should be used.

The caching responses that contain sensitive data should be disabled and stop storing unnecessary data.

XML External Entities (XXE)

XXE can get some benefit of the XML parsers in a web application and this might process and execute some of the load of payment that includes external reference in the XML document. The list that is based on statistics, this vulnerability is added in that and this statistics list is returned by the companies running static analysis tools. They have seen that in the last couple of years this vulnerability has steadily gained traction in XML processing and has become a more serious risk to web applications.

If these entities are added or modified by attackers in the XML files and the malicious source is pointed in them then they can cause a denial of service (DoS) attack or an SSRF attack. Listed below are the preventive measures:

For preventing hostile data within XML documents try to implement server-side input validation, sanitization checks, etc.

XML external entity and DTD processing should be disabled.

The places where uploads are made use timeouts and test there.

Use less complicated formats for example – JSON.

Serialization of sensitive data should be avoided and all the XML processors and libraries need to be patched.

Broken Access Control

There are two categories in the OWASP vulnerability list named Missing function level access control and insecure direct object references. Both are merged into broken access control in the OWASP’s latest published list. The weakness in the access control system is referred to as Broken access control and this will allow attackers to gain access as privileged users through bypass authorization. Some preventive measures include:

All the other resources should be avoided by default except public resources and also logs should be maintained for access control failures and alert admins.

In the applications, implement and re-use the access control checks which includes minimizing cross-origin resource sharing (CORS) usage.

Security Misconfigurations

In this category, there is a wide variety of improper implementation that keeps the application data safe. There are various things like misconfiguring security headers, verbose error message ignoring that can leak sensitivity information, patch or upgrade system neglecting, etc. Remediation measures are discussed below –

A secure installation process should be implemented.

Use a “segmented application architecture” that gives the implementation of the zero-trust model and it allows only desired behaviour and block the unnecessary.

Cross-Site Scripting

Cross-site scripting lost its position from third to seventh place in the OWASP top 10 vulnerability list. It is just because other vulnerabilities have gained more precedence. Still, it is one of the common vulnerabilities that affects more than two-thirds of the applications. Some preventive measures are listed below:

Use the framework that filters out XSS by design like the latest Ruby on Rails.

Data escaping techniques, context-sensitive encoding application implementation, and content security policy (CSP) should be enabled as mitigation measures.

Insecure Deserialization

The serialization content is an object from the application code and converting it into a stream of bytes. Deserialization is just the opposite of it which refers to serialized data converting back into the objects usable by the application. Here are some preventive measures:

Serialized objects should not be accepted from untrusted sources.

Check integrity implementation and strict type constraints should be enforced during deserialization.

Using components With known Vulnerabilities

This section is mainly referring to the widespread issue for using the various components like the implementation of libraries to a certain functionality without verifying their first legitimacy. The score of exploitability is variable and depends on what and where the vulnerability is. Some of the preventive measures are:

Only components from official sources should be used and maintain a current inventory of them.

Sources like CVE should be monitored continuously for vulnerabilities in the components.

Insufficient Logging and Monitoring

The organizations need to log events to detect data breaches in the interesting context of their application. The recording of the occurrence of an event or security incidence in the web application is known as Logging. For example – repeated failed login attempts for the same IP. The continually keeping an eye on these logs that can escalate to the incidence response (IR) team for timely action is known as Monitoring. The preventive measures are:

All the suspicious activities should be logged so that malicious accounts can be identified.

Detailed audit trails should be maintained for essential transactions. It will prevent deletion or tampering.

An incident response and recovery plant should be established.

That's all! I hope this information helps you establish a strong security policy.

Conclusion

ZippyOPS Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, and Security

Services offered by us: https://www.zippyops.com/services

Our Products: https://www.zippyops.com/products

Our Solutions: https://www.zippyops.com/solutions

For Demo, videos check out YouTube Playlist:

https://www.youtube.com/watch?v=4FYvPooN_Tg&list=PLCJ3JpanNyCfXlHahZhYgJH9-rV6ouPro

If this seems interesting, please email us at [email protected] for a call.

Relevant Blogs:

Kubernetes multi-master

Config map

istio installation in kubernetes

canary deployment with istio