CompTIA SY0-701: Sicurezza delle Applicazioni e del Web — Guida allo studio
Fa parte della CompTIA Security+ SY0-701 — Guida allo studio. Esercitati con risposte verificate nel centro esami CompTIA, oppure fai test cronometrati su ExamRoll.io.
Le applicazioni moderne si trovano all’intersezione tra logica di business, dati sensibili e input utente non attendibile. Poiché i front-end web e mobile sono esposti a tutta Internet, rappresentano una delle superfici di attacco più grandi e costantemente sfruttate in qualsiasi azienda. Difenderli richiede controlli stratificati che partono dal modo in cui il codice viene scritto e si estendono alle protezioni a runtime, alla verifica dell’integrità e ai test continui.
Attacchi di tipo Injection
L’injection rimane la vulnerabilità web per antonomasia. Si verifica ogni volta che un’applicazione concatena input non attendibile in un interprete — una query SQL, un comando di shell, un filtro LDAP, un parser XML o un motore di template — senza separare correttamente il codice dai dati. In una SQL injection (SQLi), un attaccante manipola una query in modo che il database esegua una logica controllata dall’attaccante. Un classico pattern vulnerabile in PHP si presenta così:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
Inviando admin' OR '1'='1 si trasforma la query in una tautologia che restituisce ogni riga. Varianti più avanzate includono l’estrazione basata su UNION (' UNION SELECT credit_card FROM payments--), l’inferenza booleana o basata sul tempo di tipo blind (' AND SLEEP(5)--) e l’esfiltrazione out-of-band tramite callback DNS. La soluzione definitiva consiste nell’uso di query parametrizzate o prepared statement, che inviano il template della query e i suoi parametri al database come strutture separate:
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
La command injection segue lo stesso schema ma prende di mira la shell del sistema operativo. Codice come os.system("ping " + host) permette a un attaccante di inviare 8.8.8.8; cat /etc/passwd ed eseguire comandi arbitrari. La remediation richiede di evitare del tutto l’invocazione della shell, utilizzando API che accettano array di argomenti (subprocess.run(["ping", host], shell=False)) e applicando una validazione restrittiva tramite allow-list a qualsiasi valore che debba raggiungere una shell.
Cross-Site Scripting e CSRF
Il cross-site scripting (XSS) è l’iniezione di script dannosi in pagine renderizzate da un’applicazione attendibile, portando il browser della vittima a eseguire codice dell’attaccante all’interno dell’origin del sito. L’XSS riflesso (Reflected XSS) fa “rimbalzare” i payload su un parametro vulnerabile; l’XSS memorizzato (Stored XSS) rende persistente il payload nel database e lo distribuisce a ogni visitatore; l’XSS basato su DOM (DOM-based XSS) si verifica interamente nel JavaScript lato client che scrive dati non attendibili in innerHTML, document.write o sink simili. Le conseguenze vanno dal dirottamento della sessione (session hijacking) e keylogging fino alla completa acquisizione dell’account (account takeover) tramite azioni forzate.
La cross-site request forgery (CSRF) è un attacco distinto ma complementare. Sfrutta l’inclusione automatica dei cookie da parte del browser per indurre un utente autenticato a inviare una richiesta indesiderata — ad esempio, un modulo nascosto su un sito dannoso che effettua una richiesta POST a bank.com/transfer. Le difese includono i synchronizer token (valori casuali per sessione incorporati nei moduli e verificati lato server), l’attributo SameSite=Lax o SameSite=Strict per i cookie e la richiesta di una nuova autenticazione per le azioni sensibili. XSS e CSRF vengono spesso confusi, ma l’XSS esegue codice nel browser della vittima, mentre il CSRF fa semplicemente sì che il browser emetta una richiesta; è importante notare che un attacco XSS riuscito può vanificare la maggior parte delle difese CSRF.
Scrittura di Codice Sicuro: Validazione dell’Input vs. Codifica dell’Output
Due controlli vengono spesso confusi, eppure risolvono problemi diversi. La validazione dell’input (input validation) assicura che i dati siano conformi alla struttura prevista — lunghezza, tipo, set di caratteri, intervallo, formato — prima che l’applicazione agisca su di essi. Dovrebbe avvenire sul server, utilizzando allow-list (liste di permessi) ove possibile (^[A-Za-z0-9_]{3,20}$ per un nome utente). La validazione lato client tramite JavaScript è solo una funzionalità di usabilità; può essere aggirata con qualsiasi proxy HTTP e non deve mai costituire il perimetro di sicurezza.
La codifica dell’output (output encoding) garantisce che i dati vengano renderizzati in modo sicuro in qualsiasi contesto in cui confluiscono. La stessa stringa, che è un input perfettamente valido, potrebbe richiedere un trattamento diverso a seconda di dove viene inserita: il contesto del corpo HTML richiede la codifica delle entità HTML (< → <), il contesto di un attributo richiede una codifica specifica per gli attributi tra virgolette, il contesto JavaScript richiede l’escape \xHH e gli URL richiedono il percent-encoding. Un nome utente come O'Brien è un input legittimo, ma deve essere codificato come O'Brien quando inserito in HTML. La validazione dell’input non può sostituire la codifica dell’output, e la codifica non può sostituire la validazione — affrontano problemi diversi in punti diversi del ciclo di vita dei dati.
Ulteriori misure di rafforzamento (hardening) includono gli header Content Security Policy (CSP) per limitare le fonti degli script, i flag HttpOnly e Secure sui cookie di sessione e l’uso di API parametrizzate a ogni confine di fiducia (trust boundary).
WAF e Protezioni per l’Upload di File
Un web application firewall (WAF) ispeziona il traffico HTTP e blocca le richieste che corrispondono a pattern dannosi noti — firme di SQLi, payload XSS, sequenze di path traversal, anomalie di protocollo. Implementato come reverse proxy (ModSecurity con l’OWASP Core Rule Set, AWS WAF, Cloudflare, F5), fornisce un prezioso virtual patching quando una vulnerabilità viene scoperta prima che il codice possa essere corretto. Tuttavia, un WAF è un controllo di compensazione, non un sostituto della scrittura di codice sicuro. Gli attaccanti sofisticati bypassano regolarmente i WAF attraverso tecniche di codifica, HTTP parameter pollution e frammentazione del payload.
L’upload di file merita un’attenzione speciale perché combina contenuto non attendibile con l’archiviazione lato server e, spesso, con l’esecuzione. Le protezioni includono la convalida del tipo di file ispezionando i magic byte anziché fidarsi dell’estensione o dell’header Content-Type, l’archiviazione degli upload al di fuori della web root, la ridenominazione dei file con identificatori generati dal server (per prevenire attacchi di directory traversal tramite nomi di file creati ad arte), l’esecuzione di una scansione antivirus prima dell’archiviazione e il servire i contenuti caricati dagli utenti da un dominio separato per impedire l’esecuzione di script in base alla same-origin policy.
Scenario pratico: SQL Injection che porta alla compromissione completa del database
L’endpoint di ricerca prodotti di un’azienda di vendita al dettaglio accettava un parametro category che veniva concatenato direttamente in una query SQL senza alcuna sanitizzazione. Un ricercatore di sicurezza ha scoperto che inviando la stringa ' UNION SELECT table_name,null,null FROM information_schema.tables-- si otteneva in risposta un elenco di tutte le tabelle del database. Richieste successive hanno permesso di estrarre la tabella customers, ottenendo 1,2 milioni di record che includevano nomi, indirizzi email e password con hash bcrypt. L’aggressore ha anche scoperto una stored procedure che poteva essere invocata tramite SQL injection per scrivere file nella web root, consentendo l’installazione di una webshell e la compromissione completa del server. La vulnerabilità era presente da tre anni e non era stata rilevata in due precedenti penetration test perché i tester avevano verificato solo il modulo di login, e non l’endpoint di ricerca. La lezione: i test di injection devono coprire ogni parametro in ogni endpoint, non solo i percorsi di autenticazione più ovvi.
← Risposta agli Incidenti · Tutti i domini · Sicurezza di Cloud →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →