Ochrona użytkowników przed atakami DOM XSS

Ochrona użytkowników przed atakami DOM XSS

Cross-Site scripting (XSS) jest jednym z najczęstszych ataków wayshackerów. Luki w zabezpieczeniach XSS pozwalają złośliwemu użytkownikowi wykryć dowolne fragmenty JavaScript, gdy inni użytkownicy odwiedzają Twoją witrynę.

XSS jest najczęstszą publicznie zgłaszaną luką w zabezpieczeniach i częścią zestawu narzędzi każdego hakera.

częstość występowania rzadko

łatwość wykorzystania

wpływ szkodliwy

ataki XSS oparte na DOM mają wszystkie zagrożenia związane zinnymi typami ataków XSS, z tym, że są one niemożliwe do wykrycia po stronie serwera.Każda strona, która używa fragmentów URI, jest potencjalnie zagrożona atakami XSS.

Ochrona

Ochrona przed atakami XSS bazującymi na DOM polega na sprawdzeniu, czy twój JavaScript nie interpretuje fragmentów URI w niebezpieczny sposób. Istnieje wiele sposobów, aby to zapewnić.

użyj frameworka JavaScript

frameworki takie jak AngularJS i React używają szablonów, które sprawiają, że budowa ad-hoc HTML jest jawną (i rzadką) akcją. To zmusi zespół programistów do najlepszych praktyk i ułatwi wykrywanie niebezpiecznych operacji.

AngularJS

w Angular Dowolna dynamiczna zawartość zapisana w nawiasach klamrowych automatycznie zostanie usunięta, więc poniższe są bezpieczne:

 <div>{{dynamicContent}}</div>

należy uważać na każdy kod, który wiąże zawartość dynamiczną z atrybutami innerHTML, ponieważ nie zostanie automatycznie:

 <div ="dynamicContent"></div> <div innerHTML="{{dynamicContent}}"></div>
React

w Reaccie każda dynamiczna zawartość zapisana w nawiasach klamrowych automatycznie zostanie uniknięta, więc następujące elementy są bezpieczne:

render() { return <div>{dynamicContent}</div>}

React pozwala na zapisanie surowego kodu HTML poprzez powiązanie zawartości z właściwością dangerouslySetInnerHTML, która ma przypominać o ryzyku bezpieczeństwa! Uważaj na dowolny kod, który wygląda następująco:

render() { return <div dangerouslySetInnerHTML={ __html: dynamicContent } />}
dokładnie skontroluj swój kod

czasami pełny framework JavaScript jest zbyt ciężki dla Twojego site.In w takim przypadku będziesz musiał regularnie przeprowadzać przeglądy Kodeksu, aby wykryć lokalizacje, które odnoszą się do window.location.hash. Rozważ opracowanie uzgodnionych standardów kodowania w jaki sposób fragmenty URI mają być pisane i interpretowane, i scentralizuj tę logikę w podstawowej bibliotece.

jeśli używasz JQuery, dokładnie sprawdź kod, który używa funkcjihtml(...). Jeśli konstruujesz surowy HTML po stronie klienta na odwrocie niezaufanych danych wejściowych, możesz mieć problem, niezależnie od tego, czy dane wejściowe pochodzą z fragmentu URI, czy nie. W miarę możliwości użyj funkcji text(...).

jeśli używasz direct natywnych API DOM, unikaj używania następujących właściwości i funkcji:

  • innerHTML
  • outerHTML
  • document.write

zamiast tego, w miarę możliwości, Ustaw zawartość tekstu w znacznikach:

  • textContent
ostrożnie analizuj JSON

nie oceniaj JSON, aby przekonwertować go na natywne obiekty JavaScript – na przykład za pomocą funkcji eval(...). Zamiast tego użyj JSON.parse(...).

wykrywaj niebezpieczny kod za pomocą narzędzi programistycznych

Pakiet Burp, wyprodukowany przez firmę PortSwigger,może być używany do wykrywania luk w zabezpieczeniach opartych na DOM.

nie używaj w ogóle fragmentów URI!

najbezpieczniejszym kodem jest kod, którego nie ma. Jeśli nie musisz używać fragmentów URI, nie rób tego! Napisz test jednostkowy, aby przeskanować JavaScript w poszukiwaniu wzmianek o window.location.hash i niech się nie powiedzie, jeśli wzór zostanie znaleziony. Gdy istnieje potrzeba użycia fragmentów URI, możesz omówić, jak zapewnić ich Bezpieczne użycie.

zaimplementuj politykę bezpieczeństwa treści

nowoczesne przeglądarki obsługują politykę bezpieczeństwa treści, które pozwalają autorowi strony internetowej kontrolować, skąd JavaScript (i inne zasoby)mogą być ładowane i uruchamiane. Ataki XSS polegają na tym, że atakujący jest w stanie uruchomić złośliwe skrypty na stronie internetowej użytkownika – albo wprowadzając wbudowane znaczniki <script> gdzieś w tagu <html> strony, albo oszukując przeglądarkę, aby załadowała JavaScript ze złośliwej domeny innej firmy.

ustawiając politykę bezpieczeństwa treści w nagłówku odpowiedzi, możesz nakazać przeglądarce nigdy nie uruchamiać wbudowanego JavaScript i zablokować domeny, które mogą hostować JavaScript dla strony:

Content-Security-Policy: script – src 'self’ https://apis.google.com

umieszczając na białej liście adresy Uri, z których można ładować Skrypty, domyślnie stwierdzasz, że Inline JavaScript nie jest dozwolony.

polityka bezpieczeństwa treści może być również ustawiona w znaczniku <meta> w elemencie <head>strony:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

takie podejście bardzo skutecznie ochroni Twoich użytkowników! Jednak może to wymagać znacznej dyscypliny, aby Twoja witryna była gotowa na taki nagłówek.Tagi inline scripts są uważane za złą praktykę we współczesnym tworzeniu stron internetowych-mieszanie treści i kodu sprawia, że aplikacje internetowe są trudne do utrzymania-ale są popularne w starszych, starszych witrynach.

aby stopniowo odejść od skryptów wbudowanych, rozważ użycie naruszenia CSP Reports.By dodanie dyrektywy report-uri w nagłówku zasad spowoduje, że przeglądarka nie będzie informować o naruszeniach zasad, zamiast uniemożliwiać wykonywanie wbudowanych skryptów JavaScript:

Content-Security-Policy-Report-Only: script-src’self’; raport-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.

Czytaj dalej

  • jak działa Cross-Site Scripting
  • Wprowadzenie do zasad bezpieczeństwa treści
  • CSP (Content Security Policy) W Sieci programistów Mozilli
  • luka w zabezpieczeniach między stronami oparta na DOM
Cross-Site Scripting

odbite XSS

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.