OWASP: Riferimento alla Sicurezza delle Applicazioni Web

Pubblicato da

 

La sicurezza delle applicazioni moderne è una sfida sempre più complessa. OWASP, una delle principali organizzazioni mondiali dedicate alla sicurezza del software, offre risorse, standard e strumenti open-source per aiutare sviluppatori e professionisti a costruire applicazioni più sicure. In questa guida approfondiremo cos’è OWASP, analizzeremo nel dettaglio la OWASP Top 10 e scopriremo i migliori progetti per imparare in modo pratico la sicurezza informatica.

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!


Cos’è OWASP

OWASP (Open Web Application Security Project) è una fondazione no-profit e una comunità globale di professionisti (sviluppatori, security engineer, ricercatori, pentester) che produce risorse open-source per migliorare la sicurezza delle applicazioni. L’obiettivo principale è rendere la sicurezza applicativa accessibile e praticabile: linee guida, tool, checklist, training e progetti didattici gratuiti che possono essere usati da singoli sviluppatori fino ad aziende e governi.


Caratteristiche principali

  • Community-driven: i contenuti nascono da contributi aperti e revisioni da parte della comunità.
  • Open source: documenti, tool e progetti sono liberamente consultabili e riutilizzabili.
  • Pragmatico: focus su problemi reali, esempi pratici, strumenti per test e mitigazioni concrete.
  • Rilevanza industriale: molte organizzazioni usano le linee guida OWASP come riferimento operativo per valutazioni e requisiti di sicurezza.

OWASP Top 10

La OWASP Top 10 è una lista delle categorie di rischio più critiche per le applicazioni web. Non è esaustiva, ma è un ottimo punto di partenza per capire dove concentrare controlli e testing. Ogni voce qui sotto contiene: che cos’è, esempi pratici, come rilevarla/testarla e mitigazioni consigliate.

1) Broken Access Control (Controlli di accesso mancanti o errati)

Che cos’è: autorizzazioni insufficienti o controlli di accesso implementati male che permettono azioni non autorizzate (vedere, modificare, cancellare dati di altri, escalation di privilegi).

Esempi: modificare user_id nell’URL per accedere ai dati di un altro utente; endpoint API che non verifica il ruolo prima di operazioni sensibili.

Come testare: provare manipolazione di ID/parametri, chiamare API con diversi livelli di privilegio, testare endpoint non pubblicizzati.

Mitigazioni: 

  • Verificare l’autorizzazione sul server per ogni operazione sensibile (non solo sul client)
  • Principle of least privilege (ruoli minimi)
  • Implementare policy RBAC/ABAC centralizzate
  • Evitare la sicurezza basata solo su “segreti” nel client (es. hidden fields)

2) Cryptographic Failures (Errori nella crittografia / protezione dati sensibili)

Che cos’è: uso errato o insufficiente della crittografia, esposizione di dati sensibili in chiaro (password, carte, token).

Esempi: memorizzare password in testo chiaro, usare algoritmi deboli (MD5), non usare TLS per trasferimenti sensibili.

Come testare: cercare dati sensibili non cifrati in DB, log o risposte API; verificare configurazione TLS; controllare algoritmi di hashing.

Mitigazioni:

  • Store password con hashing sicuro (bcrypt/Argon2/PBKDF2) + salt univoco
  • Transit: TLS 1.2/1.3 con configurazione sicura
  • Crittografia per dati a riposo se necessario (field-level encryption)
  • Gestione sicura delle chiavi (KMS, rotazione, accesso limitato)

Esempio (hashing password — pseudocodice Python)

from passlib.hash import bcrypt
hashed = bcrypt.hash("SuperPassword123")
bcrypt.verify("SuperPassword123", hashed)

3) Injection

Che cos’è: inserimento di dati malevoli in comandi o query che il server esegue (SQL, NoSQL, OS, LDAP...) con possibile esecuzione di comandi non previsti.

Esempi: SQL injection (' OR 1=1 --), concatenare input alla shell.

Come testare: fuzzing e input malformati, usare payload noti per SQLi/command injection, scanners automatici.

Mitigazioni:

  • Uso di query parametrizzate / prepared statements (mai concatenare stringhe).
  • Validazione e sanitizzazione centrata sul contesto.
  • Minimizzazione privilegi DB.
  • Whitelisting per input strutturati (es. ID numerici).

Esempio (prevenire SQLi in Python con query parametrizzata)

cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

4) Insecure Design (Progettazione insicura)

