Le immagini visualizzate sui profili per URL hanno implicazioni sulla sicurezza?

Question

Le immagini visualizzate sui profili per URL hanno implicazioni sulla sicurezza?

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

3

Sto sviluppando un'applicazione Web Attualmente, in cui gli utenti possono creare un profilo e compilare le informazioni dell'utente, in questo ho anche conservato una sezione per l'immagine del profilo, in quanto ho usato una logica che nessun utente deve caricare qualsiasi immagine per l'immagine del profilo solo per il test e invece di quello che sto mostrando immagini come <div style="background-image: url("http://example.com/image.jpg")></div>

In questo ho creato un Input per l'utente per posizionare il percorso dell'immagine jpg da qualsiasi sito che gli piace e io visualizzo direttamente l'immagine solo da quel sito, che è http://example.com/image.jpg nel nostro caso.

Voglio prendere in considerazione la situazione peggiore qui, non ho inserito alcun controllo né inserito nella whitelist tutti i domini in example.com/image.jpg . Ho inserito un URL come http://stackoverflow.com/index.html che mi mostra vuoto, ho provato molti script PHP come http://attacker.com/omg.php e non esegue lo script sul mio dominio.

C'è qualche possibilità di vettore di attacco qui? Se sì, gentilmente suggeriscimi. Inoltre, qui è possibile il Bypass CORS o SOP, ho la protezione CSP del dominio.

Nota: nella sezione URL, eseguo il primo controllo di convalida in scheme di URL dove http: //, // e https: // sono WhiteListed & nella sezione Immagine ho SOLO numeri in whitelist + alfabeti e caratteri speciali come . , - & / . Il resto è bloccato

web-browser web-application xss same-origin-policy

posta Gerorge Timber 24.06.2016 - 09:34

fonte

2 risposte

Leggi altre domande sui tag web-browser web-application xss same-origin-policy

Invio di rumore su cavo, utilizzando hash di rumore per trasportare dati Posso ingannare un server di posta per inviarmi un'email?

score 2 · Answer 1

i tried many php scripts like http://attacker.com/omg.php and it doesn't runs the script on my domain ..

Il problema qui non sarebbe una vulnerabilità lato server ma più una vulnerabilità XSS riflessiva che gira sul browser non sul server, motivo per cui il file php non ha funzionato.

Tratto da OWASP ( vedi qui ):

Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

Se ho allegato un file (lascialo chiamarlo script.html) e ho eseguito Javascript lì, allora chiunque visualizzi la "immagine" eseguirà Javascript sul proprio browser.

Ad esempio:

Sono un utente sul tuo sito web e allego un'immagine del profilo con il link http://mymalicouswebsite.com/script.html e nel file script.html ho il seguente codice:

...Some HTML...
<script>
    window.onload = function(){
        //Anything I put here will run on any viewers browser
    }
</script>
...Some HTML...

Questo può essere anche peggio, l'attaccante può fare quanto segue:

Sostituisci l'intero% html% co_de con qualsiasi contenuto desideri (può caricare un body che è una pagina di phishing)
Può rubare i cookie degli utenti e inviarlo alla sua pagina usando AJAX
Reindirizza l'utente su un'unità in cui verrà scaricato un virus e l'utente penserà che provenga dal tuo sito web

Now, Is there any Possibility of Attack vector here, If yes, kindly suggest me. And also is CORS or SOP Bypass possible here, I have CSP protection of the domain.

CORS è quando una richiesta HTTP proviene da uno script che non è questo caso. Quello che stai facendo è come se caricassi un iframe .

Informazioni su iframe : dovrei vedere le tue impostazioni che sono impostate per vedere se un attacco può essere fatto ...

score 2 · Answer 2

Il rischio non è che uno script come http://attacker.com/omg.php venga eseguito sul tuo dominio, è che un utente riesce a uscire da

<div style='background-image: url("http://example.com/image.jpg")'></div>

contesto in cui l'URL è scritto nella pagina. Nota che il codice è stato corretto dalla tua domanda (le virgolette usate per l'attributo HTML rendono le cose più chiare).

PHP è lato server, tuttavia, poiché stai visualizzando un'immagine lato client, non c'è alcun rischio sul lato server.

Anche se è stato inserito //example.com/evil.js , lo script non verrà eseguito sul browser perché è richiesto nel contesto di un'immagine, non di uno script.

Torna al problema: per mitigare l'utente che riesce ad uscire dal contesto in cui è scritto l'URL, è necessario attenuare XSS (Cross-site scripting) .

Per questo vedi la regola n. 4 qui : "CSS Escape e validamente convalidare prima di inserire dati non attendibili nei valori delle proprietà dello stile HTML ".

Non farlo potrebbe consentire all'utente di inserire qualcosa come

")'><script>alert('xss')</script>

come URL dell'immagine che renderà

<div style='background-image: url("")'><script>alert('xss')</script>")'></div>

sulla pagina ed esegui lo script. Qui mostra solo una finestra di avviso, tuttavia è possibile utilizzare le vulnerabilità XSS per compromettere l'intera sessione utente.

La regola per rendere questo sicuro è la seguente:

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH escaping format.

Questo dovrebbe essere fatto sull'output alla pagina.

Come seconda linea di difesa, puoi anche convalidare sull'input che l'URL inserito inizia con http:// , // o https:// e chiedi all'utente di correggerlo se non. Questo sarebbe un controllo extra rispetto a javascript: URL, tuttavia è comunque necessaria la codifica corretta per impedire CSS e attribuzioni del contesto degli attributi.