Cos'è OWASP? Cos'è la Top 10 OWASP?

Open Web App Security Project gestisce un elenco dei problemi più urgenti per la sicurezza delle applicazioni Web. Viene aggiornato a intervalli regolari.

Obiettivi di apprendimento

Dopo aver letto questo articolo sarai in grado di:

  • Definire OWASP
  • Riepilogare i singoli punti del report OWASP Top 10

Argomenti correlati


Vuoi saperne di più?

Abbonati a theNET, il riepilogo mensile di Cloudflare sulle tematiche più discusse in Internet.

Fai riferimento all'Informativa sulla privacy di Cloudflare per scoprire come raccogliamo ed elaboriamo i tuoi dati personali.

Copia link dell'articolo

Cos'è OWASP?

Open Web app Security Project, o OWASP, è un'organizzazione internazionale senza scopo di lucro dedicata alla sicurezza delle applicazioni Web. Uno dei principi fondamentali di OWASP è che tutti i loro materiali siano disponibili gratuitamente e facilmente accessibili sul proprio sito Web, consentendo a chiunque di migliorare la sicurezza della propria applicazione Web. I materiali che offrono includono documentazione, strumenti, video e forum. Forse il loro progetto più noto è la Top 10 di OWASP.

Guida
2023 Gartner® Market Guide for Cloud WAAP
Ebook
Everywhere Security per ogni fase del ciclo di vita dell'attacco

Cos'è la Top 10 OWASP?

The OWASP Top 10 is a regularly updated report outlining security concerns for web application security, focusing on the 10 most critical risks. The report is put together by a team of security experts from all over the world. OWASP refers to the Top 10 as an ‘awareness document’ and they recommend that all companies incorporate the report into their processes in order to minimize and/or mitigate security risks.

Protezione WAF
Difenditi dalle tecniche di attacco "Top 10"

Below are the security risks reported in the OWASP Top 10 2021 report:

1. Controllo degli accessi interrotto

Access control refers a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example a web application could allow a user to change which account they are logged in as simply by changing part of a URL, without any other verification.

Il controllo degli accessi può essere protetto facendo in modo che un'applicazione Web utilizzi il token di autorizzazione* e imposti rigorosi controlli su questo.

*Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are, without having to constantly enter their login credentials.

2. Cryptographic Failures

If web applications do not protect sensitive data such as financial information and passwords using encryption, attackers can gain access to that data and sell or utilize it for nefarious purposes. They can also steal sensitive information by using an on-path attack.

The risk of data exposure can be minimized by encrypting all sensitive data, authenticating all transmissions, and disabling the caching* of any sensitive information. Additionally, web application developers should take care to ensure that they are not unnecessarily storing any sensitive data.

*Caching is the practice of temporarily storing data for re-use. For example, web browsers will often cache webpages so that if a user revisits those pages within a fixed time span, the browser does not have to fetch the pages from the web.

3. Injection

Gli attacchi di injection si verificano quando vengono inviati dati non attendibili a un interprete di codice tramite l'input di un modulo o un altro invio di dati a un'applicazione Web. Ad esempio, un autore di un attacco potrebbe inserire il codice del database SQL in un modulo che prevede un nome utente in chiaro. Se l'input del modulo non è protetto correttamente, potrebbe comportare l'esecuzione di quel codice SQL. Questo è noto come attacco di SQL injection.

The Injection category also includes cross-site scripting (XSS) attacks, previously their own category in the 2017 report. Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests, as well as using modern web development frameworks like ReactJS and Ruby on Rails, which provide some built-in cross-site scripting protection.

In general, Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

Scopri di più su come prevenire le SQL injection.

4. Insecure Design

Insecure Design includes a range of weaknesses that can be emdedded in the architecture of an application. It focuses on the design of an application, not its implementation. OWASP lists the use of security questions (e.g. "What street did you grow up on?") for password recovery as one example of a workflow that is insecure by design. No matter how perfectly such a workflow is implemented by its developers, the application will still be vulnerable, because more than one person can know the answer to those security questions.

