Cloud & IT Cert Prep · Lezione

Convalida degli input e codifica degli output

Implementi la convalida degli input lato server e la codifica degli output sensibile al contesto per neutralizzare le vulnerabilità di injection e XSS prima che possano essere sfruttate.

Convalida degli input e codifica degli output è una lezione Cloud & IT Cert Prep gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cloud & IT Cert Prep, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.

Perché gli input sono pericolosi

Ogni dato che un'applicazione riceve dall'esterno — input dei moduli compilati dagli utenti, parametri URL, intestazioni HTTP, corpi delle richieste API, file caricati — può essere controllato da un attaccante. In assenza di convalida, gli attaccanti possono inserire comandi SQL, script HTML, comandi shell e direttive XML/LDAP nei flussi di dati dell'applicazione. La convalida degli input e la codifica degli output sono i due controlli fondamentali che neutralizzano le vulnerabilità di injection prima che possano causare danni.

Che cos'è la convalida degli input?

La convalida degli input verifica che i dati ricevuti siano conformi al tipo, al formato, alla lunghezza e all'intervallo di valori previsti prima che l'applicazione li elabori. La convalida deve essere eseguita lato server: la convalida lato client in JavaScript può essere facilmente aggirata dagli attaccanti che intercettano le richieste con strumenti come Burp Suite. Un nome utente dovrebbe accettare solo caratteri alfanumerici; un campo data dovrebbe accettare solo formati di data validi; un campo email dovrebbe rispettare la sintassi RFC 5322.

# Server-side input validation examples:

# Validate username: allow only alphanumeric and underscore
# Pattern: ^[a-zA-Z0-9_]{3,20}$
# Reject: 'admin--', "' OR 1=1--", '<script>alert(1)</script>'

# Validate age: must be integer between 0 and 120
# Reject: -1, 999, 'abc', '18; DROP TABLE users'

# Validate email: match RFC 5322 pattern, max 254 chars
# Reject: 'a@b' (too short), attacker@evil.com<script>...

Convalida tramite allowlist e denylist

La convalida tramite allowlist (whitelist) specifica esattamente ciò che è consentito e rifiuta tutto il resto. La convalida tramite denylist (blacklist) specifica ciò che NON è consentito e permette tutto il resto. La convalida tramite allowlist è sempre preferibile, perché gli attaccanti scoprono continuamente nuove tecniche per aggirare le denylist. Ad esempio, le denylist contro la SQL injection cercano di bloccare SELECT, UNION e i caratteri --, ma codifiche creative consentono spesso di aggirare questi filtri. Un'allowlist che consente solo cifre in un campo numerico non può essere aggirata.

# Allowlist (GOOD): only allow expected characters
# username_pattern = '^[a-zA-Z0-9_]{3,20}$'
# If input does not match -> reject with 400 Bad Request

# Denylist (WEAK): try to block known-bad patterns
# reject_patterns = ["'", '--', 'UNION', 'SELECT', 'DROP']
# Problem: attacker uses: SE%00LECT, UNION%0aALL, encoded chars
# Denylist is incomplete by definition -> prefer allowlist

Le query parametrizzate prevengono la SQL injection

Per le interazioni con i database, le query parametrizzate (prepared statement) sono la difesa definitiva contro la SQL injection. La struttura della query viene definita separatamente dai dati forniti dall'utente, quindi il motore del database non interpreta mai l'input come sintassi SQL. Anche se un utente inserisce ' OR '1'='1, questo viene trattato come parametro stringa letterale e non come SQL eseguibile. Le query parametrizzate sono disponibili in tutti i principali linguaggi e driver di database.

# VULNERABLE: string concatenation (SQL injection possible)
# query = 'SELECT * FROM users WHERE name = ' + user_input
# Attack: user_input = "' OR '1'='1" -> returns ALL users

# SAFE: parameterized query
# query = 'SELECT * FROM users WHERE name = ?'
# cursor.execute(query, (user_input,))
# The ? is a placeholder; user_input is passed separately
# The DB driver handles escaping automatically
# Attack input: "' OR '1'='1" -> treated as literal string

Che cos'è la codifica degli output?

