ce este prevenirea Scripturilor între Site-uri?
Cross-site scripting prevention este procesul de detectare și remediere a vulnerabilităților XSS în site-urile web sau aplicațiile web înainte de a ajunge la producție. Detectarea vulnerabilităților XSS se poate face automat, folosind un scaner automat de vulnerabilitate sau manual prin efectuarea de teste de penetrare. În acest articol veți afla cele mai bune practici pentru prevenirea scripturilor pe mai multe site-uri și cum le puteți implementa imediat. La sfârșitul articolului, veți găsi, de asemenea, un link către un scaner de vulnerabilitate gratuit, axat pe dezvoltatori, astfel încât să puteți începe să detectați și să remediați vulnerabilitățile de scriptare între site-uri devreme și adesea, ca parte a conductelor dvs. de dezvoltare
în acest articol, veți afla:
- ce este prevenirea Scripturilor între Site-uri?
- cum funcționează scriptarea pe mai multe site-uri?
- care sunt tipurile de atacuri XSS?
- cât de importantă este prevenirea scripturilor între site-uri?
- Cross Site scripting protection
- Escape dynamic content
- whitelist values
- implementați o politică de securitate a conținutului
- sterilizează HTML
- HTTP-only Cookies
- prevenirea XSS cu exemple de cod
- prevenirea Cross-site scripting în Python (Django)
- prevenirea Cross-site scripting în Ruby (Rails)
- prevenirea Cross-site scripting în Java (Java Server Pages)
- prevenirea Cross-site scripting în C# (ASP.NET)
- prevenirea scripting Cross-site-ul în nod
- mustață.js
- praf.js
- Nunjucks
- prevenirea Cross-site scripting în PHP
- prevenirea Cross-site scripting în AngularJS
- prevenirea Cross-site scripting în React
- Cum pot ajuta instrumentele automate la prevenirea scripturilor între site-uri?
cum funcționează scriptarea pe mai multe site-uri?
atacurile Cross-Site Scripting (XSS) sunt o formă de atac de injecție, în care scripturile rău intenționate sunt injectate în aplicații web de încredere.
un atacator poate utiliza aplicația web pentru a trimite cod rău intenționat, de obicei sub forma unui script lateral de browser, unui alt utilizator final, rezultând un atac XSS.
vulnerabilitățile XSS sunt foarte frecvente, apar atunci când o aplicație web utilizează intrări de la un utilizator valid conținut în ieșirea generată, dar fără validarea sau codificarea corespunzătoare.
cu scriptul rău intenționat trimis utilizatorului, browserul lor nu poate ști categoric că scriptul nu ar trebui să aibă încredere și, ulterior, execută scriptul. Acest script poate accesa apoi o multitudine de date, inclusiv orice cookie-uri, jetoane de sesiune sau, într-adevăr, orice alte informații sensibile care pot fi păstrate de browserul pentru acel site.
care sunt tipurile de atacuri XSS?
există trei tipuri principale de atacuri XSS:
- reflectat XSS: script rău intenționat vine de la cererea HTTP curent
- XSS stocate: script rău intenționat vine de la baza de date a site-ului
- XSS DOM-based: în cazul în care vulnerabilitatea există în cod client-side, mai degrabă decât codul server-side.
cât de importantă este prevenirea scripturilor între site-uri?
daunele cauzate de exploatarea unei vulnerabilități XSS depind de sensibilitatea datelor pe care site-ul dvs. le gestionează. Iată câteva exemple în care hackerii au exploatat aplicațiile vulnerabile XSS:
- răspândirea viermilor pe rețelele de socializare: Facebook, Twitter și YouTube au fost atacate cu succes în acest fel.
- deturnarea sesiunii: JavaScript rău intenționat poate fi capabil să trimită ID-ul sesiunii la un site la distanță sub controlul hackerului, permițând hackerului să se dea drept acel utilizator prin deturnarea unei sesiuni în curs.
- furt de identitate: dacă utilizatorul introduce informații confidențiale, cum ar fi numerele cărților de credit într-un site web compromis, aceste detalii pot fi furate folosind JavaScript rău intenționat.
- Denial of Service atacuri și site-ul vandalism.
- furtul de date sensibile, cum ar fi parolele.
- frauda financiară pe site-urile bancare.
Cross-site scripting protection
Escape conținut dinamic
de obicei, atunci când o pagină web este randat, conținut dinamic este țesute în HTML. Dacă conținutul dinamic este tratat necorespunzător, un atacator îl poate folosi pentru a construi un atac XSS stocat. Atacatorul ar abuza de un câmp editabil introducând un cod JavaScript rău intenționat, care este evaluat în browser atunci când un alt utilizator vizitează acea pagină.
este posibil să nu doriți ca utilizatorii dvs. să creeze HTML brut decât dacă site-ul dvs. este un sistem de gestionare a conținutului. Escape tot conținutul dinamic provenind dintr-un magazin de date, astfel încât browser-ul știe că este de a fi tratate ca conținutul tag-uri HTML, spre deosebire de HTML raw.
evadarea conținutului dinamic constă în general în înlocuirea caracterelor semnificative cu codificarea entității HTML:
” "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
după cum veți vedea în eșantioanele de cod de mai jos, majoritatea cadrelor moderne vor scăpa în mod implicit de conținutul dinamic.
prin evadarea conținutului editabil în acest fel, conținutul nu va fi niciodată tratat ca cod executabil de către browser. Acest lucru va preveni majoritatea atacurilor XSS.
valorile listei albe
dacă un element de date dinamic poate lua doar o mână de valori valide, restricționați valorile din depozitul de date. De asemenea, asigurați-vă că logica dvs. de redare permite numai valori cunoscute și adecvate.
un exemplu în cazul în care poate doriți să utilizați această abordare este de a cere un utilizator pentru a selecta țara lor dintr-o listă verticală,, în loc de a le tastarea manual.
implementați o politică de securitate a conținutului
browserele moderne acceptă Politici de securitate a conținutului. Politicile de securitate a conținutului permit autorului unei pagini web să controleze de unde pot fi încărcate și executate JavaScript și alte resurse.
pentru ca un atac XSS să fie posibil, atacatorul trebuie să poată rula scripturi rău intenționate pe pagina web a unui utilizator – fie prin injectarea de etichete inline < script>undeva în eticheta < html> a unei pagini, fie prin păcălirea browserului să încarce JavaScript dintr-un domeniu terț rău intenționat.
setarea unei politici de securitate a conținutului în antetul de Răspuns vă va permite să spuneți browserului să nu execute niciodată JavaScript în linie și să aleagă domeniile care pot găzdui JavaScript pentru o pagină:
Content-Security-Policy: script-src 'self' https://apis.google.com
prin lista albă a adreselor URL din care pot fi încărcate scripturile, declarați implicit că JavaScript inline nu este permis.
de asemenea, puteți plasa Politica de securitate a conținutului într-o etichetă <meta> în elementul <head> al unei pagini:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
această abordare este foarte eficientă în protejarea utilizatorilor dvs., dar necesită disciplină pentru a vă pregăti site-ul pentru un astfel de antet. În timp ce Scripturile inline sunt considerate o practică proastă în dezvoltarea web modernă, acestea sunt comune în site-urile vechi, vechi.
pentru a migra de la script-uri inline incremental, ia în considerare utilizarea rapoartelor de încălcare CSP. Prin adăugarea unei directive raport-uri în antetul politicii dvs., browserul vă va notifica orice încălcare a politicii, în loc să împiedice executarea JavaScript-ului inline:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
acest lucru vă va oferi asigurări că nu există scripturi inline persistente, înainte de a le interzice direct.
igienizați HTML
pentru unele site-uri, există o nevoie legitimă de a stoca și de a reda HTML brut. Dacă site-ul dvs. stochează și redă conținut bogat, trebuie să utilizați o bibliotecă de igienizare HTML pentru a vă asigura că utilizatorii rău intenționați nu pot injecta scripturi în trimiterile HTML.
cookie-uri numai HTTP
JavaScript rău intenționat poate fi folosit pentru a fura un cookie care conține ID-ul sesiunii utilizatorului. Rareori există un motiv bun pentru a citi sau manipula cookie-urile în JavaScript din partea clientului, deci luați în considerare marcarea cookie-urilor ca doar HTTP, ceea ce înseamnă că cookie-urile vor fi primite, stocate și trimise de browser, dar nu pot fi modificate sau citite de JavaScript.
prevenirea XSS cu exemple de cod
prevenirea scripturilor între site-uri în Python (Django)
șabloane în Django escape HTML în mod implicit, deci orice lucru care arată ca următoarele este în general sigur:
**{{ contents }}**
puteți trece peste escape utilizând filtrul / safe. Există adesea motive întemeiate pentru a face acest lucru, dar va trebui să efectuați recenzii de cod pentru orice folosește această comandă:
**{{ contents | safe }}**
rețineți că HTML-escaping poate fi, de asemenea, activat sau dezactivat cu eticheta {% autoescape %}.
prevenirea scripturilor între site-uri în Ruby (Rails)
șabloanele Rails scapă HTML în mod implicit, deci orice lucru care arată ca următoarele este în general sigur:
<%= contents %>
puteți suprascrie escape utilizând funcția raw sau utilizând operatorul <%==. Există adesea motive întemeiate pentru a face acest lucru, dar va trebui să efectuați recenzii de cod cu privire la orice folosește aceste funcții:
<% raw contents %>
<%== contents %>
prevenirea scripturilor între site-uri în Java (Java Server Pages)
utilizați eticheta c:out pentru a scăpa în siguranță de HTML:
<c:out value="${contents}">
următoarele moduri de a scrie într-un șablon nu scapă de HTML, deci ar trebui să le folosiți cu grijă:
<%= contents %>
${contents}
<%
out.println(contents);
%>
prevenirea scripturilor între site-uri în C #(ASP.NET)
utilizați oricare dintre următoarele funcții pentru a scăpa în siguranță HTML (formularul <%: a fost introdus în ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
următorul mod de a scrie într-un șablon nu scapă automat de HTML, așa că ar trebui să le folosiți cu grijă:
<%= contents %>
utilizați HttpUtility.HtmlEncode(...) dacă trebuie să scăpați manual de HTML.
Cross-Site scripting prevenirea în nod
mustață.js
în mustață.js, orice etichete din mustăți duble scapă automat HTML:
{{ contents }}
rețineți că etichetele din mustățile triple nu scapă de HTML, așa că folosiți-le cu grijă:
{{{ contents }}}
praf.js
tag-uri cheie scăpa automat HTML:
{ contents }
cu toate acestea, evadarea poate fi dezactivată cu operatorul |s, deci utilizați acest lucru cu grijă
{ contents | s }
Nunjucks
dacă auto-Evadarea este activată în mediul înconjurător, Nunjucks va scăpa automat tag-uri pentru ieșire în condiții de siguranță:
{{ contents }}
conținutul marcat cu filtrul sigur nu va fi scăpat – utilizați această funcție cu grijă:
{{ contents | safe }}
evadarea automată poate fi dezactivată pentru un șablon, caz în care etichetele trebuie scăpate manual:
{{ contents | escape }}
prevenirea scripturilor între site-uri în PHP
comanda echo din PHP nu scapă implicit de HTML, ceea ce înseamnă că orice cod precum următorul care scoate datele direct din cererea HTTP este vulnerabil la atacurile XSS:
<?php
Echo $_POST;
?>
prevenirea scripting Cross-site-ul în AngularJS
orice conținut scris în paranteze buclat va fi scăpat automat, astfel încât următoarele este sigur:
<div>{{dynamicContent}}</div>
rețineți că orice cod care leagă conținutul dinamic de atributul innerHTML nu va fi scăpat automat:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
prevenirea scripturilor între site-uri în React
orice conținut dinamic scris între paranteze curbate va fi scăpat automat în React, astfel încât următorul cod este sigur:
render() {
return <div>{dynamicContent}</div>
}
de asemenea, puteți scrie HTML brut prin legarea conținutului la proprietatea dangerouslySetInnerHTML. Numele nu este o coincidență, așa că căutați orice cod care arată după cum urmează:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
Cum pot ajuta instrumentele automate la prevenirea scripturilor între site-uri?
după cum s-a menționat mai sus, Prevenirea atacurilor de scriptare între site-uri poate fi ușoară, Multe cadre scăpând implicit de conținut dinamic. Dar această comoditate poate duce la inadvertență și la unele deficiențe grave de securitate pentru aplicația și afacerea dvs.
asigurați-vă întotdeauna că Scanați aplicațiile pentru vulnerabilități înainte de a le elibera în producție, în mod ideal ca parte a conductelor DevOps și CI/CD pentru a detecta și remedia vulnerabilitățile de securitate din timp, la fiecare construire / comitere.
puteți începe automatizarea testării de securitate astăzi cu scanerul dinamic de testare a securității aplicațiilor NeuraLegion, Nexploit. Construit pentru dezvoltatori și fără fals pozitive, îl puteți integra în conductele dvs. pentru a schimba testarea de securitate la stânga și a fi sigur prin design.
Înscrieți-vă pentru contul dvs. gratuit aici: https://nexploit.app/signup