abstract security

OWASP: What Is It and Why Should All Developers Know About It?

In the world of software and application development, OWASP principles and techniques are becoming increasingly popular.

Don’t you know what they are yet? Don’t worry: I’ll explain it to you right away!

OWASP is an acronym which stands for Open Web Application Security Project.
It is therefore a project, an initiative born with the aim of disseminating the principles of secure code in the development phases of a software.

Let’s see together what it is and why a developer should know it.

What is OWASP?

As we anticipated, OWASP is an international non-profit open-source initiative born in 2001 with the aim of creating a series of guidelines but also of practical tools, useful to support web developers in the secure development of web applications.
Being an open source project, all the resources made available to the community are freely available to anyone who wants to put security at the center of their development project.

What are The Principles of OWASP?

The techniques and principles defined by OWASP are becoming internationally recognized best practices for the prevention of IT vulnerabilities.
Through the systematic application of these procedures the developer can considerably reduce the risk of data breach ( data breach / loss) caused by hacker attacks and facilitated by poor code quality.
For the moment, these are optional indications, but in various contexts we are trying to make them mandatory for web development.
A step forward in this sense was taken with the adoption of the GDPR (General regulation for the protection of personal data) which requires compliance with data protection from the design of a software, according to the principle of privacy by design.

So let’s get to the more concrete aspects: what are the fundamental principles of OWASP?

Threat Classification or “Know your enemy”

“If you know the enemy and yourself, your victory is certain.”

This quote from “The Art of War” by Sun Tzu, a famous Chinese general and philosopher, helps us to understand that the process of identifying and classifying potential cyber threats is fundamental in terms of secure development.

In fact, this analysis makes it possible to build safe applications from the very beginning precisely because it takes into consideration which are the attack techniques and which are the most easily reachable targets and therefore deserving of greater protection.

According to OWASP, the classification of threats must follow an approach based on several points, among which we highlight:

Subdivision of the Application

Analyzing the application piece by piece is essential to understand the function of each single part and its interaction with external entities.
This allows you to find:

  • the access points through which a potential attacker could interact with the application
  • identify the assets and areas to which the attacker may feel attracted
  • classify the security levels (and therefore the access permissions ) that the application will have to assign to external entities
    Identification of countermeasures and mitigations
  • The logical step immediately following the identification of weaknesses and threats is certainly that of countermeasures.
  • Each threat must be associated with a specific countermeasure which, if not able to completely eliminate the risk, can at least mitigate it.
  • Code security review or “The devil is in the details
  • When we talk about code review we refer to the process of manually inspecting the source code of an application to check for any security problems.
  • By analyzing the source code, the developer tester examines each line of software code to verify that security controls are in place and in effect and accurately classifies any types of vulnerabilities found.
  • The code review allows you to find, for example, problems relating to encryption, access control, malware, etc.

Manual Inspections and Revisions or “The Human Factor”

These are typically “human” checks aimed at verifying the perception that a subject has of a specific application and its functioning.
By asking someone how something works and why they have implemented it in a specific way, the developer performing manual verification can quickly determine if security issues are likely to occur.
Manual reviews are particularly useful for verifying whether people understand the security process, have been informed about the security process, and have the appropriate skills to design or implement secure applications.

hacker

Penetration Test or “In the Shoes of a Hacker”

The Penetration Test (also called Pen Test ) allows you to test the security level of an information system or web application by simulating a hacker attack.
The developer acts as an attacker and attempts to find and exploit vulnerabilities.
Clearly the intruder, through his action, helps to identify only a small representative sample of all possible security risks in a system.
It follows that the Pen Test alone can not be the only tool to use.
However, targeted Pen Tests – tests that attempt to exploit known vulnerabilities found in previous revisions – can be helpful in understanding whether specific vulnerabilities have actually been fixed in the distributed source code.

What is The OWASP Top 10?

Among the various information on cyber security that emerge from the OWASP community, there is also a list, made public for the first time in 2003 with the aim of making developers aware of the most important dangers that threaten applications and software.
We are talking about the famous OWASP Top 10.

Injection (literally “code injection”)

Injections such as SQL injection, LDAP injection and CRLF injection occur when untrusted data is passed from one software to another.
The attacker’s hostile data can trick the victim software into executing unintended commands or accessing the data without proper authorization.

Authentication Aborted

If the application functions relating to authentication and session management are not developed correctly, the hacker can steal passwords, session tokens, cookies in order to impersonate other users and take control of the system.

Exposure of Sensitive Data

Sensitive data requires greater protection (for example through encryption) than data of lesser importance.
Unfortunately, many web applications and APIs do not adequately protect sensitive data, allowing cybercriminals to steal and market it.

Access Control Interrupted

The restrictions on what authenticated users can often not be applied correctly.
Attackers can exploit these programming flaws to access unauthorized features and data, access other users ‘accounts, view sensitive data, modify other users’ data, change access rights, etc.

Incorrect Security Configuration

The misconfiguration of security is certainly the most common problem.

It is often the result of insecure default configurations or incomplete configurations.
It should be remembered that not only must all operating systems, frameworks, libraries and applications be configured securely, but they must also be updated in a timely manner.

Cross-Site Scripting (XSS)

This is a vulnerability that is exploited by attackers to introduce malicious code into the victim’s browser in order to hijack user sessions, deface websites or redirect the user to malicious sites.

Insecure Deserialization

While deserialization issues don’t involve remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

Use of Components with Known Vulnerabilities

Applications and APIs that use components with known vulnerabilities can undermine application defenses and allow for very serious attacks.

Insufficient Logging and Monitoring

Failure to monitor and integrate incident response processes allows attackers to attack systems and remain there for a long time with the aim of tampering with, extracting or destroying data.
Most breach studies show that the time it takes to detect a breach exceeds 200 days and that the breach is generally detected by external parties rather than internal monitoring processes.