Skip to content

Rapporto di esempio · Scenari fittizi

Cosa potrebbe raggiungere un aggressore e come impedirlo

Queste ricostruzioni fittizie si ispirano a tipi di problemi reali. Domini, account, risposte e cronologie dei test sono inventati. Non sono risultati di clienti né prove che EverBreach abbia svolto questi test.

Dove intervenire

Nel portale, un normale account candidato può leggere i dati e il CV di un’altra persona. Nel negozio, un visitatore può recuperare un’immagine a piena risoluzione senza pagare. Entrambi i difetti sono lato server. Nascondere un pulsante lascerebbe aperto l’accesso.

  1. Alta · Limitare subito l’accesso

    Un account candidato può leggere le candidature altrui

    Team responsabile: Team applicativo e responsabile del sistema di selezione

    Limitare gli elenchi e i download dei CV mentre vengono corretti i controlli dei permessi.

  2. Alta · Bloccare l’accesso senza acquisto

    Le foto originali sono accessibili prima del pagamento

    Team responsabile: Team e-commerce e responsabile storage/CDN

    Rendere privati gli originali e smettere di fornire link utilizzabili ai visitatori che non hanno pagato.

Cosa copre questo esempio

Due ambienti distinti: un portale di selezione del personale e un negozio di fotografie. I test usano candidature predisposte, CV fittizi, immagini di prova e account con ruoli concordati. Non vengono consultati dati di candidati reali o contenuti a pagamento.

Alta · Limitare subito l’accesso

1. Un account candidato può leggere le candidature altrui

Team responsabile
Team applicativo e responsabile del sistema di selezione
Intervento immediato
Limitare gli elenchi e i download dei CV mentre vengono corretti i controlli dei permessi.

Conseguenze per l’organizzazione

Nomi, recapiti e CV possono rivelare il percorso professionale e altre informazioni personali. Un aggressore potrebbe usarli per frodi mirate o pubblicarli. Se lo stesso controllo manca per l’intero elenco, tutte le nuove candidature potrebbero essere coinvolte. Il test limitato qui sotto non dimostra tale estensione.

Cosa è stato dimostrato

L’account A ha ricevuto le candidature di prova A e B e scaricato il CV fittizio di B. Senza sessione, la risposta era 401. Manca il controllo su ciò che un utente autenticato può consultare; il login non è stato aggirato. Il test si è fermato dopo i due record concordati.

Come potrebbe agire un aggressore

  1. Creare o usare un normale account candidato, senza permessi da selezionatore.
  2. Richiedere l’elenco usato dal portale. Il server restituisce anche una candidatura altrui.
  3. Usare l’identificativo ricevuto per richiedere il relativo CV. Ripetere il passaggio potrebbe ampliare l’esposizione. Non è stata effettuata una raccolta massiva.

Perché il problema è emerso in questo test

Motivo del test nell’esempio: una nuova versione applicativa. Con gli stessi account e dati, l’elenco rispondeva 403 in r41 e 200 in r42. In questa ricostruzione, il confronto del codice rivela una nuova route priva del controllo sul ruolo. Modello e configurazione del test restano uguali; la chiave è la modifica dell’applicazione.

Prove e correzioni

Ambiente di esempio: careers.example.com · versione r42

Richiesta e risposta illustrative

GET /api/applications?status=new
Session: applicant_test_A (no recruiter role)
HTTP 200
[{id:"test-A", email:"a@example.com"},
 {id:"test-B", email:"b@example.com"}]

GET /api/applications/test-B/cv
Session: applicant_test_A
HTTP 200 · application/pdf (synthetic CV)

Control: no session -> HTTP 401

Perché l’accesso era possibile

La route dell’elenco verifica solo che la sessione sia valida. Non richiede il ruolo di selezionatore e non limita i record al proprietario. Anche la route dei CV omette il controllo per singolo oggetto. Identificativi difficili da indovinare non risolverebbero il problema: l’elenco li rivela già.

Correggere la causa

  1. Negare temporaneamente ai candidati l’accesso alle route di elenco e documenti. Conservare i log pertinenti e stabilire da quando la versione interessata era raggiungibile.
  2. Consentire gli elenchi completi solo al personale autorizzato, lato server. I candidati possono leggere soltanto i propri dati consentiti. Applicare la stessa regola ai CV e all’accesso diretto allo storage.
  3. Aggiungere test con A, B, un selezionatore autorizzato e nessuna sessione. Coprire elenchi, dettagli, esportazioni e allegati; negare l’accesso per impostazione predefinita.
  4. Esaminare i log per accessi non autorizzati e coinvolgere i responsabili di incidenti e privacy per valutare un’esposizione reale. Non copiare dati personali nei normali ticket.

Criteri di accettazione per il nuovo test

A può usare le funzioni previste sui propri dati, ma riceve 403 o 404 senza contenuti per il record e il CV di B. L’elenco respinge gli account candidati. Il personale autorizzato mantiene l’accesso previsto; le richieste anonime e gli accessi diretti ai file falliscono. Conservare questi casi nei test di regressione.

Dimostrato nell’esempio: accesso a due candidature di prova e a un CV fittizio altrui. Non accertato: accesso a tutti i candidati, abusi precedenti o esposizione di un database di produzione.

OWASP · Autorizzazione a livello di oggetto

Alta · Bloccare l’accesso senza acquisto

2. Le foto originali sono accessibili prima del pagamento

