Angular
Lista kontrolna
Lista kontrolna znajduje się tutaj.
Czym jest Angular
Angular to potężny i open-source'owy framework front-endowy utrzymywany przez Google. Wykorzystuje TypeScript do poprawy czytelności kodu i debugowania. Dzięki silnym mechanizmom bezpieczeństwa, Angular zapobiega powszechnym podatnościom po stronie klienta, takim jak XSS i przekierowania. Może być również używany po stronie serwera, co sprawia, że rozważania dotyczące bezpieczeństwa są ważne z obu stron.
Architektura frameworka
Aby lepiej zrozumieć podstawy Angulara, przejdźmy przez jego podstawowe koncepcje.
Przykładowy projekt Angulara zwykle wygląda tak:
Według dokumentacji, każda aplikacja Angularowa ma co najmniej jeden komponent, którym jest komponent główny (AppComponent
), łączący hierarchię komponentów z DOM-em. Każdy komponent definiuje klasę zawierającą dane i logikę aplikacji, oraz jest powiązany z szablonem HTML, który definiuje widok do wyświetlenia w docelowym środowisku. Dekorator @Component()
identyfikuje klasę poniżej niego jako komponent i dostarcza szablon oraz powiązane metadane specyficzne dla komponentu. AppComponent
jest zdefiniowany w pliku app.component.ts
.
Moduły Angulara (NgModules
) deklarują kontekst kompilacji dla zestawu komponentów, który jest dedykowany dla domeny aplikacji, procesu pracy lub zestawu powiązanych możliwości. Każda aplikacja Angularowa ma moduł główny, zazwyczaj nazwany AppModule
, który zapewnia mechanizm uruchamiania aplikacji. Aplikacja zazwyczaj zawiera wiele modułów funkcjonalnych. AppModule
jest zdefiniowany w pliku app.module.ts
.
Moduł Router
w Angularze dostarcza usługę, która umożliwia definiowanie ścieżki nawigacji między różnymi stanami aplikacji i hierarchiami widoków w aplikacji. RouterModule
jest zdefiniowany w pliku app-routing.module.ts
.
Jeśli chcesz udostępnić dane lub logikę, która nie jest powiązana z konkretnym widokiem i którą chcesz udostępnić między komponentami, tworzysz klasę usługi. Definicja klasy usługi jest poprzedzona dekoratorem @Injectable()
. Dekorator dostarcza metadane, które umożliwiają wstrzykiwanie innych dostawców jako zależności do twojej klasy. Wstrzykiwanie zależności (DI) pozwala utrzymać lekkie i wydajne klasy komponentów. Nie pobierają one danych z serwera, nie sprawdzają poprawności wprowadzanych danych użytkownika ani nie logują bezpośrednio do konsoli; te zadania delegują do usług.
Konfiguracja sourcemap
Framework Angular przekształca pliki TypeScript na kod JavaScript, stosując opcje z pliku tsconfig.json
, a następnie buduje projekt z konfiguracją z pliku angular.json
. Przeglądając plik angular.json
, zauważyliśmy opcję umożliwiającą włączanie lub wyłączanie sourcemap. Według dokumentacji Angulara, domyślna konfiguracja ma włączony plik sourcemap dla skryptów i nie jest domyślnie ukryty:
Mapy źródłowe
Pliki sourcemap są używane głównie do celów debugowania, ponieważ mapują wygenerowane pliki na ich oryginalne pliki. Dlatego nie zaleca się ich używania w środowisku produkcyjnym. Jeśli sourcemapy są włączone, poprawiają czytelność i ułatwiają analizę plików, odtwarzając pierwotny stan projektu Angular. Jednak jeśli są wyłączone, recenzent nadal może ręcznie analizować skompilowany plik JavaScript, szukając wzorców antybezpieczeństwa.
Ponadto, skompilowany plik JavaScript z projektem Angular można znaleźć w narzędziach deweloperskich przeglądarki → Źródła (lub Debugger i Źródła) → [id].main.js. W zależności od włączonych opcji, ten plik może zawierać następujący wiersz na końcu //# sourceMappingURL=[id].main.js.map
lub może go nie zawierać, jeśli opcja hidden jest ustawiona na true. Niemniej jednak, jeśli sourcemap jest wyłączony dla skryptów, testowanie staje się bardziej skomplikowane i nie możemy uzyskać pliku. Ponadto, sourcemap można włączyć podczas budowania projektu, używając ng build --source-map
.
Wiązanie danych
Wiązanie odnosi się do procesu komunikacji między komponentem a odpowiadającym mu widokiem. Jest używane do przesyłania danych do i z frameworka Angular. Dane mogą być przekazywane na różne sposoby, takie jak za pomocą zdarzeń, interpolacji, właściwości lub za pomocą mechanizmu dwukierunkowego wiązania. Ponadto, dane mogą być również udostępniane między powiązanymi komponentami (relacja rodzic-dziecko) oraz między dwoma niepowiązanymi komponentami za pomocą funkcji usługi.
Możemy sklasyfikować wiązanie według przepływu danych:
Dane źródłowe do celu widoku (obejmuje interpolację, właściwości, atrybuty, klasy i style); można je zastosować za pomocą
[]
lub{{}}
w szablonie;Cel widoku do źródła danych (obejmuje zdarzenia); można je zastosować za pomocą
()
w szablonie;Dwukierunkowe; można je zastosować za pomocą
[()]
w szablonie.
Wiązanie można stosować do właściwości, zdarzeń i atrybutów, a także do dowolnego publicznego elementu członkowskiego dyrektywy źródłowej:
Model bezpieczeństwa Angulara
Projekt Angulara obejmuje domyślne kodowanie lub oczyszczanie wszystkich danych, co utrudnia odkrywanie i wykorzystywanie podatności XSS w projektach Angulara. Istnieją dwa różne scenariusze obsługi danych:
Interpolacja lub
{{user_input}}
- wykonuje kodowanie zależne od kontekstu i interpretuje dane wprowadzone przez użytkownika jako tekst;
Wynik: <script>alert(1)</script><h1>test</h1>
2. Wiązanie do właściwości, atrybutów, klas i stylów lub [attribute]="user_input"
- wykonuje oczyszczanie na podstawie dostarczonego kontekstu bezpieczeństwa.
Wynik: <div><h1>test</h1></div>
Istnieje 6 typów SecurityContext
:
None
;HTML
jest używane do interpretacji wartości jako HTML;STYLE
jest używane do wiązania CSS w właściwośćstyle
;URL
jest używane dla właściwości URL, takich jak<a href>
;SCRIPT
jest używane dla kodu JavaScript;RESOURCE_URL
jako URL, który jest ładowany i wykonuje się jako kod, na przykład w<script src>
.
Podatności
Metody bypassowania zaufania bezpieczeństwa
Angular wprowadza listę metod umożliwiających obejście domyślnego procesu oczyszczania i wskazanie, że wartość może być bezpiecznie używana w określonym kontekście, jak w poniższych pięciu przykładach:
bypassSecurityTrustUrl
służy do wskazania, że podana wartość jest bezpiecznym adresem URL stylu:
bypassSecurityTrustResourceUrl
służy do wskazania, że podana wartość jest bezpiecznym adresem URL zasobu:
bypassSecurityTrustHtml
służy do wskazania, że podana wartość jest bezpiecznym kodem HTML. Należy zauważyć, że wstawianie elementówscript
do drzewa DOM w ten sposób nie spowoduje wykonania zawartego w nich kodu JavaScript, ze względu na sposób dodawania tych elementów do drzewa DOM.
bypassSecurityTrustScript
służy do wskazania, że podana wartość jest bezpiecznym kodem JavaScript. Jednakże, stwierdziliśmy, że jego zachowanie jest nieprzewidywalne, ponieważ nie udało nam się wykonać kodu JS w szablonach za pomocą tej metody.
bypassSecurityTrustStyle
służy do wskazania, że podana wartość jest bezpiecznym kodem CSS. Poniższy przykład ilustruje wstrzykiwanie CSS:
Angular udostępnia metodę sanitize
do oczyszczania danych przed ich wyświetleniem w widokach. Ta metoda korzysta z dostarczonego kontekstu bezpieczeństwa i oczyszcza dane
Wstrzykiwanie HTML-a
Ta podatność występuje, gdy dane wprowadzone przez użytkownika są przypisywane do jednej z trzech właściwości: innerHTML
, outerHTML
lub iframe
srcdoc
. Podczas przypisywania do tych atrybutów, HTML jest interpretowany w oryginalnej postaci, ale dane wejściowe są oczyszczane za pomocą SecurityContext.HTML
. W związku z tym, wstrzykiwanie HTML-a jest możliwe, ale nie jest możliwe wykonanie ataku typu cross-site scripting (XSS).
Przykład użycia innerHTML
:
Wynik to <div><h1>test</h1></div>
.
Wstrzykiwanie szablonów
Renderowanie po stronie klienta (CSR)
Angular wykorzystuje szablony do dynamicznego tworzenia stron. Ta metoda polega na umieszczaniu wyrażeń szablonowych, które Angular ma ocenić, w podwójnych nawiasach klamrowych ({{}}
). Dzięki temu framework oferuje dodatkową funkcjonalność. Na przykład, szablon taki jak {{1+1}}
zostanie wyświetlony jako 2.
Zazwyczaj Angular unika interpretacji danych wprowadzanych przez użytkownika jako wyrażeń szablonowych (np. znaki takie jak `< > ' " ``). Oznacza to, że konieczne są dodatkowe kroki, aby obejść to ograniczenie, takie jak wykorzystanie funkcji generujących obiekty łańcuchów znakowych JavaScript, aby uniknąć użycia czarnolistowanych znaków. Jednak aby to osiągnąć, musimy wziąć pod uwagę kontekst Angulara, jego właściwości i zmienne. Dlatego atak wstrzykiwania szablonów może wyglądać następująco:
Jak pokazano powyżej: constructor
odnosi się do zakresu właściwości obiektu constructor
, umożliwiając nam wywołanie konstruktora String i wykonanie dowolnego kodu.
Renderowanie po stronie serwera (SSR)
W przeciwieństwie do CSR, które występuje w DOM przeglądarki, Angular Universal jest odpowiedzialny za SSR plików szablonów. Następnie te pliki są dostarczane użytkownikowi. Pomimo tej różnicy, Angular Universal stosuje te same mechanizmy sanitarnizacji, które są używane w CSR, aby zwiększyć bezpieczeństwo SSR. Podatność na wstrzykiwanie szablonów w SSR można zauważyć w ten sam sposób, co w przypadku CSR, ponieważ używany język szablonów jest taki sam.
Oczywiście istnieje również możliwość wprowadzenia nowych podatności na wstrzykiwanie szablonów przy użyciu zewnętrznych silników szablonów, takich jak Pug i Handlebars.
XSS
Interfejsy DOM
Jak wcześniej wspomniano, możemy bezpośrednio uzyskać dostęp do DOM za pomocą interfejsu Document. Jeśli dane wprowadzone przez użytkownika nie są wcześniej zweryfikowane, może to prowadzić do podatności na ataki typu cross-site scripting (XSS).
Poniżej przedstawiono przykłady użycia metod document.write()
i document.createElement()
:
Klasy Angulara
Istnieją pewne klasy, które można używać do pracy z elementami DOM w Angularze: ElementRef
, Renderer2
, Location
i Document
. Szczegółowy opis ostatnich dwóch klas znajduje się w sekcji Przekierowania otwarte. Główną różnicą między pierwszymi dwoma jest to, że API Renderer2
zapewnia warstwę abstrakcji między elementem DOM a kodem komponentu, podczas gdy ElementRef
po prostu przechowuje odniesienie do elementu. Dlatego według dokumentacji Angulara, API ElementRef
powinno być używane tylko jako ostateczność, gdy potrzebny jest bezpośredni dostęp do DOM.
ElementRef
zawiera właściwośćnativeElement
, która może być używana do manipulowania elementami DOM. Jednak niewłaściwe użycienativeElement
może prowadzić do podatności na wstrzyknięcie XSS, jak pokazano poniżej:
Pomimo faktu, że
Renderer2
zapewnia API, które można bezpiecznie używać nawet wtedy, gdy nie jest obsługiwany bezpośredni dostęp do elementów natywnych, nadal ma pewne luki bezpieczeństwa. Za pomocąRenderer2
można ustawić atrybuty na elemencie HTML za pomocą metodysetAttribute()
, która nie ma mechanizmów zapobiegających XSS.
Aby ustawić właściwość elementu DOM, można użyć metody
Renderer2.setProperty()
i wywołać atak XSS:
Podczas naszych badań przeanalizowaliśmy również zachowanie innych metod Renderer2
, takich jak setStyle()
, createComment()
i setValue()
, w odniesieniu do wstrzykiwania XSS i CSS. Jednak nie udało nam się znaleźć żadnych prawidłowych wektorów ataku dla tych metod ze względu na ich ograniczenia funkcjonalne.
jQuery
jQuery to szybka, mała i bogata w funkcje biblioteka JavaScript, która może być używana w projekcie Angulara do manipulacji obiektami HTML DOM. Jednak, jak wiadomo, metody tej biblioteki mogą być wykorzystane do osiągnięcia podatności na XSS. Aby omówić, jak niektóre podatne metody jQuery mogą być wykorzystane w projektach Angulara, dodaliśmy tę podsekcję.
Metoda
html()
pobiera zawartość HTML pierwszego elementu w zestawie dopasowanych elementów lub ustawia zawartość HTML dla każdego dopasowanego elementu. Jednak zgodnie z projektem, każdy konstruktor jQuery lub metoda, która akceptuje ciąg HTML, może potencjalnie wykonać kod. Może to nastąpić poprzez wstrzyknięcie znaczników<script>
lub użycie atrybutów HTML, które wykonują kod, jak pokazano w przykładzie.
Metoda
jQuery.parseHTML()
używa natywnych metod do konwersji ciągu na zestaw węzłów DOM, które można następnie wstawić do dokumentu.
Jak wspomniano wcześniej, większość interfejsów API jQuery, które akceptują ciągi HTML, uruchamia skrypty zawarte w HTML. Metoda jQuery.parseHTML()
nie uruchamia skryptów w sparsowanym HTML, chyba że keepScripts
jest jawnie ustawione na true
. Jednak w większości środowisk wciąż możliwe jest pośrednie wykonanie skryptów, na przykład za pomocą atrybutu <img onerror>
.
Przekierowania otwarte
Interfejsy DOM
Zgodnie z dokumentacją W3C, obiekty window.location
i document.location
są traktowane jako aliasy we współczesnych przeglądarkach. Dlatego mają podobną implementację niektórych metod i właściwości, co może prowadzić do otwartego przekierowania i ataków XSS na schemat javascript://
, jak opisano poniżej.
window.location.href
(idocument.location.href
)
Kanonicznym sposobem uzyskania bieżącego obiektu lokalizacji DOM jest użycie window.location
. Może również być używany do przekierowania przeglądarki na nową stronę. W rezultacie kontrola nad tym obiektem pozwala nam wykorzystać podatność na otwarte przekierowanie.
Proces eksploatacji jest identyczny dla następujących scenariuszy.
window.location.assign()
(idocument.location.assign()
)
Ta metoda powoduje załadowanie i wyświetlenie dokumentu pod podanym adresem URL. Jeśli mamy kontrolę nad tą metodą, może to być miejsce podatne na atak otwartego przekierowania.
window.location.replace()
(idocument.location.replace()
)
Ta metoda zastępuje bieżący zasób tym, który jest dostarczany pod podanym adresem URL.
Różnica między metodą assign()
polega na tym, że po użyciu window.location.replace()
bieżąca strona nie zostanie zapisana w historii sesji. Jednak możliwe jest również wykorzystanie podatności na otwarte przekierowanie, gdy mamy kontrolę nad tą metodą.
window.open()
Metoda window.open()
przyjmuje adres URL i wczytuje zasób, który identyfikuje, do nowej lub istniejącej karty lub okna. Posiadanie kontroli nad tą metodą może również stanowić okazję do wywołania podatności na XSS lub otwartego przekierowania.
Klasy Angular
Według dokumentacji Angulara, klasa Angular
Document
jest taka sama jak dokument DOM, co oznacza, że można używać wspólnych wektorów dla dokumentu DOM w celu wykorzystania podatności po stronie klienta w Angularze. Właściwości i metodyDocument.location
mogą być źródłem udanych ataków na przekierowanie otwarte, jak pokazano na przykładzie:
Podczas fazy badawczej przeanalizowaliśmy również klasę Angular
Location
pod kątem podatności na przekierowanie otwarte, ale nie znaleziono żadnych ważnych wektorów.Location
to usługa Angulara, którą aplikacje mogą używać do interakcji z bieżącym adresem URL przeglądarki. Ta usługa ma kilka metod do manipulowania podanym adresem URL -go()
,replaceState()
iprepareExternalUrl()
. Jednak nie możemy ich używać do przekierowania na zewnętrzną domenę. Na przykład:
Wynik: http://localhost:4200/http://google.com/about
Klasa Angular
Router
jest głównie używana do nawigacji w obrębie tej samej domeny i nie wprowadza dodatkowych podatności do aplikacji:
Wynik: http://localhost:4200/https:
Następujące metody również nawigują w zakresie domeny:
Odwołania
Last updated