Vad är Cross-Site Scripting Prevention?
Cross-site scripting prevention är processen att upptäcka och åtgärda XSS-sårbarheter i dina webbplatser eller webbapplikationer innan de slår produktion. Detekteringen av XSS-sårbarheter kan göras automatiskt, med hjälp av en automatiserad sårbarhetsskanner eller manuellt genom att utföra penetrationstester. I den här artikeln kommer du att lära dig de bästa metoderna för förebyggande av skript på flera webbplatser och hur du kan implementera dem omedelbart. I slutet av artikeln hittar du också en länk till en gratis, utvecklarfokuserad sårbarhetsskanner så att du kan börja upptäcka och åtgärda serveröverskridande skriptsårbarheter tidigt och ofta, som en del av dina utvecklingspipelines
i den här artikeln kommer du att lära dig:
- Vad är Cross-Site Scripting Prevention?
- hur fungerar cross-site scripting?
- vilka typer av XSS-attacker?
- hur viktigt är Skriptskydd på flera webbplatser?
- Skriptöverskridande skriptskydd
- Fly dynamiskt innehåll
- vitlista värden
- implementera en innehållssäkerhetspolicy
- sanera HTML
- HTTP-endast Cookies
- XSS-förebyggande med kodexempel
- cross-site scripting prevention i Python (Django)
- cross-site scripting prevention i Ruby (Rails)
- Cross-site scripting prevention i Java (Java Server Pages)
- Cross-site scripting prevention i C# (ASP.NET)
- cross-site scripting förebyggande i Nod
- mustasch.js
- damm.JS
- Nunjucks
- cross-site scripting prevention i PHP
- Cross-site scripting prevention i AngularJS
- Cross-site scripting prevention i React
- hur kan automatiserade verktyg hjälpa till att förhindra cross-site scripting?
hur fungerar cross-site scripting?
Cross-Site Scripting (XSS) attacker är en form av injektion attack, där skadliga skript injiceras i betrodda webbapplikationer.
en angripare kan använda webbapplikationen för att skicka skadlig kod, vanligtvis i form av ett webbläsarskript, till en annan slutanvändare, vilket resulterar i en XSS-attack.
XSS-sårbarheter är mycket vanliga och uppstår där en webbapplikation använder inmatning från en giltig användare som finns i den genererade utgången, men utan lämplig validering eller kodning.
med det skadliga skriptet som skickas till användaren kan deras webbläsare inte kategoriskt veta att skriptet inte ska lita på och kör därefter skriptet. Detta skript kan sedan komma åt en mängd data, inklusive eventuella cookies, sessionstoken eller annan känslig information som kan behållas av webbläsaren för den webbplatsen.
vilka typer av XSS-attacker?
det finns tre huvudtyper av XSS-attacker:
- reflekterad XSS: skadligt skript kommer från den aktuella HTTP-begäran
- lagrad XSS: skadligt skript kommer från Webbplatsens databas
- DOM-baserad XSS: där sårbarheten finns i klientsidans kod snarare än serversidans kod.
hur viktigt är Skriptskydd på flera webbplatser?
skadorna från att utnyttja en XSS-sårbarhet beror på känsligheten hos de data som din webbplats hanterar. Här är några exempel där hackare utnyttjade XSS sårbara appar:
- spridning av maskar på sociala medier: Facebook, Twitter och YouTube har alla framgångsrikt attackerats på detta sätt.
- kapning av sessioner: Skadlig JavaScript kanske kan skicka sessions-ID till en avlägsen plats under hacker kontroll, vilket gör att hacker att imitera den användaren genom att kapa en session pågår.
- identitetsstöld: om användaren anger konfidentiell information som kreditkortsnummer på en komprometterad webbplats kan dessa uppgifter stulas med skadlig JavaScript.
- Denial of service attacker och webbplats vandalism.
- stöld av känsliga data, som lösenord.
- finansiella bedrägerier på bank webbplatser.
skriptskydd över flera platser
Escape dynamiskt innehåll
vanligtvis, när en webbsida återges, vävs dynamiskt innehåll in i HTML. Om det dynamiska innehållet behandlas felaktigt kan en angripare använda det för att konstruera en lagrad XSS-attack. Angriparen skulle missbruka ett redigerbart fält genom att infoga någon skadlig JavaScript-kod, som utvärderas i webbläsaren när en annan användare besöker den sidan.
du kanske inte vill att dina användare ska skapa rå HTML om inte din webbplats är ett innehållshanteringssystem. Undvik allt dynamiskt innehåll som kommer från ett datalager, så webbläsaren vet att det ska behandlas som innehållet i HTML-taggar, i motsats till rå HTML.
Escaping dynamiskt innehåll består i allmänhet av att ersätta signifikanta tecken med HTML-entitetskodningen:
” "
# #
& &
’ '
( (
) )
/ /
; ;
< <
> >
som du kommer att se i kodexemplen nedan kommer de flesta moderna ramar att undvika dynamiskt innehåll som standard.
genom att undkomma redigerbart innehåll på detta sätt kommer innehållet aldrig att behandlas som körbar kod av webbläsaren. Detta kommer att förhindra de flesta XSS-attacker.
vitlista värden
om ett dynamiskt dataobjekt bara kan ta en handfull giltiga värden begränsar du värdena i datalagret. Se också till att din renderingslogik endast tillåter kända, korrekta värden.
ett exempel där du kanske vill använda den här metoden är att be en användare att välja sitt land från en rullgardinslista, istället för att få dem att skriva in det manuellt.
implementera en innehållssäkerhetspolicy
moderna webbläsare stöder Innehållssäkerhetspolicyer. Innehållssäkerhetspolicyer tillåter författaren till en webbsida att styra var JavaScript och andra resurser kan laddas och köras från.
för att en XSS – attack ska vara möjlig måste angriparen kunna köra skadliga skript på en användares webbsida-antingen genom att injicera inline < script>taggar någonstans inom taggen < html> på en sida eller genom att lura webbläsaren att ladda JavaScript från en skadlig tredjepartsdomän.
om du ställer in en innehållssäkerhetspolicy i svarshuvudet kan du berätta för webbläsaren att aldrig köra inline JavaScript och välja de domäner som kan vara värd för JavaScript för en sida:
Content-Security-Policy: script-src 'self' https://apis.google.com
genom att vitlista webbadresserna från vilka skript kan laddas anger du implicit att inline JavaScript inte är tillåtet.
du kan också placera innehållssäkerhetsprincipen i en <meta> – tagg i elementet <head> på en sida:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
detta tillvägagångssätt är mycket effektivt för att skydda dina användare, men kräver disciplin för att göra din webbplats redo för en sådan rubrik. Även om inline-skript anses vara en dålig praxis i modern webbutveckling, är de vanliga på äldre, äldre webbplatser.
för att migrera bort från inline-skript stegvis, överväga att använda CSP-Överträdelserapporter. Genom att lägga till ett report-uri-direktiv i ditt policyhuvud kommer webbläsaren att meddela dig om eventuella policyöverträdelser, snarare än att förhindra inline JavaScript från att köras:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
detta kommer att ge dig försäkran om att det inte finns några kvardröjande inline skript, innan du förbjuda dem direkt.
Sanitize HTML
för vissa webbplatser finns det ett legitimt behov av att lagra och rendera raw HTML. Om din webbplats lagrar och återger rikt innehåll måste du använda ett HTML – saneringsbibliotek för att säkerställa att skadliga användare inte kan injicera skript i sina HTML-inlämningar.
http-endast Cookies
skadligt JavaScript kan användas för att stjäla en cookie som innehåller användarens sessions-ID. Det finns sällan en bra anledning att läsa eller manipulera cookies i JavaScript på klientsidan, så överväga att markera cookies som HTTP-only, vilket innebär att cookies kommer att tas emot, lagras och skickas av webbläsaren, men kan inte ändras eller läsas av JavaScript.
XSS-förebyggande med kodexempel
cross-site scripting prevention i Python (Django)
mallar i Django escape HTML som standard, så allt som ser ut som följande är generellt säkert:
**{{ contents }}**
du kan åsidosätta escape genom att använda / safe-filtret. Det finns ofta goda skäl att göra detta, men du måste göra kodrecensioner på allt som använder det här kommandot:
**{{ contents | safe }}**
Observera att HTML-escaping också kan slås på eller av med taggen {% autoescape %}.
Cross-site scripting prevention i Ruby (Rails)
Rails mallar Fly HTML som standard, så allt som ser ut som följande är i allmänhet säker:
<%= contents %>
du kan åsidosätta escape genom att använda raw-funktionen eller använda <%== – operatören. Det finns ofta goda skäl att göra detta, men du måste göra kodrecensioner på allt som använder dessa funktioner:
<% raw contents %>
<%== contents %>
skriptförhindrande över flera platser i Java (Java Server Pages)
använd taggen c:out för att på ett säkert sätt undkomma HTML:
<c:out value="${contents}">
följande sätt att skriva till en mall undviker inte HTML, så du bör använda dem med försiktighet:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Cross-site scripting förebyggande i C #(ASP.NET)
använd någon av följande funktioner för att säkert undkomma HTML (formuläret <%: introducerades i ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
följande sätt att skriva till en mall undviker inte HTML automatiskt, så du bör använda dem med försiktighet:
<%= contents %>
använd HttpUtility.HtmlEncode(...) om du behöver manuellt Fly HTML.
cross-site scripting förebyggande i Nod
mustasch.js
i Mustasch.js, alla taggar i dubbla mustascher automatiskt Fly HTML:
{{ contents }}
Tänk på att taggar i triple mustaches inte undviker HTML, så använd dem med försiktighet:
{{{ contents }}}
damm.js
Nyckel taggar automatiskt Fly HTML:
{ contents }
escaping kan dock inaktiveras med operatören |s, så använd detta med försiktighet
{ contents | s }
Nunjucks
om automatisk flykt är påslagen i miljön kommer Nunjucks automatiskt att fly från taggar för säker utmatning:
{{ contents }}
innehåll som är markerat med safe-filtret kommer inte att undkomma – använd den här funktionen med försiktighet:
{{ contents | safe }}
Auto-escaping kan inaktiveras för en mall, i vilket fall taggar måste rymmas manuellt:
{{ contents | escape }}
Cross-site scripting prevention i PHP
echo-kommandot i PHP undviker inte HTML som standard, vilket innebär att någon kod som följande som drar data direkt ur HTTP-begäran, är sårbar för XSS-attacker:
<?php
Echo $_POST;
?>
Cross-site scripting prevention i AngularJS
Allt innehåll som skrivs ut i lockiga parenteser kommer automatiskt att släppas, så Följande är säkert:
<div>{{dynamicContent}}</div>
Tänk på att någon kod som binder dynamiskt innehåll till innerHTML-attributet inte automatiskt kommer att släppas:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
cross-site scripting prevention i React
allt dynamiskt innehåll som skrivs ut i lockiga parenteser kommer automatiskt att släppas i React, så följande kod är säker:
render() {
return <div>{dynamicContent}</div>
}
du kan också skriva ut raw HTML genom att binda innehåll till egenskapen dangerouslySetInnerHTML. Namnet är inte en slump, så se upp för någon kod som ser ut som följande:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
hur kan automatiserade verktyg hjälpa till att förhindra cross-site scripting?
som nämnts ovan kan det vara enkelt att förhindra serveröverskridande skriptattacker, med många ramar som släpper ut dynamiskt innehåll som standard. Men den bekvämligheten kan leda till oavsiktlig och några allvarliga säkerhetsbrister för din ansökan och ditt företag.
se alltid till att du skannar dina program för sårbarheter innan du släpper dem till produktion, helst som en del av dina DevOps-och CI/CD-rörledningar för att upptäcka och åtgärda säkerhetsproblem tidigt, på varje build / commit.
du kan börja automatisera din säkerhetstestning idag med Neuralegions dynamiska Applikationssäkerhetstestskanner, Nexploit. Byggd för utvecklare och utan falska positiva, kan du integrera den i dina rörledningar för att flytta säkerhetstester åt vänster och vara säker genom design.
registrera dig för ditt gratis konto här: https://nexploit.app/signup