Sfide web e di crittografia

Web e crypto sono i due punti di ingresso più comuni nei CTF.

• Le challenge Web presentano un'applicazione web in esecuzione e chiedono di trovare un difetto nel modo in cui gestisce input, autenticazione o rapporti di fiducia.
• Le challenge Crypto forniscono testo cifrato, uno schema e talvolta il codice sorgente, chiedendo di recuperare il testo in chiaro o una chiave sfruttando un difetto nel modo in cui è stata usata la crittografia.

Entrambe premiano un'osservazione metodica. Questa lezione tratta gli schemi ricorrenti di ciascuna categoria.

Prima di sfruttare qualsiasi cosa, mappi l'applicazione. Visualizzi il codice sorgente, analizzi le risposte ed esplori i contenuti nascosti.

La SQL injection si verifica quando l'input dell'utente viene concatenato a una query del database senza separare codice e dati.

Un login che costruisce una query come SELECT * FROM users WHERE name='INPUT' può essere manipolato tramite un input che chiude la stringa e modifica la logica:

Il CTF insegna a sfruttare l'injection per imparare a difendersi. La difesa corretta consiste nelle query parametrizzate (prepared statements), che mantengono i dati dell'utente completamente separati dalla struttura della query.

La XSS si verifica quando un'applicazione riflette o memorizza input controllato dall'attaccante e un browser lo esegue come script. In un CTF, una challenge XSS spesso coinvolge un bot che visita il suo payload mentre conserva la flag in un cookie.

• Riflesso — il payload nella richiesta viene restituito direttamente.
• Memorizzato — il payload viene salvato ed eseguito per i visitatori successivi.
• Basato sul DOM — il JavaScript lato client inserisce l'input nella pagina in modo non sicuro.

La difesa consiste nella codifica dell'output in base al contesto, insieme a una Content-Security-Policy. Un test come <script>alert(1)</script> conferma se l'input viene sottoposto a escaping.

Altri due capisaldi del web:

• Server-Side Request Forgery (SSRF) — induce il server a effettuare richieste per suo conto, spesso verso indirizzi accessibili solo internamente come http://127.0.0.1 o verso un endpoint di metadati cloud, per raggiungere la flag.
• Path traversal — evade dalla directory prevista usando sequenze come ../ per leggere file al di fuori della web root, ad esempio ../../../../etc/passwd.

Entrambi i problemi derivano dalla fiducia nell'input dell'utente per la scelta di una risorsa. Le difese consistono in allowlist rigorose e nella canonicalizzazione e convalida dei percorsi prima del loro utilizzo.

Il tranello crittografico più comune per chi inizia è confondere la codifica con la crittografia. La codifica è reversibile da chiunque senza una chiave, quindi non offre alcuna riservatezza.

Impari a riconoscere a colpo d'occhio i formati:

• Base64 — lettere, cifre, + /, spesso con il padding =.
• Hex — solo 0-9 a-f.
• ROT13 / Caesar — struttura leggibile, lettere spostate.

Molte challenge di crittografia usano cifrari storici deboli o versioni moderne implementate con superficialità:

• Caesar / Vigenere — cifrari a sostituzione che si rompono con l'analisi delle frequenze o provando tutti i 25 spostamenti.
• Single-byte XOR — l'intero messaggio viene sottoposto a XOR con un solo byte; provi tutte le 256 chiavi e scelga l'output leggibile.
• Repeating-key XOR — si rompe trovando la lunghezza della chiave e risolvendo quindi ogni byte della chiave come un XOR a byte singolo.

La lezione è questa: un cifrario personalizzato o classico non offre alcuna sicurezza reale contro un analista.

RSA è sicuro solo quando i suoi parametri sono scelti correttamente. Le challenge di crittografia dei CTF amano fornire configurazioni vulnerabili:

• Modulo piccolo — se n è abbastanza piccolo, lo fattorizzi direttamente per recuperare la chiave privata.
• Esponente piccolo, nessun padding — con e=3 e un messaggio breve, il testo cifrato può essere un cubo perfetto, recuperabile estraendo la radice cubica intera.
• Fattori condivisi — se due chiavi pubbliche condividono un primo, il massimo comune divisore dei loro moduli lo rivela immediatamente.

La difesa nel mondo reale consiste nell'usare una libreria verificata con chiavi grandi e padding corretto (OAEP): non implementi mai autonomamente la crittografia.

Quando una challenge Le fornisce l'hash di una password, l'obiettivo è recuperare l'input originale. Non è possibile invertire un hash, ma si possono provare diversi input e confrontare i risultati.

Riunisca tutto in un ciclo coerente per entrambe le categorie:

• Osservare — leggere il prompt, visualizzare il codice sorgente, identificare la codifica o lo schema.
• Formulare un'ipotesi — individuare la probabile famiglia di vulnerabilità.
• Testare su piccola scala — inviare un payload di prova e osservare la risposta esatta.
• Sfruttare — trasformare il probe funzionante in un payload completo che restituisca la flag.
• Documentare — annotare il payload e il ragionamento finché sono ancora freschi.

Questo ciclo evita di perdersi in vicoli ciechi e permette di produrre quasi senza sforzo un writeup.

Verifichi la Sua comprensione dei fondamenti del web e della crittografia.

Ha esaminato i problemi ricorrenti di web e crittografia:

• Web: mappare prima, poi sondare la presenza di SQL injection, XSS, SSRF e path traversal — ciascuno nasce da una gestione non sicura dell'input dell'utente e si risolve separando il codice dai dati.
• Crittografia: distinguere codifica e cifratura, spezzare i cifrari classici e XOR deboli, sfruttare gli errori nei parametri RSA e fare il cracking degli hash con le wordlist.
• Un unico ciclo di osservazione, formulazione di ipotesi, test, sfruttamento e documentazione funziona per entrambe.

Ora passerà al reverse engineering e al binary exploitation.