mitä on Cross-Site Scripting Prevention?
Cross-site scripting prevention on prosessi, jossa XSS-haavoittuvuudet havaitaan ja korjataan verkkosivustoilla tai verkkosovelluksissa ennen kuin ne osuvat tuotantoon. XSS-haavoittuvuuksien havaitseminen voidaan tehdä automaattisesti automaattisella haavoittuvuuden skannerilla tai manuaalisesti penetraatiotesteillä. Tässä artikkelissa opit parhaat käytännöt cross-site scripting ehkäisy ja miten voit toteuttaa ne välittömästi. Artikkelin lopusta löytyy myös linkki ilmaiseen, kehittäjäpainotteiseen haavoittuvuuden skanneriin, jotta voit alkaa havaita ja korjata sivuston rajat ylittäviä skriptaushaavoittuvuuksia varhaisessa vaiheessa ja usein osana kehitysputkia
tässä artikkelissa opit:
- mikä on Cross-Site Scripting ehkäisy?
- miten cross-site scripting toimii?
- mitkä ovat XSS-hyökkäysten tyypit?
- kuinka tärkeää on alueiden välisen skriptauksen ehkäisy?
- Cross site scripting protection
- Escape dynamic content
- Whitelist-arvot
- Implement a content-security policy
- Sanitize HTML
- HTTP – vain evästeet
- XSS Prevention with code examples
- Cross-site scripting prevention in Python (Django)
- Cross-site scripting prevention in Ruby (Rails)
- Cross-site scripting prevention in Java (Java Server Pages)
- Cross-site scripting prevention in C# (ASP.NET)
- Cross-site scripting prevention in Node
- viikset.js
- Dust.js
- Nunjucks
- Cross-site scripting prevention in PHP
- Cross-site scripting prevention in AngularJS
- Cross-site scripting prevention in React
- miten automatisoidut työkalut voivat estää sivuston rajat ylittävän skriptauksen?
miten cross-site scripting toimii?
Cross-Site Scripting (XSS) – hyökkäykset ovat pistoshyökkäyksen muoto, jossa luotettuihin verkkosovelluksiin ruiskutetaan haitallisia skriptejä.
hyökkääjä voi verkkosovelluksen avulla lähettää haitallisen koodin, tyypillisesti selainpuoleisen skriptin muodossa, toiselle loppukäyttäjälle, mikä johtaa XSS-hyökkäykseen.
XSS-haavoittuvuudet ovat hyvin yleisiä, ja niitä esiintyy silloin, kun verkkosovellus käyttää luodussa tuotoksessa olevan kelvollisen käyttäjän syötteitä, mutta ilman asianmukaista validointia tai koodausta.
käyttäjälle lähetetyn haitallisen komentosarjan myötä hänen selaimensa ei voi kategorisesti tietää, että komentosarjaan ei pitäisi luottaa,ja suorittaa sen myöhemmin. Tämä skripti voi sitten käyttää lukuisia tietoja, mukaan lukien kaikki evästeet, istuntosalakkeet tai muut arkaluonteiset tiedot, jotka selain voi säilyttää kyseiselle sivustolle.
mitkä ovat XSS-hyökkäysten tyypit?
XSS-hyökkäyksiä on kolmea päätyyppiä:
- heijastunut XSS: haitallinen skripti tulee nykyisestä HTTP-pyynnöstä
- tallennetusta XSS: stä: haitallinen skripti tulee sivuston tietokannasta
- DOM-pohjainen XSS: jossa haavoittuvuus on asiakaspuolen koodissa eikä palvelinpuolen koodissa.
kuinka tärkeää on alueiden välisen skriptauksen ehkäisy?
XSS-haavoittuvuuden hyödyntämisestä aiheutuva vahinko riippuu sivustosi käsittelemien tietojen herkkyydestä. Tässä muutamia esimerkkejä, joissa hakkerit hyödyntää XSS haavoittuvia sovelluksia:
- levittää matoja sosiaalisessa mediassa: Facebook, Twitter ja YouTube ovat kaikki onnistuneet hyökkäämään tällä tavalla.
- Sessiokaappaus: Haitallinen JavaScript saattaa pystyä lähettämään istuntotunnuksen hakkerin hallitsemalle etäsivustolle, jolloin hakkeri voi esiintyä kyseisenä käyttäjänä kaappaamalla käynnissä olevan istunnon.
- identiteettivarkaus: jos käyttäjä syöttää luottamuksellisia tietoja, kuten luottokorttinumeroita, vaarantuneelle verkkosivustolle, nämä tiedot voidaan varastaa haitallisen JavaScriptin avulla.
- palvelunestohyökkäykset ja verkkosivujen ilkivalta.
- arkaluonteisten tietojen, kuten salasanojen, varastaminen.
- Pankkisivustoilla tehdyt Rahoituspetokset.
cross-site scripting protection
Escape dynamic content
yleensä verkkosivun renderöinnin yhteydessä dynaaminen sisältö kudotaan HTML-muotoon. Jos dynaamista sisältöä käsitellään väärin, hyökkääjä voi käyttää sitä rakentaakseen tallennetun XSS-hyökkäyksen. Hyökkääjä käyttäisi väärin muokattavaa kenttää lisäämällä siihen haitallisen JavaScript-koodin, joka arvioidaan selaimessa, kun toinen käyttäjä vierailee kyseisellä sivulla.
et välttämättä halua käyttäjiesi kirjoittavan raw HTML: ää, ellei sivustosi ole sisällönhallintajärjestelmä. Paeta kaikki dynaaminen sisältö tulee tietovarastosta, joten selain tietää, että se on käsiteltävä sisällöksi HTML tageja, toisin kuin raaka HTML.
dynaamisen sisällön pakeneminen tarkoittaa yleensä merkittävien merkkien korvaamista HTML-entiteettikoodauksella:
” "
# #
& &
’ '
( (
) )
/ /
; ;
< <
> >
kuten näet alla olevista koodinäytteistä, useimmat nykyaikaiset kehykset pakenevat dynaamista sisältöä oletusarvoisesti.
pakenemalla muokattavaa sisältöä tällä tavalla selain ei koskaan käsittele sisältöä suoritettavana koodina. Tämä estää useimmat XSS-hyökkäykset.
Whitelist-arvot
jos dynaaminen tietoerä voi ottaa vain kourallisen kelvollisia arvoja, Rajoita tietovaraston arvoja. Varmista myös, että käännöslogiikkasi sallii vain tunnetut, oikeat arvot.
esimerkki, jossa voit käyttää tätä lähestymistapaa, on pyytää käyttäjää valitsemaan maansa pudotusvalikosta sen sijaan, että hän kirjoittaisi sen manuaalisesti.
Implement a content-security policy
nykyaikaiset selaimet tukevat Content-Security Policya. Sisältö-suojauskäytäntöjen avulla web-sivun kirjoittaja voi hallita, mistä JavaScript ja muut resurssit voidaan ladata ja suorittaa.
jotta XSS-hyökkäys olisi mahdollinen, hyökkääjän on kyettävä suorittamaan haitallisia skriptejä käyttäjän www – sivulla-joko pistämällä inline <script> tageja jonnekin <html> – sivun tagiin tai huijaamalla selain lataamaan JavaScript haitallisesta kolmannen osapuolen verkkotunnuksesta.
sisällön suojauskäytännön asettaminen vastaus-otsakkeessa antaa sinulle mahdollisuuden kertoa selaimelle, ettei se koskaan suorita inline JavaScriptiä, ja valita verkkotunnukset, jotka voivat isännöidä JavaScriptiä sivulle:
Content-Security-Policy: script-src 'self' https://apis.google.com
asettamalla URL-osoitteet, joista skriptit voidaan ladata, ilmoitat epäsuorasti, että Inline JavaScript ei ole sallittua.
voit myös sijoittaa sisällön suojauskäytännön <meta> tagiin <head> sivun elementtiin:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
tämä lähestymistapa on erittäin tehokas suojaamaan käyttäjiä, mutta vaatii kurinalaisuutta, jotta sivustosi on valmis tällaiseen otsikkoon. Vaikka inline-skriptejä pidetään huonona käytäntönä nykyaikaisessa web-kehityksessä, ne ovat yleisiä vanhemmissa, perinteikkäissä sivustoissa.
siirtyäksesi pois inline-skripteistä vähitellen, harkitse CSP: n Rikkomusraporttien käyttöä. Lisäämällä raportin-uri-direktiivi politiikan otsikkoon selain ilmoittaa sinulle mahdollisista käytäntörikkomuksista sen sijaan, että estäisi Inline JavaScriptin suorittamisen:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
tämä antaa sinulle varmuuden siitä, että ei ole viipyvä inline skriptejä, ennen kuin kiellät ne suoraan.
Puhdista HTML
joillakin sivustoilla on oikeutettu tarve tallentaa ja tehdä raakaa HTML: ää. Jos sivustosi tallentaa ja tekee runsaasti sisältöä, sinun täytyy käyttää HTML sanitization-kirjastoa varmistaakseen, että haitalliset käyttäjät eivät voi pistää skriptejä HTML-lähetyksiinsä.
HTTP-vain evästeet
haitallista JavaScriptiä voi käyttää käyttäjän istuntotunnuksen sisältävän evästeen varastamiseen. On harvoin hyvä syy lukea tai manipuloida evästeitä client-side Javascriptissä, joten harkitse evästeiden merkitsemistä HTTP-vain, mikä tarkoittaa, että selain Vastaanottaa, tallentaa ja lähettää evästeet, mutta JavaScript ei voi muokata tai lukea niitä.
XSS Prevention with code examples
Cross-site scripting prevention in Python (Django)
Templates in Django escape HTML by default, joten kaikki, mikä näyttää seuraavilta, on yleensä turvallista:
**{{ contents }}**
voit ohittaa escapen käyttämällä / safe-suodatinta. On usein hyviä syitä tehdä tämä, mutta sinun täytyy tehdä koodin arvostelua mitään, joka käyttää tätä komentoa:
**{{ contents | safe }}**
huomaa, että HTML-pakeneminen voidaan myös kytkeä päälle tai pois päältä {% autoescape %} – tagilla.
Cross-site scripting prevention in Ruby (Rails)
Rails-mallit pakenevat HTML-protokollaa oletuksena, joten kaikki, mikä näyttää seuraavalta, on yleensä turvallista:
<%= contents %>
voit ohittaa escapen käyttämällä raw-toimintoa tai käyttämällä <%== – operaattoria. On usein hyviä syitä tehdä tämä, mutta sinun täytyy tehdä koodin arvostelua mitään, joka käyttää näitä toimintoja:
<% raw contents %>
<%== contents %>
Cross-site scripting prevention in Java (Java Server Pages)
käytä c:out tagia poistuaksesi turvallisesti HTML: stä:
<c:out value="${contents}">
seuraavat kirjoitustavat malliin eivät karkaa HTML: ltä, joten niitä kannattaa käyttää varoen:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Cross-site scripting prevention in C# (ASP.NET)
käytä jompaakumpaa seuraavista funktioista poistuaksesi turvallisesti HTML: stä (<%: muoto otettiin käyttöön ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
seuraava tapa kirjoittaa malliin ei karkaa HTML automaattisesti, joten käytä niitä varoen:
<%= contents %>
käytä HttpUtility.HtmlEncode(...) jos haluat paeta HTML-koodia manuaalisesti.
Cross-site scripting prevention in Node
viikset.js
viiksissä.js, kaikki tunnisteet kaksinkertainen viikset automaattisesti paeta HTML:
{{ contents }}
muista, että tunnisteet kolminkertainen viikset eivät paeta HTML, joten käytä niitä varoen:
{{{ contents }}}
pölyä.JS
Avaintagit poistuvat automaattisesti HTML: stä:
{ contents }
pakeneminen voidaan kuitenkin estää |s – operaattorin avulla, joten käytä tätä varoen
{ contents | s }
Nunjucks
Jos automaattinen pakeneminen on päällä ympäristössä, Nunjucks karkaa automaattisesti tageista turvallisen ulostulon vuoksi:
{{ contents }}
turvasuodattimella merkitty sisältö ei karkaa-käytä tätä toimintoa varoen:
{{ contents | safe }}
automaattinen pakeneminen voidaan poistaa käytöstä mallin osalta, jolloin tunnisteet on paettava manuaalisesti:
{{ contents | escape }}
Cross-site scripting prevention in PHP
Echo-komento PHP: ssä ei poistu HTML-komennosta oletuksena, mikä tarkoittaa, että mikä tahansa seuraavan kaltainen koodi, joka vetää dataa suoraan HTTP-pyynnöstä, on altis XSS-hyökkäyksille:
<?php
Echo $_POST;
?>
Cross-site scripting prevention in AngularJS
kaikki kiharasulkuihin kirjoitettu sisältö poistuu automaattisesti, joten seuraava on turvallinen:
<div>{{dynamicContent}}</div>
muista, että mikä tahansa koodi, joka sitoo dynaamisen sisällön innerHTML-attribuuttiin, ei karkaa automaattisesti:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Cross-site scripting prevention in React
kaikki kihara suluissa kirjoitettu dynaaminen sisältö poistuu automaattisesti Reactissa, joten seuraava koodi on turvallinen:
render() {
return <div>{dynamicContent}</div>
}
voit myös kirjoittaa raw HTML sitomalla sisältöä dangerouslySetInnerHTML ominaisuus. Nimi ei ole sattumaa, joten varokaa mitä tahansa koodia, joka näyttää seuraavilta:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
miten automatisoidut työkalut voivat estää sivuston rajat ylittävän skriptauksen?
kuten edellä mainittiin, sivustojen välisten skriptaushyökkäysten estäminen voi olla helppoa, jolloin monet kehykset pakenevat dynaamista sisältöä oletusarvoisesti. Mutta tämä mukavuus voi johtaa tahattomuuteen ja joihinkin vakaviin tietoturvaheikkouksiin hakemuksessasi ja liiketoiminnassasi.
Varmista aina, että skannaat sovelluksesi haavoittuvuuksien varalta ennen niiden julkaisemista tuotantoon, mieluiten osana DevOps-ja CI/CD-putkistoja, jotta tietoturvahaavoittuvuudet voidaan havaita ja korjata varhaisessa vaiheessa jokaisen build / commit-toiminnon yhteydessä.
voit aloittaa tietoturvatestauksen automatisoinnin tänään Neuralegionin dynaamisella sovelluksen Tietoturvatestauskannerilla, Nexploitilla. Rakennettu kehittäjille ja ilman vääriä positiivisia, voit integroida sen putkistoihin siirtää tietoturvatestausta vasemmalle ja olla turvallinen design.
Kirjaudu ilmaiselle tilillesi tästä: https://nexploit.app/signup