czym jest Cross-Site Scripting Prevention?
Cross-Site scripting prevention to proces wykrywania i usuwania luk w zabezpieczeniach XSS w witrynach lub aplikacjach internetowych, zanim trafią one do produkcji. Wykrywanie luk w zabezpieczeniach XSS można wykonać automatycznie, za pomocą automatycznego skanera luk lub ręcznie, wykonując testy penetracyjne. W tym artykule dowiesz się najlepszych praktyk zapobiegania skryptom między witrynami i jak możesz je natychmiast wdrożyć. Na końcu artykułu znajdziesz również link do bezpłatnego skanera luk skoncentrowanego na programistach, dzięki czemu możesz wcześnie zacząć wykrywać i usuwać luki w zabezpieczeniach w skryptach między witrynami i często, w ramach potoków rozwoju
w tym artykule dowiesz się, jak szybko i skutecznie wykrywać luki w zabezpieczeniach:
- czym jest Cross-Site Scripting Prevention?
- jak działa cross-Site scripting?
- jakie są rodzaje ataków XSS?
- jak ważna jest profilaktyka Cross-site scripting?
- Ochrona przed skryptami krzyżowymi
- Ucieczka dynamicznej zawartości
- wartości białej listy
- wdrożenie polityki bezpieczeństwa treści
- dezynfekcja HTML
- Pliki cookie tylko dla HTTP
- zapobieganie XSS z przykładami kodu
- zapobieganie krzyżowym skryptom w Pythonie (Django)
- zapobieganie krzyżowym skryptom w Ruby (Rails)
- zapobieganie krzyżowym skryptom w Javie (Java Server Pages)
- zapobieganie krzyżowym skryptom w C# (ASP.NET)
- Cross-Site Scripting prevention in Node
- .js
- pył.js
- Nunjucks
- Cross-Site Scripting prevention in PHP
- Cross-Site scripting prevention in AngularJS
- Cross-Site scripting prevention in React
- w jaki sposób zautomatyzowane narzędzia mogą zapobiegać skryptom między witrynami?
jak działa cross-Site scripting?
ataki Cross-Site Scripting (XSS) są formą ataku injection, w którym złośliwe skrypty są wstrzykiwane do zaufanych aplikacji internetowych.
atakujący może użyć aplikacji internetowej do wysłania złośliwego kodu, zwykle w postaci skryptu po stronie przeglądarki, do innego użytkownika końcowego, co skutkuje atakiem XSS.
luki w zabezpieczeniach XSS są bardzo powszechne, występujące, gdy aplikacja internetowa używa danych wejściowych od ważnego użytkownika zawartych w wygenerowanym wyjściu, ale bez odpowiedniej walidacji lub kodowania.
dzięki złośliwemu skryptowi wysłanemu do Użytkownika, jego przeglądarka nie jest w stanie kategorycznie wiedzieć, że skrypt nie powinien być zaufany, a następnie wykonuje skrypt. Ten skrypt może następnie uzyskać dostęp do wielu danych, w tym Plików cookie, tokenów sesji lub innych poufnych informacji, które mogą być przechowywane przez przeglądarkę dla tej witryny.
jakie są rodzaje ataków XSS?
istnieją trzy główne typy ataków XSS:
- odbicie XSS: złośliwy skrypt pochodzi z bieżącego żądania HTTP
- zapisanego XSS: złośliwy skrypt pochodzi z bazy danych witryny
- bazującej na DOM XSS: gdzie luka występuje w kodzie po stronie klienta, a nie w kodzie po stronie serwera.
jak ważna jest profilaktyka Cross-site scripting?
uszkodzenia wynikające z wykorzystania luki XSS zależą od wrażliwości danych obsługiwanych przez witrynę. Oto kilka przykładów, w których hakerzy wykorzystywali wrażliwe aplikacje XSS:
- rozprzestrzenianie robaków w mediach społecznościowych: Facebook, Twitter i YouTube zostały skutecznie zaatakowane w ten sposób.
- porwanie sesji: Złośliwy JavaScript może wysyłać identyfikator sesji do zdalnej witryny pod kontrolą hakera, co pozwala hakerowi podszywać się pod tego użytkownika, przejmując trwającą sesję.
- kradzież tożsamości: jeśli użytkownik wprowadzi poufne informacje, takie jak numery kart kredytowych, do naruszonej witryny, dane te mogą zostać skradzione za pomocą złośliwego JavaScript.
- ataki typu odmowa usługi i wandalizm witryny.
- kradzież wrażliwych danych, takich jak hasła.
- oszustwa finansowe na stronach bankowych.
Cross-Site Scripting protection
Escape dynamic content
zwykle, gdy strona internetowa jest renderowana, dynamiczna zawartość jest wpleciona w HTML. Jeśli zawartość dynamiczna jest niewłaściwie traktowana, atakujący może użyć jej do skonstruowania przechowywanego ataku XSS. Atakujący nadużywa edytowalnego pola, wstawiając złośliwy kod JavaScript, który jest oceniany w przeglądarce, gdy inny użytkownik odwiedza tę stronę.
możesz nie chcieć, aby użytkownicy tworzyli surowy HTML, chyba że Twoja strona jest systemem zarządzania treścią. Unikaj wszystkich dynamicznych treści pochodzących ze sklepu danych, aby przeglądarka wiedziała, że ma być traktowana jako zawartość znaczników HTML, w przeciwieństwie do surowego HTML.
unikanie zawartości dynamicznej zazwyczaj polega na zastąpieniu znaczących znaków kodowaniem encji HTML:
” "
# #
& &
’ '
( (
) )
/ /
; ;
< <
> >
jak widać w przykładach kodu poniżej, większość nowoczesnych frameworków domyślnie ucieka od zawartości dynamicznej.
unikając edytowalnej zawartości w ten sposób, zawartość nigdy nie będzie traktowana jako kod wykonywalny przez przeglądarkę. Zapobiegnie to większości ataków XSS.
Biała Lista wartości
jeśli dynamiczna pozycja danych może przyjmować tylko kilka prawidłowych wartości, ogranicz wartości w magazynie danych. Upewnij się też, że logika renderowania zezwala tylko na znane, właściwe wartości.
przykładem, w którym możesz chcieć użyć tego podejścia, jest poproszenie użytkownika o wybranie kraju z listy rozwijanej, zamiast ręcznego wpisywania go.
zaimplementuj politykę bezpieczeństwa treści
nowoczesne przeglądarki obsługują zasady bezpieczeństwa treści. Zasady bezpieczeństwa treści pozwalają autorowi strony internetowej kontrolować, skąd JavaScript i inne zasoby mogą być ładowane i uruchamiane.
aby atak XSS był możliwy, atakujący musi być w stanie uruchomić złośliwe skrypty na stronie internetowej użytkownika – albo przez wstrzyknięcie inline <script> tagów gdzieś w znaczniku <html> strony, lub przez oszukanie przeglądarki, aby załadowała JavaScript ze szkodliwej domeny innej firmy.
ustawienie zasad bezpieczeństwa treści w nagłówku odpowiedzi pozwoli Ci powiedzieć przeglądarce, aby nigdy nie uruchamiała wbudowanego JavaScript i wybrać domeny, które mogą obsługiwać JavaScript dla strony:
Content-Security-Policy: script-src 'self' https://apis.google.com
umieszczając na białej liście adresy URL, z których można ładować Skrypty, domyślnie stwierdzasz, że Inline JavaScript nie jest dozwolony.
możesz również umieścić politykę bezpieczeństwa treści w znaczniku <meta> w elemencie <head> strony:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
takie podejście jest bardzo skuteczne w ochronie użytkowników, ale wymaga dyscypliny, aby Twoja strona była gotowa na taki nagłówek. Chociaż Skrypty wbudowane są uważane za złą praktykę we współczesnym tworzeniu stron internetowych, są one powszechne w starszych, starszych witrynach.
aby stopniowo oddalać się od skryptów wbudowanych, rozważ użycie raportów o naruszeniach CSP. Dodając dyrektywę report-uri w nagłówku zasad, przeglądarka powiadomi Cię o wszelkich naruszeniach zasad, zamiast uniemożliwiać uruchamianie wbudowanego JavaScript:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
to da ci pewność, że nie ma żadnych utrzymujących się skryptów wbudowanych, zanim od razu je zbanujesz.
dezynfekuj HTML
w przypadku niektórych witryn istnieje uzasadniona potrzeba przechowywania i renderowania surowego HTML. Jeśli witryna przechowuje i renderuje treści bogate, należy użyć biblioteki dezynfekcji HTML, aby złośliwi użytkownicy nie mogli wstrzykiwać skryptów w przesyłanych plikach HTML.
Pliki cookie tylko dla HTTP
złośliwy JavaScript może zostać użyty do kradzieży pliku cookie zawierającego identyfikator sesji użytkownika. Rzadko istnieje dobry powód, aby czytać lub manipulować Plikami cookie w JavaScript po stronie klienta, więc rozważ oznaczenie plików cookie jako tylko HTTP, co oznacza, że pliki cookie będą odbierane, przechowywane i wysyłane przez przeglądarkę, ale nie mogą być modyfikowane ani odczytywane przez JavaScript.
zapobieganie XSS z przykładami kodu
zapobieganie Cross-Site scripting w Pythonie (Django)
szablony w Django domyślnie uciekają HTML, więc wszystko, co wygląda jak poniżej, jest ogólnie bezpieczne:
**{{ contents }}**
możesz nadpisać polecenie escape za pomocą filtra / safe. Często istnieją dobre powody, aby to zrobić, ale trzeba będzie przeprowadzić przegląd kodu na wszystko, co używa tego polecenia:
**{{ contents | safe }}**
zauważ, że HTML-escaping może być również włączony lub wyłączony za pomocą znacznika {% autoescape %}.
Cross-Site scripting prevention in Ruby (Rails)
szablony Rails domyślnie uciekają od HTML, więc wszystko, co wygląda jak poniżej, jest ogólnie bezpieczne:
<%= contents %>
możesz nadpisać polecenie escape za pomocą funkcji raw lub operatora <%==. Często istnieją dobre powody, aby to zrobić, ale będziesz musiał przeprowadzić recenzje kodu na temat wszystkiego, co korzysta z tych funkcji:
<% raw contents %>
<%== contents %>
Cross-Site Scripting prevention in Java (Java Server Pages)
użyj znacznika c:out, aby bezpiecznie uciec od HTML:
<c:out value="${contents}">
następujące sposoby pisania do szablonu nie wymykają się HTML – owi, więc powinieneś z nich korzystać ostrożnie:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Cross-Site scripting prevention in C# (ASP .NET)
użyj jednej z poniższych funkcji, aby bezpiecznie uciec od HTML (formularz <%: został wprowadzony w ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
poniższy sposób pisania do szablonu nie wymyka HTML automatycznie, więc należy z nich korzystać ostrożnie:
<%= contents %>
użyj HttpUtility.HtmlEncode(...), jeśli chcesz ręcznie uciec od HTML.
Cross-Site Scripting prevention in Node
.js
w wąsach.js, wszelkie tagi w podwójnych wąsach automatycznie uciekają od HTML:
{{ contents }}
pamiętaj, że tagi w triple mustaches nie uciekają przed HTML-em, więc używaj ich ostrożnie:
{{{ contents }}}
pył.js
znaczniki kluczy automatycznie usuwają HTML:
{ contents }
jednak ucieczkę można wyłączyć za pomocą operatora |s, więc używaj tego ostrożnie
{ contents | s }
Nunjucks
jeśli w środowisku jest włączona automatyczna Ucieczka, Nunjucks automatycznie usunie znaczniki dla bezpiecznego wyjścia:
{{ contents }}
zawartość oznaczona bezpiecznym filtrem nie zostanie usunięta – używaj tej funkcji ostrożnie:
{{ contents | safe }}
Automatyczna ucieczka może być wyłączona dla szablonu, w którym to przypadku znaczniki muszą być unikane ręcznie:
{{ contents | escape }}
Cross-Site Scripting prevention w PHP
polecenie echo w PHP domyślnie nie ucieka przed HTML, co oznacza, że każdy kod podobny do poniższego, który pobiera dane bezpośrednio z żądania HTTP, jest podatny na ataki XSS:
<?php
Echo $_POST;
?>
Cross-Site Scripting prevention in AngularJS
każda zawartość zapisana w nawiasach klamrowych zostanie automatycznie usunięta, więc następujące elementy są bezpieczne:
<div>{{dynamicContent}}</div>
należy pamiętać, że każdy kod wiążący zawartość dynamiczną z atrybutem innerHTML nie będzie automatycznie zabezpieczany:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
zapobieganie powstawaniu skryptów między witrynami w Reakcie
każda dynamiczna zawartość zapisana w nawiasach klamrowych zostanie automatycznie uniknięta w Reakcie, więc następujący kod jest bezpieczny:
render() {
return <div>{dynamicContent}</div>
}
można również wypisać surowy kod HTML poprzez powiązanie zawartości z właściwością dangerouslySetInnerHTML. Nazwa nie jest zbiegiem okoliczności, więc zwróć uwagę na dowolny kod, który wygląda następująco:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
w jaki sposób zautomatyzowane narzędzia mogą zapobiegać skryptom między witrynami?
jak wspomniano powyżej, zapobieganie atakom typu cross-site scripting może być łatwe, a wiele frameworków domyślnie ucieka z dynamicznej zawartości. Ale ta wygoda może prowadzić do nieumyślności i poważnych słabości bezpieczeństwa Twojej aplikacji i Twojej firmy.
zawsze upewnij się, że skanujesz aplikacje pod kątem luk w zabezpieczeniach przed ich wypuszczeniem do produkcji, najlepiej jako część potoków DevOps i CI/CD w celu wczesnego wykrywania i usuwania luk w zabezpieczeniach przy każdej kompilacji / zatwierdzeniu.
możesz rozpocząć automatyzację testów bezpieczeństwa już dziś za pomocą dynamicznego skanera Neuralegion do testowania bezpieczeństwa aplikacji, nexploit. Stworzony dla programistów i bez fałszywych alarmów, możesz zintegrować go z potokami, aby przesunąć testy bezpieczeństwa w lewo i być bezpiecznym od samego początku.
Załóż darmowe konto tutaj: https://nexploit.app/signup