L’esame OffSec Web Expert (OSWE) è noto per la sua metodologia white-box. Non si “scansiona” semplicemente una webapp per trovare vulnerabilità potenziali, si legge il codice, si comprende e si trovano i difetti per forgiare l’exploit perfetto. Niente di irraggiungibile con la giusta preparazione tecnica ed esperienza.

AWAE/OSWE/WEB-300

Chiariamo prima di cosa stiamo parlando. L’OSWE (Offensive Security Web Expert) è la certificazione, mentre AWAE (Advanced Web Attacks and Exploitation, noto anche come WEB-300) è il corso che ti prepara per l’esame.

  • AWAE Advanced Web Attacks and Exploitation: Questo corso è il cuore della preparazione. Ti insegna a identificare vulnerabilità complesse in applicazioni web eseguendo analisi white-box, ovvero analizzando il codice sorgente. L’obiettivo non è solo trovare il bug, ma anche sviluppare exploit affidabili e riutilizzabili.

  • OSWE OffSec Web Expert: È la certificazione di OffSec ottenuta superando l’esame proctored di 48 ore (+24h di report) che testa la tua abilità nella ricerca e exploiting di vulnerabilità web, tramite l’analisi del codice sorgente e l’analisi dinamica dell’app. È la prova che sei in grado di andare oltre il testing superficiale.

L’esame

Qualche nota sulla mia esperienza durante le 48 ore d’esame.

Gestione del tempo

Ho iniziato la mattina al mio solito orario, senza stravolgere i ritmi. Ho attaccato subito il primo target partendo dall’analisi statica del codice sorgente: raccogliere info, mappare i path più a rischio, individuare le funzioni critiche. In parallelo, analisi dinamica con debugger attaccato per capire dove e come venivano triggerate le funzioni sospette, e Burp per osservare le richieste.

Mentre analizzavo, tenevo un file di testo con le chiamate utili per l’exploit e facevo screenshot di tutto: pezzi di codice vulnerabili, richieste Burp, schermate dell’applicazione, flag. A metà giornata avevo già un path definito per exploitare completamente il primo target. Dopo pranzo ho iniziato a scrivere il codice dell’exploit e a testarlo. Verso sera avevo una PoC funzionante e le flag inserite nel portale OffSec. L’unico step manuale era l’nc -lnvp per il listener, che comunque è permesso come specificato nella exam guide.

Il secondo giorno, sveglia allo stesso orario, colazione, doccia e si riparte. Con il processo ormai rodato dal day 1, il secondo target è filato più liscio. Per questo exploit ho integrato anche il listener netcat nello script, così la PoC era 100% autoconsistente.

Cheat-sheet e risorse durante l’esame

L’uso di chatbot e AI è vietato durante l’esame. Questo si sente, soprattutto se, come me, ormai sei abituato ad averli a disposizione quando scrivi codice. Bisogna fare uno step back: tornare a leggere documentazione, googlare, scrivere il codice a mano. Ma essendo gli exploit degli script non troppo complessi, alla fine nulla di impossibile.

Le due risorse che ho consultato di più durante l’esame:

  • Il PDF ufficiale del corso AWAE (WEB-300) di OffSec, per le cose che non ricordavo a memoria: come settare il debugging remoto, come decompilare e cercare rapidamente nei decompilatori tipo JD-GUI.
  • Il repo exploit-writing-for-oswe di rizemon, preziosissimo per gli snippet di codice Python.

Il report

Contestualmente alla scoperta di qualcosa di interessante, incollavo appunti, screenshot ed evidenze direttamente nel template Word fornito da OffSec. Non aspettate la fine dell’esame per iniziare il report: documentare in tempo reale vi farà risparmiare ore e vi eviterà di dimenticare dettagli importanti.

Cosa farei diversamente

Se dovessi rifarlo, dedicherei qualche sessione di pratica a scrivere exploit senza AI prima dell’esame. Quando ti abitui ad avere un copilot che ti autocompleta il codice, tornare a scrivere tutto a mano sotto pressione è un piccolo shock. Anche solo risolvere qualche lab di PortSwigger scrivendo le PoC in Python senza assistenza è un buon esercizio per riacquistare il ritmo.

Preparazione

Se ne avete la possibilità, comprate il corso ufficiale AWAE (WEB-300) di OffSec e seguite la loro metodologia. Se, come me, avete avuto accesso limitato, ad esempio, solo 3 mesi di lab (tra l’altro startato ad inizio agosto poco prima di andare in ferie), le guide, i lab e le risorse elencate di seguito vi saranno utili per preparare al meglio l’esame, anche senza il percorso ufficiale completo.