La codifica degli output converte i caratteri speciali presenti nei dati prima di inserirli in un contesto di output (HTML, JavaScript, SQL, URL, comandi shell). In questo modo si impedisce che i dati provenienti da un contesto vengano interpretati come codice eseguibile in un altro. Il principio fondamentale è la codifica consapevole del contesto: la codifica applicata deve corrispondere al contesto di output. La codifica HTML, la codifica URL, la codifica JavaScript e il quoting degli argomenti shell neutralizzano l'injection nei rispettivi contesti.

La codifica degli output HTML previene l'XSS

Quando i dati forniti dall'utente vengono visualizzati in HTML, i caratteri speciali devono essere sottoposti a codifica HTML per prevenire il Cross-Site Scripting (XSS). Il carattere < diventa <, > diventa > e & diventa &. Se un attaccante inserisce <script>alert('XSS')</script>, la codifica HTML lo visualizza come testo anziché eseguire lo script. Ogni framework web offre funzioni di codifica HTML: le utilizzi in modo coerente.

# Without encoding (VULNERABLE to XSS):
# html = '<p>Hello, ' + username + '</p>'
# If username = '<script>document.cookie</script>'
# -> script executes in victim browser

# With HTML encoding (SAFE):
# html = '<p>Hello, ' + html_encode(username) + '</p>'
# html_encode('<script>...') -> '&lt;script&gt;...&lt;/script&gt;'
# -> Displays as text, not executable script

Regole di codifica specifiche del contesto

Contesti di output diversi richiedono strategie di codifica diverse. Corpo HTML: codificare < > & ' ". Attributi HTML: codificare gli stessi caratteri e imporre inoltre l'uso di attributi tra virgolette. Contesto JavaScript: utilizzare la codifica JSON o l'escape delle stringhe JavaScript. Parametri URL: applicare la codifica percentuale ai caratteri speciali. Comandi shell: evitare del tutto di costruire comandi shell a partire da input dell'utente; utilizzare invece le API del linguaggio con array di argomenti, anziché concatenare stringhe con gli interpreti shell.

# Context-aware encoding examples:

# HTML body context:
# safe_html = '&lt;script&gt;' (renders as text)

# URL parameter context:
# safe_url = 'search?q=hello%20world%26more'

# JavaScript string context (in JSON):
# safe_js = '{"name": "O\\u0027Reilly"}'

# Shell command (AVOID string concat - use array instead):
# UNSAFE: os.system('ping ' + user_input)
# SAFE:   subprocess.run(['ping', '-c', '1', user_input])

Convalida a più livelli

La convalida degli input deve avvenire a più livelli, non solo sull'endpoint API. La convalida lato client migliora l'esperienza dell'utente (feedback immediato), ma non deve mai essere considerata affidabile ai fini della sicurezza. La convalida API/controller è il principale livello di sicurezza. La convalida nei servizi e nella logica di business applica le regole del dominio. I vincoli del database (NOT NULL, CHECK, FOREIGN KEY) forniscono un ultimo livello di difesa. La difesa in profondità fa sì che l'aggiramento di un livello non porti immediatamente allo sfruttamento della vulnerabilità.

Convalida dei caricamenti di file

Gli input relativi al caricamento di file sono particolarmente pericolosi. Gli attaccanti possono caricare web shell (mascherate da immagini), documenti dannosi (macro) o file di dimensioni eccessive (DoS). La convalida deve includere: la verifica del tipo di file in base al contenuto (magic byte), non solo all'estensione; l'imposizione di una dimensione massima del file; la memorizzazione dei caricamenti al di fuori della root web; la ridenominazione dei file sul server per impedire percorsi prevedibili; la scansione con antivirus/sandbox; e il divieto di eseguire direttamente i file caricati.

# File upload validation steps:
# 1. Check Content-Type header (client-provided, not trusted alone)
# 2. Read first bytes (magic bytes):
#    JPEG: FF D8 FF | PNG: 89 50 4E 47 | PDF: 25 50 44 46
# 3. Reject if magic bytes don't match expected type
# 4. Enforce max size: reject > 10MB
# 5. Strip original filename, assign random UUID filename
# 6. Store in /var/uploads/ (NOT /var/www/html/)
# 7. Serve via CDN or application route (not direct URL)

