Este suficient să se transforme „, < and > pentru a evita XSS în șirurile JavaScript? (Securitatea informațiilor, Xss, Javascript, Html)

Sanchit Sharma a intrebat.

Este suficient să convertim ' în &#039; , > în &gt; și < în &lt; pentru a evita XSS atunci când se inserează date nesigure într-un șir de caractere JavaScript ca mai jos?

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

Există exemple de situații în care conversia de mai sus nu este suficientă pentru a evita XSS?

Comentarii

  • De ce filtrarea unui singur caracter ar rezolva problema XSS? Ce se întâmplă cu param='</script><script>alert(1)//' –  > Por tura.
  • Sau, în cazul în care se completează mai multe câmpuri, o simplă backslash în primul și în ;alert(1)// în al doilea. –  > Por Polinomul.
2 răspunsuri
Milen

Nu vă bazați pe folosirea propriilor reguli de „conversie”, OWASP recomandă utilizarea unei biblioteci de codificare axată pe securitate pentru a vă asigura că regulile necesare sunt implementate corect:

Evadați următoarele caractere cu codificarea entităților HTML pentru a preveni trecerea în orice context de execuție, cum ar fi scripturi, stiluri sau gestionari de evenimente. În plus față de cele 5 caractere semnificative în XML (&, <, >, „, ‘), este inclusă și bara oblică, deoarece ajută la încheierea unei entități HTML.

Codificarea entităților HTML este bună pentru datele nesigure pe care le introduceți în corpul documentului HTML, cum ar fi în interiorul unui fișier <div> tag. Cu toate acestea, nu ar fi suficientă într-o serie de cazuri, cum ar fi „contextele imbricate”:

<script>...param used directly here...</script>
<!--...param used inside an HTML comment...-->
<div ...param used in an attribute name=test />
<param as a tag name href="/test" />
<style>...param used directly in CSS...</style>

În general, nu utilizați niciodată param în interiorul oricăreia dintre aceste entități imbricate, chiar dacă este codificată ca entitate HTML.

Comentarii

  • sunt de acord că ar trebui să folosim o librărie axată pe securitate, dar căutam un exemplu specific pentru contextul menționat. aveți vreo idee? –  > Por Sanchit Sharma.
  • @Milen Posturile dvs. trebuie să conțină citate. Legătura cu foaia de înșelăciune OWASP XSS filter evasion cheat sheet, sau XSS prevention cheat sheet. –  > Por rook.
  • @Rook îmi pare rău, ai perfectă dreptate, ar fi trebuit să adaug sursa. –  > Por Milen.
Ry-

Nu este suficient, nu. Exemplu de backslash artificial:

<script>
var param1 = '{{ param1 }}'; var param2 = '{{ param2 }}';
</script>
param1=&param2=;alert(1)//
<script>
var param1 = ''; var param2 = ';alert(1)//';
</script>

Ca să nu mai vorbim de faptul că datele dvs. nu vor supraviețui intacte:

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

Newlines (r, ,
, , u2028, , u2029) pot, de asemenea, să întrerupă un șir JavaScript, deși este probabil rar ca acest lucru să creeze o vulnerabilitate, deoarece este invariabil o eroare de sintaxă. Dacă aveți neapărat nevoie să introduceți datele de intrare ale utilizatorului într-o variabilă într-un inline <script> inline, v-aș recomanda codificarea JSON urmată de o înlocuire de </ cu </ și <! cu <!. Totuși, cea mai bună metodă este de a utiliza o codificare HTML fiabilă în afara scriptului:

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

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

Faptul că nu aveți scripturi dinamice vă permite să implementați CSP-uri puternice.