Hvad er forebyggelse af Scripting på tværs af steder?
forebyggelse af scripting på tværs af steder er processen med at opdage og afhjælpe sårbarheder i dine hjemmesider eller applikationer, før de rammer produktionen. Detektion af sårbarheder kan udføres automatisk ved hjælp af en automatiseret sårbarhedsscanner eller manuelt ved at udføre penetrationstest. I denne artikel lærer du de bedste fremgangsmåder til forebyggelse af scripting på tværs af steder, og hvordan du kan implementere dem med det samme. I slutningen af artiklen finder du også et link til en gratis, udviklerfokuseret sårbarhedsscanner, så du kan begynde at opdage og afhjælpe sårbarheder på tværs af Site scripting tidligt og ofte som en del af dine udviklingsrørledninger
i denne artikel lærer du:
- Hvad er Cross-Site Scripting forebyggelse?
- Hvordan fungerer scripting på tværs af steder?
- hvilke typer af angreb?
- hvor vigtigt er forebyggelse af scripting på tværs af steder?
- Cross site scripting protection
- Escape dynamic content
- hvidlisteværdier
- Implementer en indholdssikkerhedspolitik
- Rens HTML
- HTTP-kun Cookies
- kodeeksempler
- forebyggelse af scripting på tværs af steder i Python (Django)
- forebyggelse af scripting på tværs af steder i Ruby (Rails)
- forebyggelse af scripting på tværs af steder i Java (Java-Serversider)
- forebyggelse af scripting på tværs af steder i C# (ASP.NET)
- forebyggelse af scripting på tværs af steder i Node
- overskæg.js
- støv.js
- Nunjucks
- forebyggelse af scripting på tværs af steder i PHP
- forebyggelse af scripting på tværs af steder i AngularJS
- forebyggelse af scripting på tværs af steder i React
- Hvordan kan automatiserede værktøjer hjælpe med at forhindre Cross-site scripting?
Hvordan fungerer scripting på tværs af steder?
Cross-Site Scripting angreb er en form for injektion angreb, hvor ondsindede scripts injiceres i betroede Internet applikationer.
en angriber kan bruge internetprogrammet til at sende ondsindet kode, typisk i form af et sidescript, til en anden slutbruger, hvilket resulterer i et HSS-angreb.
sårbarheder er meget almindelige, hvor et internetprogram bruger input fra en gyldig bruger indeholdt i det genererede output, men uden den relevante validering eller kodning.
med det ondsindede script, der sendes til brugeren, kan deres bro.ser ikke kategorisk vide, at scriptet ikke skal have tillid til, og udfører derefter scriptet. Dette script kan derefter få adgang til en lang række data, herunder eventuelle cookies, session tokens eller andre følsomme oplysninger, der kan opbevares af brugeren til det pågældende sted.
hvilke typer af angreb?
der er tre hovedtyper af angreb:
- ondsindet script kommer fra den aktuelle HTTP-anmodning
- gemt: ondsindet script kommer fra hjemmesidens database
- hvor sårbarheden findes i klient-side kode snarere end server-side kode.
hvor vigtigt er forebyggelse af scripting på tværs af steder?
skaden ved at udnytte en sårbarhed afhænger af følsomheden af de data, din hjemmeside håndterer. Her er nogle eksempler, hvor hackere udnyttede sårbare apps:
- spredning af orme på sociale medier: Facebook, Kvidre og YouTube er alle blevet angrebet på denne måde.
- Session kapring: Ondsindet JavaScript kan muligvis sende session-ID ‘ et til et eksternt sted under hackerens kontrol, så hackeren kan efterligne den bruger ved at kapre en igangværende session.
- identitetstyveri: hvis brugeren indtaster fortrolige oplysninger såsom kreditkortnumre i en kompromitteret hjemmeside, kan disse oplysninger blive stjålet ved hjælp af ondsindet JavaScript.
- lammelsesangreb og hærværk på hjemmesiden.
- tyveri af følsomme data, som adgangskoder.
- finansielle svig på bank sites.
Cross-site scripting protection
Escape dynamic content
normalt, når en hjemmeside gengives, bliver dynamisk indhold vævet ind i HTML. Hvis det dynamiske indhold behandles forkert, kan en hacker bruge det til at konstruere et gemt HSS-angreb. Angriberen ville misbruge et redigerbart felt ved at indsætte en ondsindet JavaScript-kode, som evalueres i Bro.sereren, når en anden bruger besøger denne side.
du vil måske ikke have dine brugere til at skrive rå HTML, medmindre din hjemmeside er et content management system. Undslippe alt dynamisk indhold, der kommer fra en datalager, så bro.ser ved, at det skal behandles som indholdet af HTML-tags, i modsætning til rå HTML.
at undslippe dynamisk indhold består generelt i at erstatte signifikante tegn med HTML-enhedskodningen:
” "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
som du vil se i kodeeksemplerne nedenfor, vil de fleste moderne rammer undslippe dynamisk indhold som standard.
ved at undslippe redigerbart indhold på denne måde vil indholdet aldrig blive behandlet som eksekverbar kode af bro.sereren. Dette vil forhindre de fleste angreb.
Hvidlisteværdier
hvis et dynamisk dataelement kun kan tage en håndfuld gyldige værdier, skal du begrænse værdierne i datalageret. Sørg også for, at din gengivelseslogik kun tillader kendte, korrekte værdier.
et eksempel, hvor du måske vil bruge denne tilgang, er ved at bede en bruger om at vælge deres land fra en rulleliste,, i stedet for at få dem til at skrive det manuelt.
implementere en indholdssikkerhedspolitik
moderne bro.Serere understøtter Indholdssikkerhedspolitikker. Indholdssikkerhedspolitikker gør det muligt for forfatteren af en hjemmeside at kontrollere, hvor JavaScript og andre ressourcer kan indlæses og udføres fra.
for at et angreb skal være muligt, skal angriberen kunne køre ondsindede scripts på en brugers hjemmeside – enten ved at injicere inline< script >tags et sted inden for< html > tag på en side eller ved at narre bro.sereren til at indlæse JavaScript fra et ondsindet tredjepartsdomæne.
Indstilling af en indholdssikkerhedspolitik i svaroverskriften giver dig mulighed for at bede bro. ser om aldrig at udføre inline JavaScript og vælge de domæner, der kan være vært for JavaScript til en side:
Content-Security-Policy: script-src 'self' https://apis.google.com
ved at hvidliste de URL ‘ er, hvorfra scripts kan indlæses, angiver du implicit, at inline JavaScript ikke er tilladt.
du kan også placere indholdssikkerhedspolitikken i et <meta> tag i <head> elementet på en side:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
denne tilgang er meget effektiv til at beskytte dine brugere, men kræver disciplin for at gøre din side klar til en sådan header. Mens det at have inline-scripts betragtes som en dårlig praksis i moderne internetudvikling, de er almindelige på ældre, ældre sider.
for at migrere væk fra inline scripts trinvist, overveje at gøre brug af CSP overtrædelse rapporter. Ved at tilføje et rapport-Uri-direktiv i din politikhoved, bro. ser vil underrette dig om eventuelle overtrædelser af politikken, snarere end at forhindre inline JavaScript i at udføre:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
dette vil give dig forsikring om, at der ikke er nogen dvælende inline scripts, før du forbyder dem direkte.
desinficer HTML
for nogle steder er der et legitimt behov for at gemme og gengive rå HTML. Hvis dit site gemmer og gengiver rigt indhold, skal du bruge et HTML-desinficeringsbibliotek for at sikre, at ondsindede brugere ikke kan injicere scripts i deres HTML-indlæg.
HTTP-only-Cookies
ondsindet JavaScript kan bruges til at stjæle en cookie, der indeholder brugerens session-ID. Der er sjældent en god grund til at læse eller manipulere cookies i JavaScript på klientsiden, så overvej at markere cookies som HTTP-only, hvilket betyder, at cookies vil blive modtaget, gemt, og sendt af bro.ser, men kan ikke ændres eller læses af JavaScript.
forebyggelse med kodeeksempler
forebyggelse af scripting på tværs af steder i Python (Django)
skabeloner i Django escape HTML som standard, så alt, hvad der ligner følgende, er generelt sikkert:
**{{ contents }}**
du kan tilsidesætte escape ved hjælp af / safe-filteret. Der er ofte gode grunde til at gøre dette, men du bliver nødt til at foretage kodeanmeldelser på alt, hvad der bruger denne kommando:
**{{ contents | safe }}**
bemærk, at HTML-escaping også kan slås til eller fra med tagget {% autoescape %}.
forebyggelse af scripting på tværs af steder i Ruby (Rails)
Rails-skabeloner undslipper HTML som standard, så alt, hvad der ligner følgende, er generelt sikkert:
<%= contents %>
du kan tilsidesætte escape ved hjælp af funktionen rå eller ved hjælp af operatoren <%==. Der er ofte gode grunde til at gøre dette, men du bliver nødt til at foretage kodevurderinger på alt, hvad der bruger disse funktioner:
<% raw contents %>
<%== contents %>
forebyggelse af scripting på tværs af steder i Java (Java-Serversider)
brug tagget c:out til sikkert at undslippe HTML:
<c:out value="${contents}">
følgende måder at skrive til en skabelon undgår ikke HTML, så du skal bruge dem med omhu:
<%= contents %>
${contents}
<%
out.println(contents);
%>
forebyggelse af scripting på tværs af steder i C# (ASP.NET)
brug en af følgende funktioner til sikkert at undslippe HTML (formularen <%: blev introduceret i ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
følgende måde at skrive til en skabelon undgår ikke HTML automatisk, så du skal bruge dem med omhu:
<%= contents %>
brug HttpUtility.HtmlEncode(...), hvis du manuelt skal undslippe HTML.
forebyggelse af scripting på tværs af steder i Node
overskæg.js
i overskæg.js, alle tags i dobbelt overskæg automatisk undslippe HTML:
{{ contents }}
Husk, at tags i tredobbelt overskæg ikke undslipper HTML, så brug dem med omhu:
{{{ contents }}}
støv.js
nøgle tags automatisk undslippe HTML:
{ contents }
escaping kan dog deaktiveres med operatøren |s, så brug dette med omhu
{ contents | s }
Nunjucks
Hvis auto-escaping er tændt i miljøet, vil Nunjucks automatisk undslippe tags for sikker udgang:
{{ contents }}
indhold, der er markeret med det sikre filter, undslipper ikke – brug denne funktion med omhu:
{{ contents | safe }}
Auto-escaping kan deaktiveres for en skabelon, i hvilket tilfælde tags skal undslippes manuelt:
{{ contents | escape }}
Echo-kommandoen i PHP undgår ikke HTML som standard,hvilket betyder, at enhver kode som den følgende, der trækker data direkte ud af HTTP-anmodningen, er sårbar over for:
<?php
Echo $_POST;
?>
forebyggelse af scripting på tværs af steder i AngularJS
ethvert indhold, der er skrevet ud i krøllede parenteser, slipper automatisk væk, så følgende er sikkert:
<div>{{dynamicContent}}</div>
Husk, at enhver kode, der binder dynamisk indhold til innerHTML-attributten, ikke automatisk undslippes:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
forebyggelse af scripting på tværs af steder i React
ethvert dynamisk indhold, der er skrevet ud i krøllede parenteser, undslippes automatisk i React, så følgende kode er sikker:
render() {
return <div>{dynamicContent}</div>
}
du kan også skrive rå HTML ved at binde indhold til dangerouslySetInnerHTML ejendom. Navnet er ikke tilfældigt, så pas på enhver kode, der ligner følgende:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
Hvordan kan automatiserede værktøjer hjælpe med at forhindre Cross-site scripting?
som nævnt ovenfor kan det være let at forhindre Cross-site scripting-angreb, hvor mange rammer undslipper dynamisk indhold som standard. Men denne bekvemmelighed kan føre til utilsigtet og nogle alvorlige sikkerhedssvagheder til din ansøgning og din virksomhed.
Sørg altid for at scanne dine applikationer for sårbarheder, før du frigiver dem til produktion, ideelt som en del af dine DevOps og CI/CD-rørledninger for at opdage og afhjælpe sikkerhedssårbarheder tidligt på hver build / commit.
du kan begynde at automatisere din sikkerhedstest i dag med Neuralegions dynamiske applikationssikkerhedstestscanner. Bygget til udviklere og uden falske positive, kan du integrere det i dine rørledninger for at skifte sikkerhedstest til venstre og være sikker ved design.
Tilmeld dig din gratis konto her: https://nexploit.app/signup