Un servizio RESTful è attualmente protetto dagli attacchi XSS applicando lo schema XML e la convalida dell'entità. In entrambi i casi ciò avviene tramite un'espressione regolare come:
<xs:pattern value="[0-9]{1}[0-9a-z/\ -]{0,7}" />
Questa convalida può essere considerata una contromisura affidabile contro XSS o devo implementare ulteriori misure di sicurezza?
Qui ci sono alcuni angoli:
(1) Interpretazione errata del tipo di risposta non HTML generato correttamente come HTML pericoloso. Questo è ciò di cui parla la risposta di Rook, partendo dal presupposto che il servizio REST restituisca una risposta come JSON o XML. Il problema è che alcuni browser (in particolare IE) potrebbero ignorare il Content-Type dichiarato e trattare un documento come HTML perché ha una stringa magica come <html nel primo / n / byte.
Una difesa contro questo nei browser moderni è usare l'intestazione X-Content-Type-Options: nosniff , che è una buona cosa da fare in tutte le risposte in generale. Per coprire tutti i casi è possibile utilizzare le regole di codifica per il proprio formato per evitare di inserire testo variabile potenzialmente sensibile in un modulo di codifica che non può essere interpretato erroneamente come HTML. In genere ciò significa scrivere < come \u003C nelle stringhe JSON, anche se < non è normalmente un carattere che richiede l'escape in JSON. Con XML sei coperto per questo, dato che hai bisogno di codificare un valore letterale < in < . Altri caratteri ci sono argomenti per la codifica (sebbene gli attacchi siano estremamente marginali) sono + e { .
(2) Risposta generata in modo errato, mancante della codifica corretta per il formato.
La convalida dell'input è una buona misura di difesa approfondita e un buon modo per applicare le regole aziendali. Ma non ti protegge dalle vulnerabilità di iniezione. Se si crea una risposta XML o JSON aggiungendo stringhe insieme senza escape esplicito, si ha la possibilità che un utente malintenzionato causi risposte errate che potrebbero essere interpretate da un altro chiamante. Questo probabilmente non si tradurrebbe in XSS diretto, ma potrebbe certamente causare problemi logici specifici dell'app.
Usa la forma corretta di codifica delle stringhe per il tuo contesto ogni volta che aggiungi stringhe insieme, o, meglio, usa le librerie di output dei dati che lo fanno automaticamente (es. serial JSON standard o serializzatore XML). Questo assicura che la tua risposta sia corretta, e la sicurezza è un effetto collaterale di quella correttezza.
(3) tipi di documento XML. Questa è una miscela di (1) e (2), dove l'iniezione ti dà la possibilità di interpretare l'XML come un diverso tipo di XML. Se hai un problema di iniezione di XML, un utente malintenzionato potrebbe essere in grado di includere un elemento nella tua risposta con un xmlns che punta agli spazi dei nomi XHTML o SVG. Se il documento viene caricato direttamente in un browser Web, questi possono includere contenuti di script eseguiti nell'origine di quel sito, e di nuovo esiste potenzialmente XSS.
(4) DOM XSS: gestione errata della risposta lato client. Se la risposta REST viene utilizzata da uno script del browser Web che accetta un valore nella risposta e imposta innerHTML su tale valore, hai ancora una vulnerabilità legata all'input HTML, solo in una posizione leggermente diversa.
Il content-type utilizzato dai servizi web dovrebbe indicare al browser di non interpretare la risposta come codice JavaScript eseguibile. Ad esempio, un servizio Web RESTful può utilizzare application/json o application/xml a seconda del tipo di marshalling utilizzato. È impossibile per un utente malintenzionato ottenere XSS con questi tipi di contenuto, indipendentemente dal contenuto del corpo.
Qualcosa a cui prestare attenzione sta accidentalmente impostando content-type su text/html o omettendola del tutto in quanto ciò potrebbe portare a XSS in un servizio web.
Leggi altre domande sui tag rest appsec xss attack-prevention web-service