Handlebars JS automatycznie stosuje kod ucieczki, aby zapobiec wstrzyknięciu, ale niebezpieczne wzorce, takie jak potrójne nawiasy klamrowe lub źle napisane niestandardowe funkcje pomocnicze, mogą całkowicie ominąć tę ochronę. Gdy to nastąpi, atakujący mogą wstrzyknąć ładunki XSS, ukraść dane lub uruchomić złośliwy kod za pośrednictwem szablonów, które programiści uznali domyślnie za bezpieczne.
W tym przewodniku dowiesz się, jak bezpiecznie korzystać z Handlebars, wyróżnisz przykłady niebezpiecznych i bezpiecznych rozwiązań oraz wyjaśnisz, jak zautomatyzować walidację szablonów w pipelineprzy użyciu narzędzi takich jak Xygeni.
Dlaczego szablony na kierownicę mogą być ryzykowne
Domyślnie Handlebars JS używa escape'ów, aby zablokować bezpośrednie wstrzykiwanie kodu. Wielu programistów wyłącza tę funkcję, nie zdając sobie sprawy z ryzyka. Na przykład użycie potrójnych nawiasów klamrowych powoduje wyświetlenie surowego kodu HTML:
If userInput is <script>alert('XSS')</script>, Skrypt jest wykonywany w przeglądarce. W rezultacie nawet jeden niebezpieczny szablon może zagrozić całej aplikacji.
Te podstawowe błędy doprowadziły do rzeczywistych, udokumentowanych nadużyć, a nie tylko teoretycznego ryzyka. Oto dwa najgłośniejsze przypadki.
Przykłady luk w zabezpieczeniach kierownic w świecie rzeczywistym
Chociaż Kierownica JS domyślnie ucieka wartości, historia pokazuje, że niebezpieczne wzorce lub słabe Pomocnicy kierownicy spowodowały poważne problemy:
1. Zanieczyszczenie kierownic prototypowych (zalecenie npm GHSA-2cf5-4w76-r9qv)
W 2021 roku wykryto błąd w handlebars samego opakowania. Wada ta umożliwiła prototyp zanieczyszczenia, gdzie atakujący mogą wstrzykiwać właściwości do obiektów globalnych za pomocą spreparowanych szablonów.
- Wpływ: Zanieczyszczenie prototypów może umożliwić atakującym uruchomienie kodu, uzyskanie większego dostępu lub kradzież danych.
- Wykorzystać: Napastnicy wysłali złośliwe dane wejściowe, takie jak
__proto__Właściwości. Podczas renderowania szablonów te zanieczyszczone obiekty zmieniały sposób działania aplikacji. - Lekcja: Nawet silnik szablonów może być ryzykowny, jeśli nie jest aktualizowany. Uruchamianie skanowania zależności i aktualizowanie pakietów ma kluczowe znaczenie.
2. XSS w Asanie w sekcji Custom Handlebars Helpers (2019)
W 2019 roku badacze bezpieczeństwa odkryli, że Asananarzędzie do zarządzania zadaniami, udostępniające użytkownikom XSS z powodu niebezpiecznych niestandardowych pomocników. Programiści napisali pomocniki, które zwracały surowe ciągi znaków, używając SafeString, omijając wbudowaną funkcję ucieczki Handlebars.
- Wpływ: Napastnicy wstrzyknęli złośliwy kod JavaScript do współdzielonych zadań lub komentarzy.
- Wykorzystać: Ładunki takie jak
<script>alert('XSS')</script>został uruchomiony w przeglądarce ofiary po otwarciu tych pól. - Lekcja: Nigdy nie wyłączaj funkcji ucieczki, chyba że nie masz innego wyjścia. Zawsze sprawdzaj ustawienia niestandardowe. Pomocnicy kierownicy przed ich wdrożeniem.
Rodzaje luk w zabezpieczeniach kierownic
Niebezpieczne użycie Kierownica JS Szablony mogą ujawniać różne klasy luk w zabezpieczeniach. Ich zrozumienie pomaga programistom dokładnie wiedzieć, czego unikać:
Skrypty między lokacjami (XSS)
To najczęstsza wada. Występuje, gdy programiści używają potrójnych nawiasów klamrowych. {{{}}} lub surowych pomocników, którzy uniemożliwiają ucieczkę.
- Wpływ: Napastnicy mogą wstrzyknąć
<script>znaczniki, kod HTML lub ramki iframe, które działają w przeglądarce użytkownika. - Przykład:
If
userInputzawiera<script>alert('XSS')</script>, zostanie wykonane natychmiast.
Prototyp zanieczyszczenia
Jak widać w npm advisory GHSA-2cf5-4w76-r9qvZłośliwe dane wejściowe mogą modyfikować obiekty globalne za pomocą spreparowanych szablonów.
- Wpływ: Może to prowadzić do nieuzasadnionych zachowań, eskalacji uprawnień lub wycieku danych.
- Lekcja: Zawsze trzymaj
handlebarszaktualizowano i uruchomiono sprawdzanie zależności CI/CD.
Wstrzykiwanie szablonów po stronie serwera (SSTI)
SSTI występuje, gdy niezaufane dane wejściowe są przekazywane bezpośrednio do silnika szablonów działającego na serwerze. Kierownica JSJeśli programiści skompilują szablony, wykorzystując surowe dane wejściowe użytkownika, atakujący może uruchomić ładunki na poziomie serwera.
Silnik może próbować je ocenić, ujawniając pliki po stronie serwera.
- Wpływ: W przeciwieństwie do XSS, który wpływa tylko na przeglądarkę, SSTI może zapewnić bezpośredni dostęp do środowiska serwerowego.
- Zapobieganie: Nigdy nie kompiluj szablonów z niezaufanych źródeł. Zamiast tego używaj wyłącznie predefiniowanych szablonów i oczyszczaj dane wejściowe przed renderowaniem.
Podobne zagrożenia występują w innych ekosystemach. Zobacz na przykład nasz poradnik Wstrzykiwanie zależności w Pythonie nauczyć się bezpiecznych praktyk w innym kontekście.
Nadużywanie logiki u pomocników
warunki indywidualne Pomocnicy kierownicy może być niebezpieczne, jeśli dopuszcza surowe ciągi znaków lub pracuje z niezweryfikowanymi danymi wejściowymi.
- Wpływ: Atakujący mogą ominąć procedurę ucieczki lub oszukać osoby udzielające pomocy, aby ujawniły wrażliwe dane.
- Przykład:
Ta funkcja pomocnicza całkowicie uniemożliwia ucieczkę, dlatego należy jej unikać.
Wyciek danych
Czasami pomocnicy lub błędnie skonfigurowane szablony ujawniają poufne informacje.
- Wpływ: Tokeny, wartości konfiguracyjne i dane uwierzytelniające bazy danych mogą być renderowane w wynikach HTML.
- Lekcja: Nigdy nie ujawniaj poufnych informacji zawartych w szablonach; sprawdzaj poprawność danych i skanuj swoje repozytoria w poszukiwaniu przypadkowych wycieków.
Łącznie te kategorie pokazują zakres ryzyka, od błędu renderowania w przeglądarce po całkowitą kompromitację serwera. Nawet niewielki błąd w szablonie Handlebars, jeśli nie zostanie naprawiony, może stać się problemem w łańcuchu dostaw.
Dlaczego to ma znaczenie dla programistów
Te luki nie są teoretyczne; zostały wykorzystane na rzeczywistych platformach, takich jak Asana i Handlebars pakiet npm Ponieważ Handlebars JS jest tak szeroko stosowany w projektach Node.js i front-end, niezabezpieczony pomocnik lub przestarzała zależność w jednym projekcie może szybko stać się zagrożeniem dla łańcucha dostaw oprogramowania, dotykając wielu innych.
Chcesz automatycznie zablokować te zagrożenia? Rozpocznij bezpłatny okres próbny Xygeni i dodać guardrails w telefonie pipeline dzisiaj.
Najlepsze praktyki bezpiecznego użytkowania kierownic
Aby uniknąć błędów związanych z wstrzykiwaniem kodu, należy stosować się do poniższych zasad bezpiecznego kodowania:
1. Zawsze używaj podwójnych nawiasów klamrowych
Dzięki temu silnik szablonów wykona ucieczkę kodu HTML przed renderowaniem.
2. Zweryfikuj i zdezynfekuj dane wejściowe
Ponadto należy zweryfikować dane wejściowe przed przekazaniem ich do szablonów. Biblioteki takie jak walidator.js
3. Ograniczaj niebezpiecznych pomocników
Słabo zaprojektowane Pomocnicy kierownicy często powodują luki w zabezpieczeniach:
To całkowicie pomija escaping. Jednak bezpieczne pomoce powinny być ograniczone do prostych operacji, takich jak formatowanie dat czy przycinanie tekstu.
4. Użyj Polityki bezpieczeństwa treści (CSP)
Ponadto należy wymusić stosowanie silnych nagłówków CSP w celu zmniejszenia promienia rażenia dowolnego wstrzyknięcia.
Te najlepsze praktyki są ważne podczas rozwoju. Dodatkowo możesz dodać automatyczne kontrole, aby niebezpieczny kod nigdy nie trafił do produkcji.
Automatyzacja walidacji w CI/CD Pipelines
Same ręczne przeglądy nie wystarczą, niebezpieczne wzorce Handlebars mogą przedostać się do produkcji, jeśli nie zostaną wdrożone automatyczne kontrole:
- SAST reguły: Flaga
{{{in.hbsakta. - Skanery sekretów:Wykryj poświadczenia osadzone w szablonach.
- CI/CD guardrails: Przerwij kompilację, gdy jest niebezpieczna Pomocnicy kierownicy lub pojawiają się potrójne nawiasy klamrowe.
Na przykład możesz wymusić zastosowanie bariery ochronnej w pipelines:
Te kontrole zmniejszają ryzyko przedostania się niebezpiecznych szablonów do środowiska produkcyjnego, ale ich konsekwentne egzekwowanie w każdym repozytorium i pipeline tu właśnie pojawia się dedykowana platforma, taka jak Xygeni.
Można również zobaczyć, jak zabezpiecza się pipelines w Bitbucket działa w naszym Często zadawane pytania dotyczące bezpieczeństwa Bitbuckets.
Jak Xygeni pomaga zapobiegać niebezpiecznemu użytkowaniu kierownic
Pisanie bezpiecznego kodu jest ważne, ale prawdziwą ochronę zapewnia automatyzacja. Xygeni sprawia, że Kierownica JS bezpieczniej, dodając kontrole do swojego przepływu pracy:
- SAST dla szablonów: Skanuje
.hbspliki do wyłapywania niebezpiecznych{{{lub ryzykownych niestandardowych pomocników. - Guardrails: Ustaw proste reguły w GitHub, GitLab lub Bitbucket. Jeśli zostanie znaleziony niebezpieczny kod JS Handlebars, kompilacja zostanie zatrzymana.
- Samonaprawa: Sugeruje bezpieczne poprawki w pull requests, zamieniając potrójne nawiasy klamrowe na bezpieczne podwójne nawiasy klamrowe lub zaufane wezwania pomocnika.
- Tajemnice i kontrole konfiguracji: Wykrywa tokeny i dane uwierzytelniające ukryte w szablonach, zanim zostaną ujawnione.
- CI/CD Ochrona: Blokuje niebezpieczne fragmenty kodu podczas scalania, dzięki czemu do produkcji trafia wyłącznie bezpieczny kod.
Z Xygeni, bezpiecznie Kierownica JS użytkowanie nie jest już tylko wskazówką. Staje się częścią Twojego zautomatyzowanego pipeline.
Wszystko razem
Handlebars jest domyślnie bezpieczny, ale niewłaściwe użycie nadal otwiera drzwi do ataków typu injection. Przestrzeganie tych najlepszych praktyk, weryfikacja danych wejściowych, ograniczanie niebezpiecznych pomocników i egzekwowanie CSP, wypełnia większość tej luki. Prawdziwą zaletą jest to, że te kontrole uruchamiają się automatycznie w Twoim systemie. pipeline zamiast polegać na ręcznym przeglądzie za każdym razem.
Połączenie tych nawyków z platformą typu Xygeni sprawia, że szablony są bezpieczne, nie spowalniając dostarczania.
FAQ
Czy korzystanie z Handlebars JS jest bezpieczne?
Tak, domyślnie. Handlebars automatycznie stosuje znaki escape, aby zapobiec wstrzyknięciu. Ryzyko wynika z obchodzenia tego zabezpieczenia przez programistów, najczęściej za pomocą potrójnych nawiasów klamrowych ({{{ }}}) lub niestandardowych funkcji pomocniczych, które zwracają surowe, niezakodowane ciągi znaków.
Jaka jest różnica między atakiem XSS a atakiem SSTI (Server-Side Template Injection) w aplikacji Handlebars?
XSS atakuje przeglądarkę: złośliwy skrypt uruchamia się w sesji ofiary. SSTI jest poważniejszym atakiem i występuje, gdy niezaufane dane wejściowe są kompilowane bezpośrednio do szablonu na serwerze, co potencjalnie naraża pliki po stronie serwera lub dostęp do środowiska, a nie tylko przeglądarkę.
Skąd mam wiedzieć, czy pomocnicy kierownicy są niebezpieczni?
Funkcja pomocnicza stanowi zagrożenie, jeśli zwraca surowy ciąg znaków za pomocą SafeString lub w inny sposób omija domyślne escaping w Handlebars. Ogranicz niestandardowe funkcje pomocnicze do prostych operacji niezwracających ciągów znaków, takich jak formatowanie dat lub przycinanie tekstu.
Czy narzędzia automatyczne mogą wykryć niebezpieczne użytkowanie kierownicy przed jej wysyłką?
Tak. SAST reguły mogą oznaczać potrójne nawiasy klamrowe w plikach .hbs, skanery sekretów mogą wychwytywać poświadczenia osadzone w szablonach, a CI/CD guardrails może całkowicie zablokować kompilację, gdy wykryte zostaną niebezpieczne wzorce, wykrywając problemy jeszcze przed ręcznym przeglądem.
