Hva Er Forebygging Av Skripting På Tvers av Nettsteder?
Forebygging Av skripting på tvers av nettsteder Er prosessen med å oppdage OG utbedre xss-sårbarheter i nettsteder eller webapplikasjoner før de kommer i produksjon. Påvisning AV xss sårbarheter kan gjøres automatisk, ved hjelp av en automatisert sårbarhetsskanner, eller manuelt ved å utføre penetrasjonstester. I denne artikkelen vil du lære de beste praksisene for forebygging av skripting på tvers av nettsteder og hvordan du kan implementere dem umiddelbart. På slutten av artikkelen finner du også en lenke til en gratis, utviklerfokusert sårbarhetsskanner, slik at du kan begynne å oppdage og rette opp sårbarheter på tvers av nettsteder tidlig og ofte, som en del av utviklingsledningene dine
i denne artikkelen vil du lære:
- Hva Er Forebygging Av Skripting På Tvers av Nettsteder?
- hvordan fungerer skripting på tvers av nettsteder?
- hva er TYPENE XSS-angrep?
- hvor viktig er forebygging Av skripting på tvers av nettsteder?
- Beskyttelse Mot skripting på tvers av nettsteder
- Unnslippe dynamisk innhold
- Hvitelisteverdier
- Implementer en sikkerhetspolicy for innhold
- Sanitiser HTML
- HTTP-kun Informasjonskapsler
- XSS Forebygging med kodeeksempler
- forebygging av skripting på tvers av nettsteder I Python (Django)
- Forebygging av skripting på Tvers av nettsteder I Ruby (Rails)
- Forebygging av skripting på Tvers av Nettsteder I Java (Java Server Pages)
- Forebygging Av skripting på TVERS av NETTSTEDER I C# (ASP.NETTO)
- Forebygging Av skripting på tvers Av nettsteder I Node
- Bart.Js
- Støv.js
- Nunjucks
- Forebygging av skripting på TVERS av NETTSTEDER i PHP
- Forebygging Av skripting på Tvers av nettsteder I AngularJS
- Forebygging Av skripting på Tvers Av Nettsteder I React
- Hvordan kan automatiserte verktøy bidra til å forhindre skripting på tvers av nettsteder?
hvordan fungerer skripting på tvers av nettsteder?
cross-Site Scripting (XSS) – angrep er en form for injeksjonsangrep, der ondsinnede skript injiseres i pålitelige webapplikasjoner.
en angriper kan bruke webapplikasjonen til å sende ondsinnet kode, vanligvis i form av et sideskript i nettleseren, til en annen sluttbruker, noe som resulterer i ET xss-angrep.
xss-sårbarheter er svært vanlige, og forekommer der et webprogram bruker inndata fra en gyldig bruker i den genererte utgangen, men uten riktig validering eller koding.
med det ondsinnede skriptet sendt til brukeren, kan nettleseren ikke kategorisk vite at skriptet ikke skal stole på, og utfører deretter skriptet. Dette skriptet kan da få tilgang til en rekke data, inkludert informasjonskapsler, økttokener eller annen sensitiv informasjon som kan beholdes av nettleseren for det nettstedet.
hva er TYPENE XSS-angrep?
DET er tre hovedtyper AV xss-angrep:
- Reflektert XSS: skadelig skript kommer fra gjeldende HTTP-forespørsel
- Lagret XSS: ondsinnet skript kommer fra nettstedets database
- DOM-basert XSS: hvor sikkerhetsproblemet finnes i klientsiden kode i stedet for server-side kode.
hvor viktig er forebygging Av skripting på tvers av nettsteder?
skaden fra å utnytte EN xss-sårbarhet avhenger av sensitiviteten til dataene nettstedet håndterer. Her er noen eksempler hvor hackere utnyttet xss sårbare apps:
- Spre ormer på sosiale medier: Facebook, Twitter og YouTube har alle blitt angrepet på denne måten.
- Økt kapring: Skadelig JavaScript kan være i stand til å sende økt-ID til et eksternt nettsted under hackerens kontroll, slik at hackeren kan etterligne den brukeren ved å kapre en økt som pågår.
- Identitetstyveri: Hvis brukeren legger inn konfidensiell informasjon som kredittkortnumre i et kompromittert nettsted, kan disse detaljene bli stjålet ved hjelp av skadelig JavaScript.
- Denial of service angrep og nettsted hærverk.
- Tyveri av sensitive data, som passord.
- Økonomisk svindel på banktjenester nettsteder.
beskyttelse Mot skripting på tvers av nettsteder
Unnslippe dynamisk innhold
vanligvis veves dynamisk innhold inn I HTML når en nettside gjengis. Hvis det dynamiske innholdet behandles feil, kan en angriper bruke det til å konstruere et lagret XSS-angrep. Angriperen misbruker et redigerbart felt ved å sette inn skadelig JavaScript-kode, som evalueres i nettleseren når en annen bruker besøker siden.
du vil kanskje ikke at brukerne skal skrive rå HTML med mindre nettstedet ditt er et innholdsstyringssystem. Unnslippe alt dynamisk innhold som kommer fra et datalager, slik at nettleseren vet at det skal behandles som innholdet I HTML-koder, i motsetning TIL rå HTML.
Escaping dynamisk innhold består vanligvis av å erstatte signifikante tegn MED HTML-entitetskodingen:
» "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
som du vil se i kodeeksemplene nedenfor, vil de fleste moderne rammer unnslippe dynamisk innhold som standard.
ved å rømme redigerbart innhold på denne måten, vil innholdet aldri bli behandlet som kjørbar kode av nettleseren. Dette vil forhindre DE FLESTE xss-angrep.
Hvitelisteverdier
hvis et dynamisk dataelement bare kan ta en håndfull gyldige verdier, begrenser du verdiene i datalageret. Sørg også for at gjengivelseslogikken bare tillater kjente, riktige verdier.
et eksempel der du kanskje vil bruke denne tilnærmingen, er å be en bruker om å velge sitt land fra en rullegardinliste, i stedet for å få dem til å skrive det inn manuelt.
Implementer en policy for innholdssikkerhet
Moderne nettlesere støtter Policyer For Innholdssikkerhet. Retningslinjer for innholdssikkerhet gjør det mulig for forfatteren av en nettside å kontrollere hvor JavaScript og andre ressurser kan lastes inn og kjøres fra.
for AT ET xss-angrep skal være mulig, må angriperen kunne kjøre ondsinnede skript på en brukers nettside-enten ved å injisere inline <script > – tagger et sted innenfor <html > -taggen på en side, eller ved å lure nettleseren til å laste JavaScript fra et ondsinnet tredjepartsdomene.
Hvis du Angir en sikkerhetspolicy for innhold i svaroverskriften, kan du be nettleseren om aldri å kjøre Innebygd JavaScript, og velge domenene Som Kan være Vert For JavaScript for en side:
Content-Security-Policy: script-src 'self' https://apis.google.com
ved å hviteliste Nettadressene som skript kan lastes inn fra, sier du implisitt at Inline JavaScript ikke er tillatt.
du kan også plassere sikkerhetspolicyen for innhold i en <meta> – kode i <head> – elementet på en side:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
denne tilnærmingen er svært effektiv for å beskytte brukerne, men krever disiplin for å gjøre nettstedet ditt klart for en slik overskrift. Selv om det å ha inline-skript anses som en dårlig praksis i moderne webutvikling, er de vanlige på eldre, eldre nettsteder.
hvis du vil migrere fra inline-skript trinnvis, bør du vurdere Å bruke CSP-Bruddrapporter. Ved å legge til et rapporturi-direktiv i policyoverskriften, vil nettleseren varsle deg om eventuelle brudd på retningslinjene, i stedet for å forhindre Inline JavaScript fra å utføre:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
Dette vil gi deg forsikring om at det ikke er dvelende inline skript, før du forby dem direkte.
Sanitize HTML
for noen nettsteder er det et legitimt behov for å lagre og gjengi rå HTML. Hvis området lagrer og gjengir rikt innhold, må du bruke ET BIBLIOTEK FOR HTML-rensing for å sikre at ondsinnede brukere ikke kan injisere skript i HTML-innleveringene sine.
HTTP-only Cookies
Skadelig JavaScript kan brukes til å stjele en informasjonskapsel som inneholder brukerens økt-ID. Det er sjelden en god grunn til å lese eller manipulere informasjonskapsler i JavaScript på klientsiden, så vurder å merke informasjonskapsler som BARE HTTP, noe som betyr at informasjonskapsler vil bli mottatt, lagret og sendt av nettleseren, men kan ikke endres eller leses Av JavaScript.
Xss-Forebygging med kodeeksempler
Forebygging av skripting på tvers av Nettsteder I Python (Django)
Maler I Django escape HTML som standard, så alt som ser ut som følgende er generelt trygt:
**{{ contents }}**
du kan overstyre escape ved å bruke / safe-filteret. Det er ofte gode grunner til å gjøre dette, men du må utføre kodevurderinger på alt som bruker denne kommandoen:
**{{ contents | safe }}**
Merk AT HTML-escaping også kan slås på eller av med {% autoescape %} – taggen.
Forebygging Av skripting på tvers av Nettsteder I Ruby (Rails)
Rails-maler unnslipper HTML som standard, så alt som ser ut som følgende er generelt trygt:
<%= contents %>
du kan overstyre escape ved hjelp av raw-funksjonen, eller ved hjelp av operatoren <%==. Det er ofte gode grunner til å gjøre dette, men du må utføre kodevurderinger på alt som bruker disse funksjonene:
<% raw contents %>
<%== contents %>
Forebygging av skripting på Tvers Av Nettsteder I Java (Java Server Pages)
Bruk c:out – taggen for å trygt unnslippe HTML:
<c:out value="${contents}">
FØLGENDE måter å skrive til en mal, unngår IKKE HTML, så du bør bruke dem med forsiktighet:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Forebygging Av skripting på TVERS AV nettsteder i C# (ASP.NET)
Bruk en av følgende funksjoner for å trygt unnslippe HTML (skjemaet <%: ble introdusert i ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
følgende måte å skrive til en mal unnslipper IKKE HTML automatisk, så du bør bruke dem med forsiktighet:
<%= contents %>
Bruk HttpUtility.HtmlEncode(...) hvis DU trenger Å manuelt unnslippe HTML.
Forebygging Av skripting på tvers av nettsteder I Node
Bart.js
I Bart.js, noen koder i doble barter automatisk unnslippe HTML:
{{ contents }}
Husk at koder i triple mustaches ikke unnslipper HTML, så bruk dem med forsiktighet:
{{{ contents }}}
Støv.js
nøkkel koder automatisk unnslippe HTML:
{ contents }
rømmer kan imidlertid deaktiveres med operatøren |s, så bruk dette med forsiktighet
{ contents | s }
Nunjucks
Hvis auto-escaping er slått på i miljøet, vil Nunjucks automatisk unnslippe koder for sikker utgang:
{{ contents }}
Innhold merket med safe filter vil ikke bli rømt-bruk denne funksjonen med forsiktighet:
{{ contents | safe }}
Auto-escaping kan deaktiveres for en mal, i så fall koder må rømmes manuelt:
{{ contents | escape }}
Cross-site scripting prevention I PHP
echo-kommandoen i PHP unnslipper ikke HTML som standard, noe som betyr at enhver kode som følgende som trekker data direkte ut AV HTTP-forespørselen, er sårbar FOR xss-angrep:
<?php
Echo $_POST;
?>
Cross-site scripting prevention I AngularJS
alt innhold skrevet ut i krøllete parentes vil automatisk bli rømt, så følgende er trygt:
<div>{{dynamicContent}}</div>
Husk at noen kode som binder dynamisk innhold til innerhtml attributtet vil ikke bli automatisk rømt:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Forebygging Av skripting på tvers Av Nettsteder I React
ethvert dynamisk innhold skrevet ut i krøllete parenteser vil automatisk bli rømt I React, så følgende kode er trygt:
render() {
return <div>{dynamicContent}</div>
}
du kan også skrive ut raw HTML ved å binde innhold til egenskapen dangerouslySetInnerHTML. Navnet er ikke en tilfeldighet, så se etter en kode som ser ut som følgende:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
Hvordan kan automatiserte verktøy bidra til å forhindre skripting på tvers av nettsteder?
som nevnt ovenfor, kan det være enkelt å forhindre skriptangrep på tvers av nettsteder, med mange rammer som unngår dynamisk innhold som standard. Men at bekvemmelighet kan føre til utilsiktet og noen alvorlige sikkerhetssvakheter til søknaden din og din virksomhet.
sørg alltid for at du skanner programmene dine for sårbarheter før du slipper dem til produksjon, ideelt som en del Av DevOps-og ci / CD-rørledninger for å oppdage og rette opp sikkerhetsproblemer tidlig, på hver bygg / forplikte.
du kan begynne å automatisere sikkerhetstestene dine i dag med Neuralegions dynamic Application Security Testing scanner, Nexploit. Bygget for utviklere og uten falske positiver, kan du integrere den i pipelines for å skifte sikkerhetstesting til venstre og være sikker ved design.
Registrer DEG FOR DIN GRATIS konto her: https://nexploit.app/signup