Convalida degli input nelle API

Le applicazioni moderne utilizzano ampiamente REST API e GraphQL e richiedono quindi la convalida dei corpi delle richieste JSON/XML. I framework di convalida delle API, come JSON Schema, definiscono i campi obbligatori, i tipi di dati, i pattern delle stringhe e gli intervalli di valori. La limitazione della profondità GraphQL impedisce che query profondamente annidate provochino un DoS. La limitazione della frequenza delle richieste previene gli abusi automatizzati anche quando i singoli input sono validi. La convalida dello schema deve avvenire prima che la logica di business elabori la richiesta.

# JSON Schema validation example:
# POST /api/register body schema:
# {
#   'type': 'object',
#   'required': ['username', 'email', 'password'],
#   'properties': {
#     'username': {'type': 'string', 'pattern': '^[a-zA-Z0-9_]{3,20}$'},
#     'email':    {'type': 'string', 'format': 'email', 'maxLength': 254},
#     'password': {'type': 'string', 'minLength': 12, 'maxLength': 128}
#   },
#   'additionalProperties': false
# }

Messaggi di errore e divulgazione di informazioni

I messaggi di errore restituiti agli utenti possono esporre inavvertitamente informazioni sensibili utili agli attaccanti. I messaggi di errore del database possono rivelare nomi di tabelle, tipi di colonna o sintassi SQL. Le tracce dello stack espongono le versioni del framework applicativo e i percorsi dei file. Gli errori dettagliati di convalida degli input possono confermare all'attaccante quali caratteri vengono rifiutati, aiutandolo a elaborare tentativi di aggiramento. Buona pratica: restituire ai client messaggi di errore generici e intuitivi (ad esempio, 'Input non valido'), registrando al contempo lato server le informazioni dettagliate sull'errore per il debugging degli sviluppatori. Non esporre mai agli utenti finali i messaggi grezzi delle eccezioni.

# UNSAFE: returning detailed database error to user
# Error: 'You have an error in your SQL syntax near ... at line 1'
# Reveals: database type (MySQL), partial query structure

# UNSAFE: stack trace in API response
# Error: 'java.sql.SQLException at com.company.UserDAO.findByName:47'
# Reveals: framework (Java), class names, line numbers

# SAFE: generic error response to client
# HTTP 400 Bad Request: { 'error': 'Invalid request parameters' }
# Server log (internal only): full exception with stack trace
# Monitoring: alert on high error rates -> investigate internally

Verifica rapida

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

Riepilogo della lezione

In questa lezione ha imparato che: la convalida degli input lato server tramite allowlist garantisce che vengano elaborati solo i dati previsti; le query parametrizzate prevengono la SQL injection separando i dati dalla struttura della query; infine, la codifica degli output consapevole del contesto previene l'XSS e altri attacchi di injection neutralizzando i caratteri speciali prima che entrino nei contesti HTML, JavaScript, URL o shell. Prossimamente esamineremo la gestione sicura dei secret e l'injection delle variabili d'ambiente.

Domande Frequenti

La lezione «Convalida degli input e codifica degli output» è gratuita?

Sì — il testo completo di «Convalida degli input e codifica degli output» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cloud & IT Cert Prep, passa a CoddyKit PRO. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.

Cosa imparerò in «Convalida degli input e codifica degli output»?

Implementi la convalida degli input lato server e la codifica degli output sensibile al contesto per neutralizzare le vulnerabilità di injection e XSS prima che possano essere sfruttate. Eserciti Cloud & IT Cert Prep con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Cloud & IT Cert Prep?

Non è richiesta alcuna esperienza precedente. Cloud & IT Cert Prep su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Convalida degli input e codifica degli output»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Cloud & IT Cert Prep?

Sì. Ogni lezione Cloud & IT Cert Prep include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

Convalida degli input e codifica degli output
Gestione sicura dei segreti e variabili d'ambiente
Sicurezza delle dipendenze e analisi della composizione del software
DevSecOps: spostare la sicurezza a sinistra nelle pipeline

← Torna a Cloud & IT Cert Prep