Può essere sfruttata una vulnerabilità xss senza autenticazione?

Question

Può essere sfruttata una vulnerabilità xss senza autenticazione?

#1 da (1 voti)
#2 da (0 voti)

0

Sono confuso riguardo alla superficie di attacco resa possibile da una vulnerabilità XSS. Supponiamo che io abbia una semplice applicazione web che non implichi l'autenticazione (forse un tipo di "parola del giorno"). Se è ingenuamente scritto e consente l'iniezione creando un collegamento dannoso, che tipo di danno può fare l'iniezione?

Per rendere le cose concrete, ecco uno script PHP (che altro) che è completamente aperto all'attacco, dal momento che invierà qualsiasi assurdità aggiunta all'URL della richiesta.

<html><body>
<p>
  <?php echo 'Access denied:' . $_SERVER["PHP_SELF"] ; ?>
</p>
</body></html>

Quanto male sarebbe avere questo problema sul mio server? Cosa può accadere esattamente? Il mio script non raccoglie o archivia alcun dato, quindi non c'è alcuna possibilità di un'iniezione persistente sul mio server.

Se l'utente che fa clic sul link dannoso si fida del mio dominio, potrebbe essere indotto a fare o accettare cose che altrimenti non farebbero. Ma se il mio dominio non gode di una fiducia speciale, c'è ancora il pericolo? L'utente malintenzionato ha già avuto accesso all'utente / vittima per indurli a trovarmi attraverso il link corretto, quindi il mio sito Web rappresenta davvero un pericolo aggiuntivo?
Poiché il codice riflesso sembra provenire dal mio dominio, l'utente malintenzionato potrebbe ottenere l'accesso alla mia intranet? Suppongo che in questo caso non siano necessari trucchi: l'attaccante può eseguire le richieste maligne direttamente sul mio server, giusto?

Mi manca qualcosa qui, per favore aiutami a capire di cosa si tratta.

xss

posta alexis 11.11.2018 - 01:18

fonte

2 risposte

Leggi altre domande sui tag xss

Se la condivisione cross-cookie tra le app Android è una potenziale minaccia per la privacy? 4G Pocket WiFi - Catcher IMSI?

score 1 · Answer 1

If the user clicking on the malicious link trusts my domain, they could be tricked into doing or accepting things that they wouldn't otherwise. But if my domain enjoys no special trust, is there still danger? The attacker has already had access to the user/victim to trick them into visiting me through the doctored link, so is my website really posing an additional danger?

L'utente malintenzionato non ha accesso necessariamente all'utente. Potrebbero aver appena inviato un'email di spam con un link o creato un profilo di social media falso per inviare loro quel link. Dal momento che il tuo sito sembra abbastanza benigno (potrebbero persino sapere del sito e fidarsi di esso) potrebbero essere più propensi a fare clic sul link.

Hai ragione che c'è un impatto minore in quanto il tuo dominio non ha segreti su di esso e nessuna autenticazione. Questo è certamente vero per gli utenti generali, almeno. Ma considera che se tu avessi, ad esempio, un pannello di amministrazione CMS sul tuo sito per la gestione del contenuto o di un blog, l'utente malintenzionato potrebbe invece indurti a fare clic su un link dannoso e attivare XSS per ottenere l'accesso a quel pannello.

Anche se improbabile, potrebbe essere anche possibile per un utente malintenzionato sfruttare il tuo sito come dominio attendibile al fine di fornire un exploit del browser tramite l'XSS. Un esempio comune di questo è dove un utente malintenzionato scrive uno script che rivela informazioni identificative su qualcuno che sta navigando tramite il browser Tor e induce l'utente a abilitare gli script su quello che sembra un dominio benigno e attendibile.

Since the reflected code appears to originate on my domain, could the attacker gain access to my intranet? I suppose in this case no trickery is needed: the attacker can run the malicious requests directly on my server, right?

Se per "intranet" intendi altri siti sulla tua LAN locale, non in generale. Le richieste di origine incrociata vengono negate a meno che il server di destinazione non consenta loro di utilizzare un'intestazione CORS. I sottodomini non sono raggiungibili anche a causa della stessa politica di origine a meno che tu non lo sostituisca: http://foo.com non può raggiungere http://x.foo.com o http://y.foo.com e http://x.foo.com non può raggiungere né http://y.foo.com né http://foo.com senza un criterio CORS permissivo applicato dal dominio di destinazione.

Non sono sicuro di cosa intendi con "esegui le richieste dannose direttamente sul mio server": i risultati XSS nell'esecuzione dello script sul lato client, non sul lato server.

score 0 · Answer 2

Se il sito vulnerabile non condivide un dominio con operazioni sensibili alla sicurezza e non è un sito "attendibile" che gli utenti hanno motivi particolari per ritenere sia legittimo (ad esempio, dove gli utenti potrebbero credere che l'inserimento di credenziali perché qualcosa dovrebbe essere previsto), quindi l'XSS non è un rischio significativo.

Se il dominio (compresi i domini di livello superiore o sottodominio) viene usato per qualcosa di particolarmente sensibile, allora c'è un rischio, poiché un utente malintenzionato potrebbe accedere o manipolare i cookie o dirottare le sessioni anche se quella particolare pagina non è autenticata. Se il dominio è affidabile (ad esempio, un'applicazione web interna aziendale), è probabile che le persone siano meno sospettose se, ad esempio, chiedono loro di accedere con le proprie credenziali aziendali. Infine, alcuni siti possono ancora avere sessioni che devono essere mantenute sicure, anche senza autenticazione. Considera un sito di prenotazione biglietti che non richiede agli utenti di avere un account prima di acquistare un biglietto, ma dove un XSS potrebbe ancora rubare le informazioni di pagamento dell'utente o simili.