The use of threat modeling prior to an application's deployment can help mitigate these types of vulnerabilities.

5. Configurazione errata della sicurezza

L'errata configurazione della sicurezza è la vulnerabilità più comune ed è spesso il risultato dell'utilizzo di configurazioni predefinite o della visualizzazione di errori eccessivamente dettagliati. Ad esempio, un'applicazione potrebbe mostrare a un utente errori eccessivamente descrittivi che potrebbero rivelare vulnerabilità nell'applicazione. Questo può essere mitigato rimuovendo tutte le funzionalità inutilizzate nel codice e garantendo che i messaggi di errore siano più generali.

The Security Misconfiguration category includes the XML External Entities (XEE) attack — previously its own category in the 2017 report. This is an attack against a web application that parses XML* input. This input can reference an external entity, attempting to exploit a vulnerability in the parser. An ‘external entity’ in this context refers to a storage unit, such as a hard drive. An XML parser can be duped into sending data to an unauthorized external entity, which can pass sensitive data directly to an attacker. The best ways to prevent XEE attacks are to have web applications accept a less complex type of data, such as JSON, or at the very least to patch XML parsers and disable the use of external entities in an XML application.

*XML or Extensible Markup Language is a markup language intended to be both human-readable and machine-readable. Due to its complexity and security vulnerabilities, it is now being phased out of use in many web applications.

6. Vulnerable and Outdated Components

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or A/B testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers do not always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensure that they are receiving components from a trusted source that are up to date.

7. Identification and Authentication Failures

Le vulnerabilità nei sistemi di autenticazione (accesso) possono fornire agli autori di un attacco l'accesso agli account utente e persino la possibilità di compromettere un intero sistema utilizzando un account amministratore. Ad esempio, un autore di un attacco può sottrarre un elenco con migliaia di combinazioni di nome utente e password note ottenute durante una violazione dei dati e utilizzare uno script per provare tutte quelle combinazioni su un sistema di accesso per scoprire se una di queste può essere violata con successo.

Alcune strategie per mitigare le vulnerabilità di autenticazione richiedono l'autenticazione a due fattori (2FA) e la limitazione o il ritardo dei tentativi di accesso ripetuti utilizzando la limitazione della frequenza.

8. Software and Data Integrity Failures

Many applications today rely on third-party plugins and other external sources for their functionality, and they do not always make sure that updates and data from those sources have not been tampered with and originate from an expected location. For instance, an application that automatically accepts updates from an outside source could be vulnerable to an attacker uploading their own malicious updates, which would then be distributed to all installations of that application. This category also includes insecure deserialization exploits: these attacks are the result of deserializing data from untrusted sources, and they can result in serious consequences like DDoS attacks and remote code execution attacks.

To help ensure data and updates have not had their integrity violated, application developers should use digital signatures to verify updates, check their software supply chains, and ensure that continuous integration/continuous deployment (CI/CD) pipelines have strong access control and are configured correctly.

9. Security Logging and Monitoring Failures

Molte applicazioni Web non stanno adottando misure sufficienti per rilevare le violazioni dei dati. Il tempo medio di rilevamento di una violazione è di circa 200 giorni dopo che si è verificata. Questo dà ad autore di un attacco molto tempo per causare danni prima che ci sia una risposta. OWASP consiglia agli sviluppatori Web di implementare la registrazione e il monitoraggio, nonché un piano di risposta agli incidenti per garantire che siano informati degli attacchi alla propria applicazione.

10. Server-Side Request Forgery

Server-Side Request Forgery (SSRF) is an attack in which someone sends a URL request to a server that causes the server to fetch an unexpected resource, even if that resource is otherwise protected. An attacker might, for example, send a request for www.example.com/super-secret-data/, even though web users are not supposed to be able to navigate to that location, and get access to super secret data from the server's response.

There are a number of possible mitigations for SSRF attacks, and one of the most important is to validate all URLs coming from clients. Invalid URLs should not result in a direct, raw response from the server.

For a more technical and in-depth look at the OWASP Top 10, see the official report.