Che cos’è: mancanza di considerazioni di sicurezza nella fase di design/architettura: assenza di threat modeling, controlli insufficienti e decisioni progettuali rischiose.

Esempi: servizi interni esposti pubblicamente, nessuna separazione di responsabilità, assenza di rate limits per operazioni sensibili.

Come testare: review architetturale, threat modeling, analisi dei flussi dati, revisione dipendenze e modello di trust.

Mitigazioni:

  • Threat modeling (STRIDE, PASTA) durante design
  • Security by design: fail-secure defaults, defense in depth
  • Revisione architetturale e policy di sicurezza integrate nel ciclo di sviluppo


5) Security Misconfiguration (Errata configurazione)

Che cos’è: configurazioni insicure nel server, framework o servizi (debug mode attivo, directory listing, default creds).

Esempi: header di sicurezza mancanti, bucket S3 pubblici per errore.

Come testare: scanner di configurazione, ispezione header HTTP, verifica default passwords, controlli su file e directory.

Mitigazioni: 

  • Hardening delle configurazioni (principi di sicurezza per web server, database, framework)
  • Rimozione di funzionalità non usate, disabilitare debug in produzione
  • Automatizzare la gestione della configurazione (IaC con check di security)

Header utili da aggiungere: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security.


6) Vulnerable and Outdated Components (Componenti vulnerabili / non aggiornati)

Che cos’è: uso di librerie, framework o immagini container con vulnerabilità note che permettono compromissione.

Esempi: dipendenze con CVE note non aggiornate; immagini container con software vulnerabile.

Come testare: dependency scanning (SCA), SBOM, verifica versioni e CVE.

Mitigazioni: 

  • Aggiornamento regolare delle dipendenze e patching
  • Usare tool di SCA (dependency-check, OWASP Dependency-Track)
  • Monitoraggio CVE e policy di gestione delle patch
  • Limitare superfici esposte da componenti esterni


7) Identification and Authentication Failures

Che cos’è: meccanismi di autenticazione deboli o implementati male che permettono takeover di account o bypass.

Esempi: session management debole (session fixation), password reset non sicuro, mancanza di MFA per operazioni sensibili.

Come testare: test login brute force, session fixation attempts, analisi dei flussi di reset password e token.

Mitigazioni:

  • Implementare MFA/2FA per operazioni sensibili
  • Usare token sicuri per sessioni, con scadenza e revoca
  • Limitare tentativi di login (rate limiting), account lockout o challenge
  • Proteggere endpoint di reset password con verifica e limiti


8) Software and Data Integrity Failures

Che cos’è: assenza di verifiche sull’integrità del codice o dei dati (es. aggiornamenti non firmati, assenza di controllo su artefatti CI/CD).

Esempi: pipeline CI che consente artefatti non firmati o pacchetti da repository non verificati; uso di plugin non firmati.

Come testare: verificare firme digitali sui pacchetti, analizzare pipeline CI/CD per possibili injection di artefatti, controllare verifiche di integrità.

Mitigazioni:

  • Firmare artefatti e verificare firme in produzione
  • Restrizioni su repository autorizzati, controllo degli accessi nella pipeline
  • Automazione di scansioni di integrità e controllo sulle build


9) Security Logging and Monitoring Failures

Che cos’è: logging insufficiente o monitoring mancante che impedisce di rilevare e rispondere tempestivamente a incidenti.

Esempi: nessun log di accesso privilegiato, log non conservati o non protetti, assenza di alert su anomalie.

Come testare: controllare log coverage, riprodurre eventi e verificare che vengano loggati e generino alert.

Mitigazioni:

  • Loggare eventi di autenticazione, autorizzazione, errori critici e attività amministrative
  • Proteggere e centralizzare i log (SIEM), definire retention e alerting
  • Procedure di incident response e playbook


10) Server-Side Request Forgery (SSRF)

Che cos’è: un’applicazione riceve un URL/endpoint da un utente e il server fa richieste verso risorse interne o esterne usando quell’input, consentendo l’accesso a network interni o metadata service.

Esempi: url che permette all’attaccante di richiedere http://169.254.169.254/latest/meta-data/ su cloud provider, esfiltrando dati sensibili.

Come testare: fornire indirizzi interni, indirizzi IP come 127.0.0.1 o 169.254.169.254, o usare strumenti che rilevano redirection verso host interni.