Team responsabile
Team e-commerce e responsabile storage/CDN
Intervento immediato
Rendere privati gli originali e smettere di fornire link utilizzabili ai visitatori che non hanno pagato.

Conseguenze per l’organizzazione

Il negozio consegna il prodotto prima di concludere la vendita. I visitatori potrebbero salvare o ridistribuire l’originale senza acquistarlo. Se altre voci del catalogo usano le stesse risposte e regole di storage, molte immagini potrebbero essere interessate. L’esempio dimostra un’immagine di test concordata, non il download del catalogo.

Cosa è stato dimostrato

Un account di prova senza acquisti ha ricevuto l’URL dell’originale nella risposta della foto. Una richiesta separata senza sessione ha recuperato l’immagine di test a piena risoluzione. L’ordine è rimasto non pagato e non è stato effettuato alcun pagamento.

Come potrebbe agire un aggressore

  1. Aprire la pagina di acquisto di una foto senza averla comprata.
  2. Leggere i dettagli inviati al browser prima del pagamento. Contengono l’indirizzo dell’originale, anche se la pagina mostra solo l’anteprima.
  3. Richiedere direttamente l’indirizzo. Il server dei file restituisce l’originale senza controllare l’acquisto. Servono verifiche su altre immagini prima di affermare che tutto il catalogo sia accessibile.

Perché il problema è emerso in questo test

Motivo del test nell’esempio: una nuova verifica dopo un aggiornamento del modello. Versione r17, account, dati, strumenti, istruzioni e budget restano invariati. Il secondo tentativo segue il link dall’anteprima all’originale; il precedente non aveva segnalato il difetto. La vulnerabilità esisteva già. Due soli tentativi non dimostrano che il nuovo modello abbia causato il miglioramento; servirebbero prove comparabili ripetute.

Prove e correzioni

Ambiente di esempio: studio.example.com + media.example.com · versione r17

Richiesta e risposta illustrative

GET /api/photos/test-photo-01
Session: buyer_test_A · purchases: []
HTTP 200
{"previewUrl":"/previews/test-photo-01.jpg",
 "originalUrl":"https://media.example.com/originals/test-photo-01.jpg"}

GET originalUrl · no session
HTTP 200 · image/jpeg · full resolution
Order state: unpaid · no payment submitted

Perché l’accesso era possibile

L’interfaccia nasconde il pulsante di download fino al pagamento, ma l’API espone prima l’URL e il server dei file lo rende pubblico. Mancano due controlli: il diritto legato all’acquisto nell’applicazione e l’accesso privato all’origine dei file.

Correggere la causa

  1. Bloccare l’accesso pubblico agli originali nello storage e nel CDN. Invalidare le copie pubbliche in cache e i link già esposti, dove applicabile. Mantenere disponibili le anteprime.
  2. Fornire anteprime prima dell’acquisto. Prima dell’accesso a un originale, confermare il pagamento lato server con il fornitore e verificare il diritto dell’acquirente su quella specifica immagine. Non fidarsi di una pagina di successo o di uno stato inviato dal browser.
  3. Servire gli originali tramite una route con controllo dei permessi oppure emettere solo dopo la verifica URL firmati, di breve durata e limitati al file. Chi possiede il link può usarlo fino alla scadenza: non esporlo prima del pagamento.
  4. Testare pagamenti assenti, in attesa, falliti e annullati, un acquisto valido e l’accesso a un’altra immagine. Verificare che il server dei file non aggiri la decisione applicativa.

Criteri di accettazione per il nuovo test

Senza acquisto, la risposta contiene solo l’anteprima e nessun link utilizzabile all’originale. L’accesso diretto fallisce. Pagamenti in attesa, falliti e annullati non concedono accesso. Un acquirente verificato può scaricare solo l’immagine acquistata. I link scaduti falliscono e le anteprime pubbliche restano disponibili.

Dimostrato nell’esempio: un originale di test recuperato senza pagamento. Non accertato: accesso a tutte le immagini, vendite perse o vantaggio di rilevamento specifico di un modello.

OWASP · Autorizzazione delle transazioni

Trasformare i risultati in attività assegnate

Esempio per un team interno o un fornitore esterno. Usa solo i punti pertinenti al tuo sistema e allega il rapporto reale.

Buongiorno, Vi chiediamo di esaminare i risultati allegati e assegnare un responsabile a ogni problema pertinente. CANDIDATURE: riservare gli elenchi al personale autorizzato e controllare i permessi su ogni candidatura e download di CV. Conservare i log utili ed esaminare il possibile periodo di esposizione. NEGOZIO FOTO: mantenere privati gli originali. Consentire il download solo dopo la conferma del pagamento lato server e la verifica del diritto su quella specifica immagine. Controllare storage e CDN. Prima di procedere, confermate contenimento, correzione definitiva, costo e data prevista. Inserite i casi di accesso consentito e negato del rapporto nei test di regressione, poi concordate una nuova verifica. Grazie.

Cosa non dimostra questo rapporto

Gli scenari mostrano la profondità di un’analisi applicativa, non la copertura dello scanner esterno attuale. Un incarico reale deve concordare separatamente accessi, account di prova, azioni consentite e condizioni di arresto. Gli esempi dimostrano accessi limitati a dati di test. Non provano un’intrusione reale, l’esposizione totale o il tasso di successo generale di un modello di IA.

Vedi cosa comprende l’analisiRichiedi un’analisi pilota