Di seguito trovate, per ogni classe di vulnerabilità rilevante per l’OSWE, il link ai lab di PortSwigger per fare pratica e una selezione di case study e risorse che ho trovato utili durante la preparazione.

VulnerabilitàLabCase Studies & Risorse
SQL InjectionPortSwiggerRCE with SQLi - MSSQL, Pre-Auth Takeover of OXID eShops, SQLi to LFI to RCE - MySQL, From SQLi to SHELL (I and II) - PentesterLab, Having Fun With PostgreSQL, Blind PostgreSQL SQLi Tutorial, SQLi Cheat Sheet - PentestMonkey, SQLi Cheat Sheet - PayloadAllTheThings, Exploiting H2 SQLi to RCE
Insecure DeserializationPortSwiggerSerialization - A Hidden Threat, Deserialization Vulnerability [Paper], Analyse Binary Serialization Stream, Friday the 13th: JSON Attacks - Black Hat 2017, Exploiting Node.js Deserialization to RCE, YAML Deserialization Attack in Python
SSTIPortSwiggerServer Side Template Injection - Portswigger Research, SSTI: RCE For The Modern Web App [Video], Server Side Template Injection, Jinja2 Template Injection Filter Bypasses
XXEPortSwiggerA Deep Dive into XXE Injection, From XXE to RCE: Pwn2Win CTF 2018, Blind XXE to RCE, Apache Flex BlazeDS XXE, WebLogic EJBTaglibDescriptor XXE
XSSPortSwiggerAtMail 6.4 - Persistent XSS, Chaining XSS, CSRF to RCE, Code Analysis to Gaining RCE, Magento 2.3.1: Unauth Stored XSS to RCE, MyBB 18.20 From Stored XSS to RCE
Arbitrary File UploadPortSwiggerFile Upload Restrictions Bypass [Paper], Shell the Web - Methods of a Ninja, Popcorn - HackTheBox, Vault - HackTheBox
SSRFPortSwiggerSSRF Vulnerability in Directus, Escalating SSRF to RCE on AWS, A New Era of SSRF - Black Hat 2017

Consiglio di approfondire anche Prototype Pollution, CSRF, OS Command Injection e Path Traversal tramite i lab di PortSwigger: sono classi di vulnerabilità che possono presentarsi durante l’esame o nel lavoro quotidiano.

Fai una Pausa

Quando sei esausto, puoi sempre spegnere il pc, buttarti sul divano e leggere o guardare video dallo smartphone (meglio un tablet per i video di IppSec se non vuoi perdere la vista):

Cheat-Sheet

L’esame OSWE è proctored e l’uso di AI o chatbot è vietato. Quindi, a meno che non scrivi codice quotidianamente, potrebbe risultarti difficile scrivere gli exploit da zero, sotto pressione, senza aiuti esterni. Anche finire su Stack Overflow per scoprire come si printa un “Hello, World!” in Python è abbastanza frustrante.

Consiglio: prepara i tuoi cheat-sheet con gli snippet di codice, o trovane di già pronti tipo questo: OSWE cheatsheet from rizemon

Conclusione

Onestamente, gli esami di OffSec li ho sempre trovati un po’ stressanti. La modalità proctored e il tempo limitato mettono oggettivamente ansia, ma devo dire che, rispetto all’OSCP, affrontare temi web con l’OSWE su cui ero più preparato e trattandosi del mio secondo esame con loro, mi ha permesso di essere più rilassato.

L’OSWE non è solo un esame tecnico, è una prova di resistenza, metodologia e abilità nel problem-solving white-box. Richiede disciplina nel leggere il codice e creatività nel trasformare i singoli bug in exploit funzionale. In generale comunque, consiglio a tutti il corso WEB-300 (AWAE). Per me è ben fatto, ricco di risorse, ma soprattutto ti dà accesso ai lab dove puoi esercitarti su chain di vulnerabilità reali e pratiche. Poi mi è capitato più volte di chiedere e ricevere supporto sul canale Discord di OffSec e l’ho trovato funzionale, ben gestito e utilissimo, specialmente quando ti serve qualche hint per andare avanti durante il corso.

In ogni caso, se hai bisogno di approfondire alcuni temi prima dell’esame, spero che questo post sia d’aiuto.