Mitigazioni:

  • Whitelist di domini/indirizzi consentiti; non usare blacklist
  • Validare e normalizzare gli input URL
  • Ricorrere a proxy o servizi che filtrano richieste in uscita; separare rete interna da servizi pubblici


Progetti utili per imparare la sicurezza (OWASP e non solo)

Ecco una collezione di progetti e risorse pratiche, ordinati per tipo (tool di test, ambienti d’apprendimento, standard e checklist). Questi sono ampiamente usati nella community e sono eccellenti per apprendere in modo pratico.


🏛️ Ambienti e app didattiche

  • OWASP Juice Shop — applicazione intenzionalmente vulnerabile, eccellente per esercitazioni e CTF: molte vulnerabilità moderne presenti.
  • OWASP WebGoat — laboratorio didattico con lezioni passo-passo su diverse vulnerabilità.
  • Broken Web Applications VM — raccolta di applicazioni vulnerabili per test in locale/VM. Questi permettono di esercitarsi in un ambiente controllato: attacchi, exploitation e mitigazioni.


🔧 Tool per testing / scansione

  • OWASP ZAP (Zed Attack Proxy) — scanner/ proxy per test automatici e manuali di sicurezza web (intercetta traffico, fuzzing, active scan).
  • Burp Suite (non OWASP ma molto usato) — proxy professionale per pentest web.
  • OWASP Dependency-Check / Dependency-Track — per individuare librerie con CVE note nelle dipendenze.


📕 Guide, standard e checklist

  • OWASP Top 10 — per priorizzare i rischi.
  • OWASP ASVS (Application Security Verification Standard) — standard dettagliato per definire requisiti di sicurezza applicativa (livelli di verifica).
  • OWASP Testing Guide — guida completa per test di sicurezza (manuale operativo).
  • OWASP Cheat Sheet Series — raccolta di best practice e snippet pratici su molte tematiche (XSS, CSRF, password storage, ecc.).
  • OWASP Proactive Controls — elenco di controlli raccomandati per sviluppatori.


🤖 Tool di supporto e automazione

  • ModSecurity — WAF open-source per protezione a livello web server.
  • Snyk / Dependabot / Renovate — strumenti (alcuni commerciali) per aggiornamento e scan automatico delle dipendenze.
  • Trivy / Clair — scanner immagini container per vulnerabilità.


🎓 Learning path consigliato (pratico)

  1. Concetti di base: leggere le Cheat Sheets su input validation, authentication, session management.
  2. Hands-on: eseguire Juice Shop/WebGoat localmente; risolvere challenge.
  3. Proxy e testing: imparare a usare ZAP o Burp per analizzare traffico, testare XSS/SQLi/CSRF.
  4. Dependency scanning: eseguire Dependency-Check su un progetto esistente e correggere findings.
  5. Threat modeling & ASVS: eseguire threat modeling su una piccola app e mappare requisiti ASVS.
  6. CI/CD security: integrare scansioni automatiche (SCA, SAST, composition analysis) nella pipeline.
  7. Partecipare: contribuire a progetti OWASP o partecipare a meetup/CTF per consolidare esperienza.


Esempi pratici e snippet utili

1) Prevenire SQL Injection (Node.js con parameterized query)

// usando parameterized queries con pg (Postgres)
const text = 'SELECT * FROM users WHERE email = $1';
const values = [userInputEmail];
const res = await client.query(text, values);

2) Prevenire XSS (output encoding in HTML)

Principio: non inserire direttamente input utente nell’HTML senza escaping. Usa funzioni di escape del framework o librerie.

<div>{{ escapeHtml(userComment) }}</div>

3) Proteggere API con JWT e controllo ruoli

Validare signature JWT, controllare exp, usare scopes/roles e verificare server-side che il token corrisponda alla risorsa richiesta.


Consigli pratici per chi è alle prime armi

  • Impara con esempi reali: teoria + pratica insieme (es. fare un attacco XSS su Juice Shop ti aiuta a ricordare le mitigazioni).
  • Segui una checklist: ASVS o Cheat Sheets per cosa controllare in ogni release.
  • Automatizza i controlli ripetitivi: scanner, SCA e policy CI riducono il carico.
  • Threat modeling precoce: risolve molti problemi prima che diventino bug.
  • Condividi conoscenza: code review con attenzione alla security e pair programming aiutano a far crescere il team.
  • Non cercare la perfezione: applica controlli proporzionati al rischio (risk-based approach).


Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment