Le patch XHR possono prevenire gli effetti collaterali XSS?

Naviga le tue risposte
9

XSS & App per pagina singola

Sto facendo ricerche sulla sicurezza Web e ho visto che l'autenticazione basata su token è utile per la prevenzione di CSRF, le architetture di sistema distribuite e le prestazioni di elaborazione.

Ma un altro problema è l'XSS. Non parlando specificamente dell'iniezione stessa, ma delle librerie. Con le app a pagina singola gli sviluppatori normalmente includono centinaia di moduli diversi nel loro codice, che potrebbero in seguito essere eseguiti maliziosamente quando l'app è in produzione.

Patching XMLHttpRequest

Quindi mi è venuta l'idea di applicare la patch alla proprietà XMLHttpRequest e assumere il controllo della funzione "codice nativo" originale, evitando che il codice di terze parti effettuasse richieste di tipo jax. 

(function () {
  // my code
  let XHR = window.XMLHttpRequest
  window.XMLHttpRequest = null
})()

// load third-party code after...

Ho provato questo nella console con facebook e youtube ... tutti i loro contenuti caricati ajax smettono di funzionare.

Esempio dannoso

Un esempio di comportamento malevolo non protetto è il codice che viene eseguito solo in produzione controllando se window.location è qualcosa come "app.x.com", quindi lo sviluppatore non si rende conto delle richieste ajax durante lo sviluppo.

L'applicazione della patch alla proprietà XMLHttpRequest lo avrebbe impedito, e tenendo conto che tutti gli altri parametri sono stati presi per prevenire l'XSS (sanitizzazione), questo avrebbe chiuso il gap finale e permesso di prendere il controllo delle richieste di rete, impedendo al codice dannoso di rubare l'autenticazione token.

Dubbio finale

Ci sono dei caveat a questo approccio? (Sicurezza-saggio)

    
posta Hadrian 05.06.2016 - 06:49
fonte

2 risposte

8

Are there any caveats to this approach? (security-wise)

Sì, non è molto accurato, puoi invece ottenere una nuova istanza del costruttore da un nuovo oggetto della finestra: 

XMLHttpRequest = null;

var iframe = document.createElement('iframe');
iframe.style.display = 'none'; // optional
document.body.appendChild(iframe);
var XHR = iframe.contentWindow.XMLHttpRequest;
console.log(new XHR());

Dovresti sovrascrivere molte più cose per assicurarti che non sia possibile accedere a XMLHttpRequest , questo è solo un modo per farlo.

Per la protezione XSS, basta utilizzare una politica di sicurezza del contenuto e utilizzare solo le librerie attendibili da fonti attendibili.

    
risposta data 05.06.2016 - 08:24
fonte
2

Anche se funzionasse e potresti bloccare JavaScript dall'esecuzione di XMLHttpRequests - che come mostrato da @Alexander non è il caso (ActiveXObject sarebbe un'altra alternativa) - in realtà non limita i pericoli di XSS.

Un utente malintenzionato ha ancora un certo numero di possibilità:

  • Defacement
  • Phishing : ad esempio, aggiungi un modulo di accesso, che invia i dati inseriti a un server controllato da un utente malintenzionato
  • Estrazione dei dati : mentre un utente malintenzionato non può inviare dati acquisiti tramite XMLHttpRequest, può forzare un reindirizzamento tramite il metatag aggiorna e invia i dati in questo modo.
  • CSRF : il token può essere acquisito come descritto sopra, quindi un modulo può essere creato e inviato tramite JavaScript.
  • Richieste di rete : l'esempio di modulo di cui sopra è anche il modo in cui è possibile eseguire qualsiasi richiesta di rete senza utilizzare XMLHttpRequests.

Non c'è davvero un buon modo per prevenire tutti questi punti (per lo meno, è necessario impedire qualsiasi modifica al DOM, che non credo sia possibile).

Devi fidarti delle librerie JavaScript di terze parti che usi.

Se non ti fidi del venditore, devi riprodurre da solo la funzionalità.

    
risposta data 05.06.2016 - 10:12
fonte

Leggi altre domande sui tag

Quali fattori dovresti prendere in considerazione al momento di decidere se gli utenti debbano essere informati di un test di penetrazione? Come determinare se un provider VPN rispetta la riservatezza dei dati?