Implicazione dell'iniezione URL in un servizio di abbreviazione URL

Question

Implicazione dell'iniezione URL in un servizio di abbreviazione URL

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

1

EDIT ci sono stati ritorsioni a monte o downvotes a causa, credo, di un grave fraintendimento della mia domanda. Di seguito non sono preoccupato dell'URL che porta a un sito che contiene malware o exploit (non che non sia una preoccupazione: semplicemente non è ciò di cui tratta questa domanda): sono preoccupato dell'iniezione nella stringa URL stessa. Quello che non voglio è che un pirata sia in grado di schivare la sicurezza "qualunque sia la struttura" ed essere in grado di iniettare, per esempio, il codice JavaScript in un URL che vorrei quindi mostrare ad altri utenti. In altre parole: sto cercando un'ulteriore misura per ridurre il rischio di rogue JavaScript in esecuzione come se provenisse dalla mia webapp.

Per indurire una webapp, sto pensando di non visualizzare mai gli URL inseriti dagli utenti e tuttavia consentirgli di inserire gli URL ma di utilizzare sempre un servizio di abbreviazione degli URL. Questo non ha lo scopo di sostituire altre buone pratiche di sicurezza ma di essere utilizzato in aggiunta ad altre pratiche di sicurezza.

Ecco uno scenario molto semplice:

l'unica cosa che un utente può inserire nel sito Web è un singolo URL
l'URL inviato dall'utente viene inviato a un servizio di accorciamento dell'URL esterno
l'URL abbreviato viene quindi pubblicato dal mio sito web

Se durante il primo passaggio consideriamo che il mio parser non ha difetti durante l'analisi dei parametri POST inviati dall'utente, cosa può andare storto in seguito se c'è un exploit di successo nell'URL che potrebbe influenzare il servizio di accorciamento dell'URL?

Fondamentalmente la mia idea sarebbe di servire, ad esempio, un hardcoded:

http://bit.ly/

seguito da una regola molto severa che dice qualcosa come: "inserisce al massimo 9 caratteri e questi caratteri devono essere alfanumerici" .

