mi a webhelyek közötti szkriptelés megelőzése?
a Cross-site scripting prevention a webhelyek vagy webes alkalmazások XSS biztonsági réseinek felderítése és kijavítása, mielőtt azok megjelennek. Az XSS sebezhetőségek észlelése automatikusan elvégezhető egy automatizált sebezhetőségi szkenner segítségével, vagy manuálisan behatolási tesztek végrehajtásával. Ebben a cikkben megismerheti a webhelyek közötti szkriptelés megelőzésének legjobb gyakorlatait, és azt, hogyan lehet ezeket azonnal végrehajtani. A cikk végén talál egy linket egy ingyenes, fejlesztőközpontú sebezhetőségi szkennerhez is, így korán és gyakran elkezdheti észlelni és orvosolni a webhelyek közötti szkriptelési sebezhetőségeket, a fejlesztési folyamat részeként
ebben a cikkben megtudhatja:
- mi a Cross-Site Scripting megelőzés?
- hogyan működik a cross-site scripting?
- melyek az XSS támadások típusai?
- mennyire fontos a Cross-site scripting megelőzés?
- Cross site scripting protection
- Escape dinamikus tartalom
- Whitelist értékek
- tartalombiztonsági politika végrehajtása
- HTML fertőtlenítése
- csak HTTP cookie-k
- XSS megelőzés kódpéldákkal
- Cross-site scripting megelőzés Pythonban (Django)
- Cross-site scripting megelőzés Rubyban (Rails)
- Cross-site scripting megelőzés Java-ban (Java Server Pages)
- Cross-site scripting megelőzés C# – ban (ASP.NET)
- Cross-site scripting megelőzés csomópont
- bajusz.js
- por.js
- Nunjucks
- Cross-site scripting megelőzés PHP-ben
- Cross-site scripting megelőzés AngularJS – ben
- Cross-site scripting megelőzés a React-ben
- hogyan segíthetnek az automatizált eszközök a webhelyek közötti szkriptek megelőzésében?
hogyan működik a cross-site scripting?
a Cross-Site Scripting (XSS) támadások az injekciós támadások egyik formája, ahol a rosszindulatú szkripteket megbízható webes alkalmazásokba injektálják.
a támadó a webalkalmazással rosszindulatú kódot küldhet, jellemzően böngészőoldali szkript formájában egy másik végfelhasználónak, ami XSS támadást eredményez.
az XSS sebezhetőségek nagyon gyakoriak, amikor egy webalkalmazás A generált kimeneten belüli érvényes felhasználó bemenetét használja, de a megfelelő érvényesítés vagy kódolás nélkül.
a Felhasználónak küldött rosszindulatú szkript segítségével a böngésző nem tudja kategorikusan tudni, hogy a szkriptet nem szabad megbízni, majd végrehajtja a szkriptet. Ez a parancsfájl ezután számos adathoz férhet hozzá, beleértve a cookie-kat, a munkamenet-tokeneket vagy bármely más érzékeny információt, amelyet az adott webhely böngészője megőrizhet.
melyek az XSS támadások típusai?
az XSS támadásoknak három fő típusa van:
- tükrözött XSS: a rosszindulatú szkript az aktuális HTTP kérésből származik
- tárolt XSS: a rosszindulatú szkript a webhely
- Dom-alapú XSS adatbázisából származik: ahol a biztonsági rés a kliens oldali kódban, nem pedig a szerver oldali kódban található.
mennyire fontos a Cross-site scripting megelőzés?
az XSS biztonsági rés kihasználásából származó kár a webhely által kezelt adatok érzékenységétől függ. Íme néhány példa, ahol a hackerek kihasználták az XSS sebezhető alkalmazásokat:
- férgek terjesztése a közösségi médiában: a Facebook, a Twitter és a YouTube mind sikeresen támadtak ilyen módon.
- ülés eltérítés: A rosszindulatú JavaScript képes lehet elküldeni a munkamenet-azonosítót egy távoli webhelyre a hacker ellenőrzése alatt, lehetővé téve a hacker számára, hogy megszemélyesítse ezt a felhasználót egy folyamatban lévő munkamenet eltérítésével.
- személyazonosság-lopás: ha a felhasználó bizalmas információkat, például hitelkártya-számokat ad meg egy kompromittált webhelyre, ezeket az adatokat rosszindulatú JavaScript segítségével ellophatják.
- szolgáltatásmegtagadási támadások és weboldal vandalizmus.
- érzékeny adatok, például jelszavak lopása.
- pénzügyi csalás banki oldalakon.
Cross-site scripting protection
Escape dinamikus tartalom
általában egy weboldal megjelenítésekor a dinamikus tartalom HTML-be van szőve. Ha a dinamikus tartalmat nem megfelelően kezelik, a támadó ezt felhasználhatja tárolt XSS támadás létrehozására. A támadó visszaélne egy szerkeszthető mezővel valamilyen rosszindulatú JavaScript-kód beillesztésével, amelyet a böngésző értékel, amikor egy másik felhasználó meglátogatja az oldalt.
előfordulhat, hogy nem szeretné, hogy a felhasználók nyers HTML-t készítsenek, kivéve, ha webhelye tartalomkezelő rendszer. Kerülje el az adattárból származó összes dinamikus tartalmat, így a böngésző tudja, hogy HTML-címkék tartalmaként kell kezelni, szemben a nyers HTML-vel.
a dinamikus tartalom kikerülése általában abból áll, hogy a jelentős karaktereket a HTML entitás kódolásával helyettesítik:
” "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
amint az alábbi kódmintákban látni fogja, a legtöbb modern keretrendszer alapértelmezés szerint elkerüli a dinamikus tartalmat.
a szerkeszthető tartalom ilyen módon történő kikerülésével a tartalmat a böngésző soha nem fogja végrehajtható kódként kezelni. Ez megakadályozza a legtöbb XSS támadást.
Engedélyezőlista értékek
ha egy dinamikus adatelem csak néhány érvényes értéket vehet fel, korlátozza az adattár értékeit. Győződjön meg arról is, hogy a renderelési logika csak ismert, megfelelő értékeket engedélyez.
egy példa, ahol érdemes használni ezt a megközelítést, ha megkéri a felhasználót, hogy válassza ki az országot egy legördülő listából,, ahelyett, hogy kézzel írja be.
tartalombiztonsági házirend végrehajtása
a Modern böngészők támogatják a tartalombiztonsági házirendeket. A tartalom-biztonsági házirendek lehetővé teszik, hogy a weboldal szerzője szabályozza, hogy a JavaScript és más erőforrások hol tölthetők be és hajthatók végre.
ahhoz, hogy egy XSS támadás lehetséges legyen, a támadónak képesnek kell lennie rosszindulatú szkriptek futtatására a felhasználó weboldalán – vagy inline < script>címkék befecskendezésével valahol az oldal < html> címkéjén belül, vagy a böngésző becsapásával, hogy betöltse a Javascriptet egy rosszindulatú harmadik fél domainjéből.
tartalombiztonsági házirend beállítása a válaszfejlécben lehetővé teszi, hogy megmondja a böngészőnek, hogy soha ne hajtson végre inline JavaScriptet, és válassza ki azokat a tartományokat, amelyek egy Oldalhoz Javascriptet tárolhatnak:
Content-Security-Policy: script-src 'self' https://apis.google.com
az URL-ek engedélyezőlistáján, ahonnan a szkriptek betölthetők, implicit módon kijelenti, hogy az inline JavaScript nem engedélyezett.
a tartalombiztonsági házirendet egy <meta> címkébe is elhelyezheti az oldal <head> elemében:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
ez a megközelítés nagyon hatékony a felhasználók védelmében, de fegyelmet igényel, hogy webhelye készen álljon egy ilyen fejlécre. Míg az inline szkriptek használata rossz gyakorlatnak számít a modern webfejlesztésben, a régebbi, örökölt webhelyeken gyakoriak.
az inline szkriptek fokozatos eltávolításához fontolja meg a CSP megsértési jelentések használatát. A jelentés-uri irányelv hozzáadásával a házirend fejlécébe, a böngésző értesíti Önt az irányelvek megsértéséről, ahelyett, hogy megakadályozná az inline JavaScript végrehajtását:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
ez megnyugtatja Önt, hogy nincsenek elhúzódó inline szkriptek, mielőtt egyenesen betiltaná őket.
HTML fertőtlenítése
egyes webhelyek esetében jogos igény van a nyers HTML tárolására és renderelésére. Ha a webhely gazdag tartalmat tárol és renderel, HTML-fertőtlenítő könyvtárat kell használnia annak biztosítására, hogy a rosszindulatú felhasználók ne fecskendezhessenek szkripteket HTML-beadványaikba.
csak HTTP-cookie-k
rosszindulatú JavaScript használható a felhasználó munkamenet-azonosítóját tartalmazó cookie ellopására. Ritkán van jó ok arra, hogy olvassa el vagy manipulálja a cookie-kat az ügyféloldali JavaScript – ben, ezért fontolja meg a cookie-k csak HTTP-ként való megjelölését, ami azt jelenti, hogy a cookie-kat a böngésző fogadja, tárolja és elküldi, de a JavaScript nem módosíthatja vagy olvashatja.
XSS megelőzés kód példákkal
Cross-site scripting megelőzés Python (Django)
sablonok Django escape HTML alapértelmezés szerint, így bármi, ami úgy néz ki, mint a következő általában biztonságos:
**{{ contents }}**
a | safe szűrő segítségével felülbírálhatja az escape funkciót. Ennek gyakran jó okai vannak, de kódvizsgálatokat kell végeznie bármiről, amely ezt a parancsot használja:
**{{ contents | safe }}**
vegye figyelembe, hogy a HTML-menekülés a {% autoescape %} címkével is be-vagy kikapcsolható.
Cross-site scripting prevention in Ruby (Rails)
a Rails sablonok alapértelmezés szerint kikerülnek a HTML-ből, így minden, ami a következőnek tűnik, általában biztonságos:
<%= contents %>
az escape felülbírálható a raw függvény vagy a <%== operátor használatával. Ennek gyakran jó okai vannak, de kódvizsgálatokat kell végeznie bármiről, amely ezeket a funkciókat használja:
<% raw contents %>
<%== contents %>
Cross-site scripting prevention Java-ban (Java Server Pages)
a c:out címke használatával biztonságosan elkerülheti a HTML-t:
<c:out value="${contents}">
a sablonba történő írás következő módjai nem kerülik el a HTML-t, ezért óvatosan kell használni őket:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Cross-site scripting megelőzés C# (ASP.NET)
használja a következő funkciók egyikét a HTML biztonságos elkerüléséhez (a <%: űrlapot a ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
a sablonba történő írás következő módja nem kerül el automatikusan a HTML-ből, ezért óvatosan kell használni őket:
<%= contents %>
használja a HttpUtility.HtmlEncode(...) parancsot, ha manuálisan kell kikerülnie a HTML-t.
Cross-site scripting megelőzés csomópont
bajusz.js
bajuszban.js, a dupla bajuszokban lévő címkék automatikusan elkerülik a HTML-t:
{{ contents }}
ne feledje, hogy a hármas bajusz címkéi nem kerülik el a HTML-t, ezért óvatosan használja őket:
{{{ contents }}}
por.js
a Kulcscímkék automatikusan kikerülnek a HTML-ből:
{ contents }
a menekülés azonban letiltható a |s operátorral, ezért óvatosan használja ezt
{ contents | s }
Nunjucks
ha az automatikus menekülés be van kapcsolva a környezetben, a nunjucks automatikusan elhagyja a címkéket a biztonságos kimenet érdekében:
{{ contents }}
a biztonságos szűrővel jelölt tartalom nem kerül ki – használja ezt a funkciót óvatosan:
{{ contents | safe }}
az automatikus menekülés letiltható egy sablonnál, ebben az esetben a címkéket manuálisan kell megszökni:
{{ contents | escape }}
Cross-site scripting prevention in PHP
a PHP echo parancsa alapértelmezés szerint nem kerülheti el a HTML-t, ami azt jelenti, hogy minden olyan kód, mint a következő, amely közvetlenül kihúzza az adatokat a HTTP kérésből, sebezhető az XSS támadásokkal szemben:
<?php
Echo $_POST;
?>
Cross-site scripting megelőzés AngularJS
Minden tartalom írt ki göndör zárójelben automatikusan megszökött, így a következő biztonságos:
<div>{{dynamicContent}}</div>
ne feledje, hogy minden olyan kód, amely a dinamikus tartalmat az innerHTML attribútumhoz köti, nem kerül automatikusan kikerülésre:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Cross-site scripting prevention in React
minden göndör zárójelben írt dinamikus tartalom automatikusan kikerül a React-ben, így a következő kód biztonságos:
render() {
return <div>{dynamicContent}</div>
}
a nyers HTML-t úgy is kiírhatja, hogy a tartalmat a dangerouslySetInnerHTML tulajdonsághoz köti. A név nem véletlen, ezért vigyázzon minden olyan kódra, amely a következőképpen néz ki:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
hogyan segíthetnek az automatizált eszközök a webhelyek közötti szkriptek megelőzésében?
mint fentebb említettük, a webhelyek közötti szkriptelési támadások megelőzése egyszerű lehet, sok keretrendszer alapértelmezés szerint elkerüli a dinamikus tartalmat. De ez a kényelem véletlenszerűséghez és komoly biztonsági gyengeségekhez vezethet az alkalmazás és a vállalkozás számára.
mindig győződjön meg róla, hogy átvizsgálja az alkalmazásokat a biztonsági résekre, mielőtt kiadná őket a gyártásba, ideális esetben a DevOps és a CI/CD csővezetékek részeként, hogy minden build / commit során korán észlelje és orvosolja a biztonsági réseket.
meg lehet kezdeni automatizálja a biztonsági tesztelés ma NeuraLegion dinamikus alkalmazás biztonsági tesztelés scanner, Nexploit. Beépített fejlesztők számára, és nem hamis pozitív, akkor integrálja azt a csővezetékek váltani biztonsági tesztelés balra, és biztonságos legyen a tervezés.
iratkozzon fel ingyenes fiókjára itt: https://nexploit.app/signup