WSTECZ
W przypadku najpopularniejszych bibliotek Javascript trzeba przyznać, że w historii ich rozwoju (9, 6 i 5 lat odpowiednio dla Angular, React i Vue) wydarzyło się wiele dobrego pod względem bezpieczeństwa, zwłaszcza związanego z podatnością na ataki XSS. W tym artykule omówione zostaną jednak drobne pułapki i zasady, o których deweloperzy nadal powinni wiedzieć.
Ż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.
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:
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, odpowiednio dla Vue i React. Każda dokumentacja [2] informuje czytelników, że nieostrożne użycie może narazić użytkowników na atak XSS. Jeśli żadne inne opcje nie pozwalają na rozwiązanie problemu, należy upewnić się, że dane są 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:
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:
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)?
Polish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek