Perché gli scanner di solito non rilevano XSS memorizzati? C'è un modo per automatizzare il rilevamento di xss archiviati (persistenti)? [chiuso]

3

Sto cercando disperatamente strumenti, preferibilmente con qualche guida, anche preferibilmente open-source, per rilevare le vulnerabilità xss memorizzate. Si osserva che una manciata di questi non fornisce i risultati attesi con l'XSS memorizzato.

Ho provato con ZAP Proxy e xsser , ma ho trovato solo la documentazione su XSS riflessa per quegli strumenti.

Per XSS memorizzato la pagina "iniettata" potrebbe essere diversa dalla pagina vulnerabile.

Sto analizzando gli strumenti su una semplice applicazione vulnerabile che trovi qui: link

Lo sfruttamento manuale ha richiesto alcuni secondi, ma finora non sono stato in grado di utilizzare strumenti automatici, anche in modalità "guidata", in cui ho specificato l'URL del modulo e lasciato che lo strumento trovi pagine vulnerabili.

Sospetto che entrambi gli strumenti citati siano in grado di farlo, ma è troppo banale o troppo complicato per essere mostrato in esempi / post sul blog. Sarei davvero grato se qualcuno potesse mostrare tale caso d'uso.

    
posta user2245644 18.10.2016 - 15:35
fonte

1 risposta

2

Ecco alcuni problemi con quello che stai cercando e perché sono praticamente inesistenti.

  1. Gli strumenti trovano XSS riflesso cercando lo snippet di script immesso nell'origine HTML della risposta immediata alla richiesta che ha iniettato lo script.
  2. Gli stessi strumenti rileveranno anche l'XSS memorizzato se lo script si riflette nella risposta immediata.
  3. Ma a volte la risposta immediata potrebbe non riflettere lo script anche se è vulnerabile all'XSS. Ad esempio, un utente invia un modulo interno a un utente con privilegi elevati che non sarà immediatamente visibile a lui / lei. In questo caso, se il modulo è vulnerabile a XSS persistente, verrà eseguito nel browser dell'utente con privilegi elevati.
  4. L'XSS persistente si verifica principalmente su richiesta POST. La richiesta di scansione di solito porta all'esaurimento del database.

Che cosa puoi fare per automatizzare:

A questo punto non sono a conoscenza di alcuno strumento che possa essere utilizzato per lo stesso. Comunque vorrei suggerire un lavoro in giro.

  1. Utilizza la versione di prova di Burp Professional [Ci vorranno un giorno o due perché possano inviare la licenza di prova.]
  2. In Opzioni utente > Varie nella sezione Registrazione fai clic sulla casella di controllo per registrare tutte le risposte.
  3. Sfoglia l'applicazione, spiderla, seleziona le richieste che vuoi scansionare, inviale alla scheda dello scanner. Identificherà le solite vulnerabilità, ma potrebbe mancare qualche XSS persistente.
  4. Sfoglia e spider di nuovo attraverso l'intera applicazione dopo la scansione con tutti i livelli di privilegio dell'utente.
  5. Controlla il file di log per gli script. Gli script di Burp injected possono essere distinti in quanto di solito portano con sé una firma di caratteri casuali. Ad esempio, lo script iniettato potrebbe apparire come

    jklmn | script iniettato che stackexchange non mi permetterà di postare | jklmn

  6. Pertanto, se si identificano script immessi nel file di registro delle risposte, è possibile identificare la pagina, i parametri e l'origine del riflesso.

risposta data 18.10.2016 - 16:37
fonte

Leggi altre domande sui tag