Lo farei per semplificare la regola relativa a quali caratteri possono e non possono essere inviati dall'utente: l'output di un URL bit.ly è molto più semplice di quello consentito dagli URL legittimi ( Ho usato bit.ly come esempio, qualsiasi servizio di accorciamento dell'URL che utilizza un sottoinsieme molto ristretto di caratteri negli URL abbreviati che restituisce farebbe).

Quindi, quale sarebbe il caso peggiore di se consideriamo che l'utente non autorizzato è in grado di sfruttare il mio sito web ma riesce comunque a sfruttare un difetto nel servizio di abbreviazione URL?

Quello che mi piacerebbe capire meglio è che cosa significa quando si tratta della stessa politica di origine / XSS e CSRF e altri tipi di exploit.

E, credo, la mia domanda potrebbe essere ripresa in questo modo: "Se la sicurezza viene eseguita correttamente sul mio sito web, gli exploit XSS che influiscono sul servizio di accorciamento dell'URL potrebbero essere la mia preoccupazione o no?"

L'idea generale sarebbe quella di aggiungere la difesa in profondità e considerare che il servizio di abbreviazione degli URL probabilmente sa come difendersi dalle iniezioni di URL.

webserver web-application url-redirection

posta Cedric Martin 09.04.2013 - 15:47

fonte

3 risposte

Leggi altre domande sui tag webserver web-application url-redirection

Come proteggere l'integrità dei file di risorse in un contesto di attacco white-box? Quante informazioni possono essere ottenute osservando qualcuno digitare la loro password?

score 2 · Answer 1

Questo è un modo inefficiente di fare le cose. L'unica sicurezza che otterresti da un servizio di abbreviazione URL esterno è che accorciano solo URL validi, e non codice javascript, ecc. Tuttavia, stai ancora facendo affidamento sulla loro sicurezza che loro accorciano effettivamente l'URL fornito dall'utente, saliranno il 100% del tempo e avranno 0 vulnerabilità di sicurezza. Perché non scrivere il tuo parser personale che verifica l'URL. Qualcosa del genere: link

Alcune cose che puoi cercare:

1: gli utenti hanno effettivamente inserito un URL che inizia con http: // e non un codice casuale di script java.

2- puoi anche utilizzare google safe browsing api per controllare l'URL del malware. link , questo è molto utile in quanto l'API di Google Safebrowsing restituirà malware per malware e 200 per URL validi, per qualsiasi altra cosa come l'URL non valido, l'API di google non restituirà nulla.

score 1 · Answer 2

Dipende da cosa fa il servizio shortener URL. Presumibilmente prende un input (l'URL completo) e produce un output (l'URL più piccolo), memorizzando la mappatura dall'URL più piccolo all'URL completo nel database. Può anche memorizzare un hash dell'URL più piccolo per essere più efficiente e rendere più veloci le ricerche. Sto solo speculando perché il modo in cui funziona dipenderà davvero dalla tua implementazione. Tuttavia, per quanto riguarda i componenti, l'SQL probabilmente utilizzerà un database per archiviare i mapping. Inoltre, il servizio stesso potrebbe avere accesso a quel database per garantire che i mapping duplicati non si verifichino. Sarebbe possibile produrre un'iniezione SQL se il servizio URL utilizza direttamente il database e lo fa male. L'iniezione SQL può essere prevenuta usando query parametrizzate.

In secondo luogo, il servizio di accorciamento degli URL sarebbe vulnerabile agli attacchi DOS in cui vengono eseguite più richieste di quante ne possa gestire. Questo vale soprattutto se è scritto male e non può generare rapidamente URL unici. Comunque non mi preoccuperei troppo di quello, gli attacchi DDoS possono essere lanciati contro chiunque.

Penso che hai modificato il tuo post per indicare che si tratta di un servizio di accorciamento esterno. Questo cambia le cose perché significa che non è il tuo database che è vulnerabile all'iniezione SQL, ma a qualcun altro. Davvero, non ci sono troppi rischi legati a questo tipo di servizio. Se qualcuno riesce a iniettare il database o comunque modificarlo, può far sì che gli utenti vengano reindirizzati all'URL sbagliato, uno che hanno impostato con codice dannoso. Questo servizio esterno potrebbe anche essere un pericolo per te in quanto può restituire qualsiasi URL precedente che desidera. Non c'è nulla che li costringa a implementare la mappatura in buona fede. Possono facilmente inviarti il 99% di buoni URL e l'1% di URL dannosi per siti dannosi creati dall'autore del servizio di accorciamento. Oppure il servizio di accorciamento potrebbe essere compromesso, il che influenzerà indirettamente il tuo sito web. Fondamentalmente, il servizio di accorciamento dell'URL ospitato esternamente ti risparmia un sacco di mal di testa perché hai meno attacchi di cui preoccuparti. Ma l'attacco più serio se il servizio esterno viene compromesso, è che gli utenti verranno nutriti con URL errati o malevoli. A seconda di come viene autenticato il servizio Web per recuperare questi mapping URL dal servizio URL, è possibile che venga eseguito un attacco MITM al fine di fornire all'utente anche URL falsi. E il tuo servizio web potrebbe potenzialmente essere sfruttato per hackerare anche il tuo server. Di nuovo, tutte queste cose dipendono dall'implementazione del servizio url shortener e dei servizi Web e dell'autenticazione ... molti fattori per i quali non ci avete fornito informazioni.

score 0 · Answer 3

Come farà il tuo server a sapere se l'URL proviene dal servizio di accorciamento o no? L'attaccante potrebbe semplicemente comportarsi come se fosse il servizio di abbreviazione degli URL e inviare le informazioni in un modo che potrebbe violare il sistema?

Non vedo come questo sia diverso dall'accettare gli URL, ma poi eseguire una Riscrittura di URL per garantire che le informazioni che hanno trasmesso sull'URL non vengano visualizzate, a meno che non manchi qualcosa sullo scenario proposto.

Se stai semplicemente utilizzando il servizio Abbreviazione URL per fornire token casuali per pagine particolari al tuo sito, allora perché non memorizzare semplicemente un segnalibro internamente nel tuo DB. In questo modo controlli l'input utilizzato per prevenire gli abusi. Anche se stai chiamando direttamente il servizio di accorciamento, cosa impedirebbe a un utente malintenzionato di creare il proprio URL abbreviato per il tuo dominio? (A meno che tu non abbia un servizio di accorciamento che restituirà solo i risultati dal tuo account.)