E 'sufficiente convertire' ed evitare XSS nelle stringhe JavaScript?

Question

E 'sufficiente convertire' ed evitare XSS nelle stringhe JavaScript?

#1 da (9 voti)
#2 da (5 voti)

8

È sufficiente convertire ' in ' , > in > e < in < per evitare XSS quando si inseriscono dati non affidabili in una stringa JavaScript come sotto?

<script>
param='payload';
</script>

Ci sono esempi di situazioni in cui la conversione di cui sopra non è sufficiente per evitare XSS?

html javascript xss

posta Sanchit Sharma 27.11.2014 - 14:19

fonte

2 risposte

Leggi altre domande sui tag html javascript xss

È possibile provare quale chiave pubblica è stata utilizzata per crittografare un messaggio? Le librerie Javascript obsolete presentano un rischio per la mia applicazione web?

score 9 · Answer 1

Non fare affidamento sull'utilizzo delle tue regole di "conversione", OWASP consiglia di utilizzare un libreria di codifica orientata alla sicurezza per assicurarsi che le regole necessarie siano implementate correttamente:

Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity.

HTML entity encoding is okay for untrusted data that you put in the body of the HTML document, such as inside a <div> tag. However, it would not be sufficient in a number of cases, such as "nested contexts":
<script>...param used directly here...</script>

<div ...param used in an attribute name=test />
<param as a tag name href="/test" />
<style>...param used directly in CSS...</style>
In general, never use param inside any of these nested entities, even if HTML entity encoded.

score 5 · Answer 2

Non è sufficiente, no. Esempio di backslash contrived:

<script>
var param1 = '{{ param1 }}'; var param2 = '{{ param2 }}';
</script>

param1=\&param2=;alert(1)//

<script>
var param1 = '\'; var param2 = ';alert(1)//';
</script>

Per non parlare del fatto che i tuoi dati non sopravviveranno intatti:

<script>
var param1 = '&lt;';
alert(param1); // Shows up as &lt;, not <
</script>

Le nuove righe ( \r , \n , \u2028 , \u2029 ) possono anche rompere una stringa JavaScript, sebbene sia probabilmente raro che ciò crei una vulnerabilità, poiché è sempre un errore di sintassi. Se devi assolutamente inserire l'input dell'utente in una variabile inline <script> inline, ti consigliamo di codificare JSON seguito da una sostituzione di </ con <\/ e <! con <\! . Il modo migliore, tuttavia, è utilizzare una codifica HTML affidabile al di fuori dello script:

<div id="my-information" data-something="{{ param1 }}"></div>

<script>
var param1 = document.getElementById('my-information').getAttribute('data-something');
</script>

Non avere script dinamici ti consente di implementare CSP efficaci.