Cos'è una pratica più sicura? Hosting da CDN o sito Web principale

Question

Cos'è una pratica più sicura? Hosting da CDN o sito Web principale

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

2

C'è stato un lungo dibattito sulla modellazione CSP, ho un'applicazione Web e uso JQuery in esso, per cui uso il sito principale di JQuery http://code.jquery.com/jquery-x.yy.z.min.js per ospitarlo sul mio sito per funzionare, so che i CDN possono essere utile in casi come questo, potrei anche inserire questo nei miei tag di script https://ajax.googleapis.com/ajax/libs/jquery/x.yy.z/jquery.min.js per risolvere lo stesso processo. Per quanto riguarda il tempo di caricamento, JQuery ospitato da Google è più veloce di code.jquery.com .

Ora, diciamo che uso la seconda parte di ajax.googleapis.com per ospitare il mio sito JQuery sul mio sito web. Ora, per posizionare il meccanismo di difesa in profondità per evitare XSS, utilizzo le intestazioni CSP (Content-Security-Policy), Ora la prima cosa che faccio è White-List di script-src 'self' ajax.googleapis.com . Ora, diciamo che ho una porzione sul mio sito Web dove Input viene riflesso senza filtri che possono causare XSS. Ora, gli script in linea come <script>alert(/xss/)</script> otterrebbero Bloccato e Fornirmi protezione. Ma c'è un negativo in seguito, dato che ho elencato in bianco ajax.googleapis.com, qualsiasi attaccante può usare Angular JS 1.1.3 dallo stesso e causare XSS proprio come "><script src="//ajax.googleapis.com/ajax/libs/angularjs/1.1.3/angular.min.js"></script><div ng-app ng-csp id=p ng-click=$event.view.alert(1337)><script async src=//ajax.googleapis.com/jsapi?callback=p.click></script>

Questo comporterà un attacco XSS, Ora il punto è Come potrei modificare la mia regola CSP in modo che blocchi ogni altro End-point del sito Whitelist che ho O se non è possibile di quanto immagino che l'API di Google CDN è sicuramente non è una scelta migliore di code.jquery.com . Qualche spiegazione su come allenarsi?

Perché anche se uso code.jquery.com e Whitelist, allora l'attaccante può usare la versione precedente di Jquery dallo stesso CDN e può erroneamente utilizzare la sua vulnerabilità per causare XSS. Quindi qual è la scommessa più sicura che posso mettere qui? Spiegare

google jquery xss content-security-policy

posta Gerorge Timber 22.07.2016 - 10:00

fonte

3 risposte

0

la mia comprensione è che non è possibile specificare singoli file JS. invece il principio è che ti fidi del provider CDN in questo caso ti fidi di Google. Penso che sarebbe una bella estensione al CSP se ti è permesso inserire nella whitelist il dominio e la risorsa JS.

risposta data 22.07.2016 - 10:23

fonte

0

Se vuoi davvero proteggere il javascript usato sul tuo sito, copia sul tuo server la parte jQuery che usi e servila direttamente da lì. Le CDN sono estremamente utili per contenuti di grandi dimensioni come i file video. Ma javascript non è così pesante e può essere normalmente memorizzato nella cache dai browser client, quindi lo caricano solo una volta per un'intera sessione.

risposta data 22.07.2016 - 14:14

fonte

Leggi altre domande sui tag google jquery xss content-security-policy

Quale attacco può essere rilevato dalle informazioni sul flusso del controller SDN? [chiuso] Perché il modello di token del sincronizzatore è preferito al controllo dell'intestazione di origine per impedire CSRF

score 0 · Accepted Answer

Potresti dare un'occhiata al "Fare CSP Great Ancora una volta " presentazione di AppSec Europe, che illustra alcune sfumature di implementazione di CSP efficaci.

Il commento per utente grc che menziona l'integrità delle risorse secondarie è un altro modo per garantire che solo gli script siano esplicitamente autorizzata (in base al contenuto dell'hash) può essere caricata. Ciò significa che è possibile evitare che un utente malintenzionato sia in grado di iniettare una versione vulnerabile di Angular (non riuscirà a eseguire il controllo SRI), tuttavia sarà necessario monitorare le nuove versioni di Angular / tenerlo aggiornato. Inoltre, è probabile che lo script con inietto attacker probabilmente non includa un hash SRI (e quindi qualsiasi libreria può essere caricata) a meno che non siano in grado di influenzare solo l''src' di un tag script a cui è stato applicato l'hash.

L'unico modo per bloccare realmente altri endpoint vulnerabili è inserire nella whitelist percorsi specifici .js nel tuo CSP, tuttavia altamente consiglio di provarlo su più browser (e / o con qualche tipo di regressione test) per assicurarsi che non ricadano nella whitelist di tutta l'origine della fonte.

In alternativa, potresti preferire utilizzare un CSP non basato su nonce: link

L'idea è che, anche se l'autore dell'attacco può inserire un altro elemento di script, non sarà in grado di determinare il nonce e dovresti essere in grado di proibire script indesiderati che vivono sulla stessa origine con quella tecnica finché gli utenti non può influenzare il contenuto dell'attributo 'src' per i tag di script che benedici con il nonce.

Si noti, tuttavia, che questo non protegge ancora l'integrità del contenuto (se il tuo CDN viene acquisito, tutti quelli che estraggono JS da lì tireranno il contenuto dannoso). Per questo, l'SRI è necessario.