thecodest, Author at The Codest

XSS

Żyjemy w erze frameworków, a nie języków. Oznacza to, że programiści powinni być w stanie mniej martwić się o wiele aspektów rozwoju, w tym o bezpieczeństwo. Większość obecnych frameworków backendowych implementuje moduły bezpieczeństwa, które są testowane przez zewnętrzne, wyspecjalizowane firmy i duże stowarzyszenia. Dlatego, malejąca świadomość bezpieczeństwa Może to być widoczne na przykład między młodymi programistami, którzy biorą większą odpowiedzialność za produkty, zwłaszcza w zakresie freelancingu.

Jednym z powszechnych ataków po stronie klienta aplikacji jest XSS (Cross-Site Scripting). Jest on wykonywany poprzez wstrzykiwanie skryptów uruchamianych po stronie klienta do aplikacji internetowych [1] i wykorzystuje zaimplementowane metody renderowania HTML lub Javascript kod oceniających, które go wykonują. XSS jest stosunkowo lukratywny, ponieważ może gromadzić wiele różnych danych, w tym pliki cookie sesji lub dane użytkownika, i może zainstalować aplikację śledzącą, taką jak keylogger, co czyni go niebezpiecznym zarówno dla użytkowników, jak i właścicieli firm. Czasami wykonywane są inne formy ataku, aby umożliwić XSS na stronie, takie jak Wstrzyknięcie kodu SQL.

Przykład

Formularz logowania na stronie renderuje parametr loginName wysłany w żądaniu GET w polu nazwy logowania. Wartość nie jest przetwarzana ani przez serwer, ani po stronie klienta aplikacji. Poprzez żądanie: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
kod jest wykonywany, a dane są ujawniane

To jest przykład odbity atak XSS, gdzie skrypty są wstrzykiwane za pośrednictwem specjalnie przygotowanego adresu URL przesłanego do ofiary i odzwierciedlanego przez odpowiedź serwera. Inne znane popularne formy ataków są następujące:

Przechowywane XSS wykonywane przy użyciu wstrzykniętych danych przechowywanych po stronie serwera, zwykle za pomocą formularzy dostępnych w aplikacji. Aplikacja kliencka renderuje kod przechowywany na przykład w bazie danych.
DOM XSS wykonuje atak XSS bez użycia strony serwera. W dalszej części artykułu skupimy się na tej formie ataku.

Aktualne luki w zabezpieczeniach bibliotek React i Vue

W obecnych wersjach React/Vue wykryto dwa poważne problemy, które nie zostały jeszcze oficjalnie naprawione. Pierwsza luka ma ten sam charakter dla każdego frameworka i jest związana z metodami pozwalającymi na renderowanie surowego HTML w szablonach: v-html i dangerouslySetInnerHTML, respectively, for Vue and React. Each documentation [2] informs readers that unwise usage may expose users to XSS attack. If no other options allow for resolving the problem, ensure that the data is filtrowany i uciekł. Chociaż są one niebezpieczne, nie należy oczekiwać, że metody te zostaną naprawione. Używaj ich na własne ryzyko.

W pierwszym kwartale 2018 roku wykryto duży błąd w React, umożliwiający bezpośrednie wykonanie kodu poprzez ustawienie właściwości dla elementu znacznika. Przekazywanie przykładowego kodu w ramach atrybutów, takich jak javascript:alert(1) i uruchomienie renderowanego łącza spowoduje wykonanie kodu. Problem ten [4] jest wciąż otwarty i nie została przygotowana żadna poprawka, więc upewnij się, że Twój kod jest bezpieczny. Przykłady zaproponowane w oficjalnej dyskusji sugerują kilka sposobów na przezwyciężenie tego problemu.

Jeśli aktualizacja do najnowszych wersji nie jest możliwa, upewnij się, że stare błędy nie powodują problemów, upewniając się, że Twój kod nie jest na nie narażony:

dziecko węzeł wtrysk - React, użycie React.createElement [5]
renderowanie po stronie serwera - React/Vue [6]
Wstrzykiwanie CSS [8]

Wciąż chodzi o Javascript. Wciąż chodzi o front-end

Nie zapominaj, że oprócz samych frameworków lub bibliotek, Javascript jako język ma pewne niebezpieczne funkcje, których należy unikać lub używać z ostrożnością. Są one zazwyczaj związane z manipulacją DOM lub wykonywaniem skryptów. eval() reprezentuje flagowe funkcje tego rodzaju i jest niezwykle niebezpieczna, ponieważ bezpośrednio wykonuje podany kod łańcuchowy [9]. Ponadto, lepiej przyjrzyj się swojemu kodowi, gdy znajdziesz jedną z tych funkcji:

document.write
document.writeln
(element).innerHTML
(element).outerHTML
(element).insertAdjacentHTML

W tym przypadku użycie linterów z odpowiednim zestawem reguł może być pomocne w znalezieniu takich podatnych na ataki punktów. Istnieje również wiele otwartych lub komercyjnych analizatorów kodu, które mogą pomóc w wykryciu luk bezpieczeństwa w opracowanym kodzie.

Niezależnie od wybranej biblioteki/frameworka, wciąż musimy pamiętać o podstawowych zasadach związanych z tworzeniem front-endu. Po pierwsze, zawsze upewnij się, że zewnętrzny kod, który wstrzykujesz, pochodzi z zaufanego źródła. Audyt zależności i wybieraj je mądrze. Niektóre z nich mogą zawierać poważne luki w zabezpieczeniach, narażając twój kod, nawet jeśli wszystko jest w porządku z samym kodem. Więcej o bezpieczeństwie zależności można przeczytać tutaj:

https://thecodest.co/blog/security-in-javascript-packages/

Więc... czy nadal powinieneś się martwić?

Tak - i gorąco zachęcam wszystkich, aby nigdy nie ufali zewnętrznym bibliotekom ani sobie w kwestii bezpieczeństwa. Bez względu na to, jak bezpieczne jest twoje oprogramowanie, zawsze staraj się przetestować je w jak największym stopniu pod kątem typowych form ataku [10].

Czytaj więcej:

5 błędów, których należy unikać podczas prowadzenia projektu w PHP

PHP Development. Komponent konsoli Symfony - porady i wskazówki

Dlaczego potrzebujemy Symfony Polyfill (... i dlaczego nie powinniśmy)?