Wykradanie danych w świetnym stylu – czyli jak wykorzystać CSS-y do ataków na webaplikację

25 września 2017, 22:30 | Teksty | komentarzy 14
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.
W tym artykule zostanie pokazany przykład, w jaki sposób można wykorzystać możliwość wstrzyknięcia własnych reguł CSS w webaplikację w celu eksfiltracji danych. Atak ten może być w szczególności praktyczny do wykradania tokenów chroniących przed atakami CSRF.

Ataki wykorzystujące CSS-y do wykradania danych nie są w żadnym wypadku nowe. W zeszłym roku pisaliśmy na Sekuraku o ataku znanym jako Relative Path Overwrite (RPO) lub Path–Relative Style Sheet Import (PRSSI). Pokazaliśmy w tamtym artykule, że wstrzyknięcie własnego CSS-a może zostać wykorzystane do złośliwej podmiany zawartości strony np. w celu naruszenia dobrego imienia innej osoby, a także, że w pewnych warunkach, wstrzyknięcie CSS-a może skutkować XSS-em.

W tym tekście zobaczymy, że wstrzyknięcia CSS-owe mogą być wykorzystywane do wykradania danych umieszczonych wewnątrz atrybutów tagów HTML-owych – co zrobimy pierwszym, łatwiejszym sposobem – jak również do wykradania właściwie dowolnych danych na stronie z użyciem magii przeglądarek webkitowych, stylowania pasków przewijania i ligatur w fontach.

Przykładowa podatna strona

Na potrzeby przykładów do tego artykułu założymy, że mamy stronę, na której istnieją dwa tokeny CSRF-owe, które będziemy chcieli wykraść.

W powyższym przykładzie mamy prostą stronę, na której zdefiniowano dwa tokeny CSRF-owe:

  • Jeden z nich jest w polu <input> – co jest bardzo często spotykane w realnych aplikacjach webowych,
  • Drugi z nich jest wewnątrz tagu <script>.

Dodatkowo możemy do tego skryptu dodać parametr ?css= w URL-u i zostanie on umieszczony wewnątrz tagu <style>.

Naszym celem jest wydobycie za pomocą CSS-ów obu tych tokenów.

By uruchomić u siebie tę aplikację PHP, można użyć serwera wbudowanego w interpreter PHP, a więc w folderze, w którym umieścimy plik z kodem powyżej, możemy wywołać polecenie:

Wówczas na porcie 12345 na localhoście będzie uruchomiona powyższa strona.

Rys 1. Kod HTML przykładowej "podatnej" strony

Rys 1. Kod HTML przykładowej „podatnej” strony

Ponadto potrzebna nam będzie maszyna wirtualna, na której hostować będziemy część serwerową ataku. Na potrzeby artykułu przygotowaliśmy plik Vagrantfile, który uruchomi maszynę wirtualną dostępną w trybie host-only pod adresem 192.168.13.37 oraz zainstaluje niezbędne oprogramowanie (nodejs oraz fontforge).

By uruchomić maszynę, wystarczy powyższy kod zapisać w pliku o nazwie Vagrantfile i uruchomić kolejno polecenia:

Domyślnie katalog /vagrant na maszynie wirtualnej jest folderem współdzielonym z hostem, przez który można łatwo wymieniać pliki.

Wydobycie tokena z atrybutu

Jako pierwsze zadanie spróbujmy więc wydobyć wartość tokena z pola typu hidden.

Okazuje się, że takie zadanie jest dość proste, ponieważ bezpośrednio z pomocą przychodzą nam selektory CSS-a. Selektory – mówiąc najkrócej – pozwalają nam w CSS-ie dokładnie wybrać ten element, który chcemy ostylować. Możemy szukać elementów według klas, identyfikatorów, nazw tagów czy też wartości dowolnych atrybutów. Poniżej kilka podstawowych przykładów selektorów CSS:

Wskazówką do dalszego przebiegu naszego ataku jest ostatni z wymienionych powyżej przykładów selektorów: CSS pozwala nam wyszukiwać elementu według początku wartości atrybutu. Co za tym idzie, możemy przygotować różne style dla wszystkich możliwych wartości pierwszego znaku atrybutu. Zobaczmy to na następującym przykładzie:

Co się tutaj dzieje? Widzimy, że w zależności od pierwszego znaku wartości elementu input, ustawiane jest dla niego różne tło. Przeglądarki domyślnie starają się minimalizować liczbę zewnętrznych zapytań http wysyłanych do serwerów, co oznacza, że przeglądarka wyśle zapytanie tylko o ten obrazek tła, do którego selektor będzie dopasowany. Oznacza to, że na serwer napastnika trafi pierwszy znak tokena!

Możemy łatwo to sprawdzić wrzucając odpowiedniego CSS-a do strony i zaglądając do narzędzi deweloperskich przeglądarki (Rys 2).

Rys 2. W narzędziach deweloperskich widać jedno zapytanie do zewnętrznego serwera. Wniosek: pierwszy znak tokena to "6"

Rys 2. W narzędziach deweloperskich widać jedno zapytanie do zewnętrznego serwera. Wniosek: pierwszy znak tokena to „6”

Na razie wydobyliśmy tylko jeden znak tokena; w praktycznym przypadku oczywiście chcemy wydobyć je wszystkie. By tego dokonać, będziemy musieli kolejne znaki wydobywać iteracyjnie, tj. najpierw wydobywamy pierwszy znak tokena; jak już go mamy, to generujemy nowego CSS-a i próbujemy wszystkich możliwości dla drugiego znaku. Jak już mamy drugi znak to generujemy kolejnego CSS-a do wydobycia trzeciego znaku itp.

Oczywiście nie będziemy tego robić ręcznie, tylko pomożemy sobie odpowiednim kodem javascriptowym, który całość zautomatyzuje. Przyjmujemy założenia:

  • Na serwerze napastnika (192.168.13.37) zostanie wystawiona strona HTML, w której znajdzie się kod JS automatyzujący atak,
  • Serwer napastnika będzie też przyjmował połączenia zwrotne z wartościami tokenów wydobytych dzięki CSS-om. Zakładamy, że połączenie zwrotne będą wykonywane do URL-a typu /token/:token, np. jeśli wyciągamy drugi znak tokena, to do serwera może trafić zapytanie pod adres /token/6b, co oznacza, że pierwsze dwa znaki tokena to 6b.
  • Komunikacja między serwerem przyjmującym połączenia zwrotne, a kodem JS będzie odbywała się przez ciasteczka. To znaczy: jeśli do serwera trafi połączenie zwrotne z informacją, że pierwsze dwa znaki tokenu to „6b”, wówczas zostanie ustawione ciasteczko: „token=6b”. Kod JS będzie regularnie sprawdzał czy ciasteczko zostało ustawione – jeśli tak, to użyje jego wartości do wygenerowania nowego CSS-a w celu wydobycia kolejnego znaku tokena.

Powyższy opis może wydawać się nieco zawiły, ale powinien wyjaśnić się po zobaczeniu kodu :)

Na potrzeby przykładu zakładam, że część serwerową napiszemy w JS z użyciem NodeJS. Utwórzmy więc w dowolnym katalogu na maszynie wirtualnej plik package.json o następującej zawartości:

Następnie w tym samym katalogu użyjmy polecenia:

Dzięki temu zostaną automatycznie pobrane z serwera wszystkie zależności niezbędne do uruchomienia serwera. Część serwerowa musi odpowiadać na tylko trzy zapytania http:

  • /index.html – serwowany będzie plik index.html z tego samego katalogu,
  • /cookie.js – serwowany będzie plik biblioteki js-cookie, która umożliwia przeprowadzanie wygodnych operacji na ciasteczkach z poziomu JS,
  • /token/:token – pod tym adresem przyjmowane będą połączenia zwrotne z kolejnymi znakami tokena. W odpowiedzi ustawiane będzie ciasteczko „token” o tej samej wartości, która została przekazana do serwera.

Utwórzmy plik index.js, który będzie realizował te wszystkie funkcje:

Teraz potrzebujemy przygotować odpowiedni plik HTML, w którym tak naprawdę wydarzy się cała magia i wykradniemy wszystkie kolejne znaki tokena. Patrząc na razie dość wysokopoziomowo na problem, który chcemy rozwiązać to wiemy następujące rzeczy:

  • Chcemy wydobyć token składający się z 32 znaków z zakresu 0-9a-f,
  • Mamy stronę, która jest podatna na wstrzyknięcie CSS-ów: możemy się do tej strony odwoływać z poziomu elementu <iframe> w HTML-u.

Sam atak będzie składał się z następujących kroków:

  1. Jeśli długość tokena, który na razie udało nam się wydobyć jest mniejsza niż oczekiwana, wykonujemy poniższe operacje,
  2. Czyścimy ciasteczko token zawierające ew. wcześniejsze wyekstrahowane dane,
  3. Tworzymy element iframe, w którym odwołujemy się do podatnej strony z uwzględnieniem odpowiedniego kodu CSS, który pozwoli nam wydobyć kolejny znak tokena,
  4. Czekamy aż połączenie zwrotne do serwera napastnika ustawi nam ciasteczko token,
  5. Jak ciasteczko zostanie ustawione, ustawiamy je jako aktualną znaną wartość tokena i wracamy do punktu 1.

Na poziomie samego HTML-a możemy powyższe rozumowanie zapisać następująco:

W kolejnym kroku zaimplementujmy kolejne funkcje wykonujące nasz atak. W pierwszej kolejności czyścimy ciasteczko z tokenem. Ta operacja jest bardzo prosta:

Korzystamy po prostu z biblioteki js-cookie i usuwamy ciasteczko token.

Dalej musimy przypisać odpowiedni adres URL do elementu <iframe>:

I oczywiście zaimplementować funkcję generującą odpowiedniego CSS-a. Ta funkcja po prostu iteruje po wszystkich możliwych znakach w tokenie (czyli 0-9a-f) i generuje odpowiednie reguły w CSS:

Ostatecznie – musimy zaimplementować funkcję oczekującą na ustawienie ciasteczko token przez połączenie zwrotne. Skorzystamy tutaj z mechanizmu Promise w JS by zbudować funkcję asynchroniczną: nasz kod będzie sprawdzał co 50ms czy ciasteczko zostało ustawione; a jeśli tak, to funkcja natychmiast zwróci wartość.

Finalnie kod realizujący atak wygląda następująco:

Zapiszmy go pod nazwą index.html w tym samym folderze, w którym znajduje się index.js, a następnie wywołajmy polecenie:

Teraz z poziomu przeglądarki wystarczy już tylko wejść na http://192.168.13.37:3000/index.html i patrzeć jak wykradamy kolejne znaki tokenu :)

W narzędziach deweloperskich przeglądarki z prawej strony wyraźnie widać naprzemiennie wykonywane zapytania: najpierw zawierające wstrzyknięcia CSS, a potem połączenie zwrotne do serwera napastnika z wartością tokenu.

Podsumowując: jeśli mamy na stronie internetowej wstrzyknięcie kodu CSS, to możemy wydobyć z niej dowolne dane umieszczone w atrybutach tagów HTML-owych wykorzystując selektory typu:

Wydobycie tokena z zawartości strony

W poprzednim rozdziale, selektory CSS ograniczały nas do samych atrybutów. Mogliśmy zidentyfikować element na podstawie początku wartości atrybutu, ale nie możemy zrobić tego samego już dla tekstu umieszczonego w samym tagu – CSS po prostu nie ma selektorów takiego typu. Można więc zadać sobie pytanie: w jaki sposób wydobyć token umieszczony wewnątrz tagu <script>? Np. w kodzie takim jak poniżej:

Uprzedzając fakty: taki atak jest oczywiście możliwy, jednak jest o wiele bardziej skomplikowany i wymaga więcej przygotowania i poznania więcej teorii. Ale dzięki temu jest o wiele bardziej satysfakcjonujący :-). Tym razem składniki, których będziemy potrzebować do wykonania ataku, to definiowanie własnych fontów z ligaturami i stylowanie pasków przewijania.

Zacznijmy zatem od ligatur. Czym jest ligatura? Najkrócej mówiąc: ligatura w foncie jest sekwencją co najmniej dwóch znaków, która ma swoją reprezentację graficzną. Prawdopodobnie najczęściej spotykaną ligaturą w fontach szeryfowych jest sekwencja „fi”. Na obrazku poniżej widać litery „f” oraz „i” oddzielone spacją, a poniżej te same litery napisane bezpośrednio po sobie. Wyraźnie widać, że w drugiej linii mamy inną reprezentację graficzną sekwencji tych dwóch liter – daszek litery „f” połączony jest z kropką nad „i”. Ligatur nie należy mylić z kerningiem: kerning określa tylko odległości pomiędzy literami w foncie, z kolei ligatura jest całkowicie niezależnym glifem (symbolem graficznym) danej sekwencji znaków.

Standardowy przykład ligatury: sekwencja liter "f" oraz "i"

Standardowy przykład ligatury: sekwencja liter „f” oraz „i”

Z pomocą dodatkowego oprogramowania typu np. fontforge możemy sobie tworzyć własne fonty – a w nich własne ligatury. Fontforge jest dość rozbudowanym narzędziem do tworzenia fontów; my natomiast wykorzystamy go do jednej operacji: będziemy zamieniać fonty z formatu SVG na WOFF. Jest to konieczne, ponieważ przeglądarki zaprzestały wsparcia dla formatu SVG w fontach (stąd konieczność użycia formatu WOFF), natomiast z ludzkiego punktu widzenia, definiowanie fontów w formacie SVG jest zdecydowanie najwygodniejsze. Na maszynie wirtualnej, do której plik vagrantowy podałem we wcześniejszym fragmencie tekstu, FontForge jest już zainstalowany.

FontForge pozwala na definiowanie skryptów do wykonywania konwersji pomiędzy różnymi formatami fontów. Przygotujmy plik o nazwie script.fontforge o następującej zawartości:

Skrypt można następnie wywoływać w następujący sposób:

W wyniku wykonania skryptu zostanie utworzony plik o nazwie <plik>.woff. W ten prosty sposób utworzyliśmy sobie prosty konwerter pomiędzy formatami fontów ;-)

Zobaczmy więc jak może wyglądać definicja fontu w SVG. Poniżej jest przykład prostego fonta, w którym wszystkie małe litery alfabetu łacińskiego nie mają przypisanego żadnego symbolu graficznego i ich szerokość wynosi 0 (atrybut: horiz-adv-x=”0″), natomiast jest zdefiniowana także ligatura sekurak, która wprawdzie też symbolu graficznego nie ma, natomiast jest znakiem bardzo szerokim.

Spróbujmy teraz sposób zachowania się tego fonta zobaczyć na przykładzie prostej strony: mamy jedno pole typu <input> a poniżej element typu <span>, do którego jest przepisywana wartość pola <input>. W elemencie <span> ustawione jest niebieskie tło oraz font utworzony na podstawie powyższego pliku SVG.

Zobaczmy co się dzieje. Gdy wpisuję cyfry – one wyświetlają się normalnie, ponieważ w żaden sposób nie są zdefiniowane w foncie. Gdy używam jakichkolwiek liter – nic się nie wyświetla: litery nie mają symbolu graficznego ani jakiejkolwiek szerokości znaku. Gdy jednak wpisuję słowo „sekurak”, wyraźnie widać, że niebieskie tło się wydłużyło: właśnie dlatego, że w foncie została zdefiniowana ligatura dla takiej sekwencji znaków.

Na tym etapie niektórzy z czytelników mogą zacząć się zastanawiać do czego właściwie dążymy… dobra wiadomość jest taka, że jesteśmy już blisko wyjaśnienia sprawy :)

Przejdźmy teraz do zupełnie innego tematu: paski przewijania. W przeglądarkach opartych na WebKicie lub jednym z jego forków, mamy możliwość stylowania pasków przewijania korzystając z CSS-owego pseudoelementu  --webkit-scrollbar. Spróbujmy go zdefiniować w następujący sposób:

W pierwszym bloku body ustawiam dyrektywę white-space na nowrap – dzięki temu jeśli tekst będzie szerszy niż szerokość okna, to nie zostanie złamany do nowej linii – co za tym idzie, wymusi to pojawienie się paska przewijania. Żeby paski przewijania mogły w ogóle być stylowalne, należy wpierw dodać pseudoelement --webkit-scrollbar, dopiero później można stylować konkretny pasek. W trzeciej dyrektywie więc ustawiam styl dla paska poziomego – aby próba pobrania jego tła wykonywała zapytanie do serwera pod kontrolą do napastnika. To co jest tutaj istotne to fakt, że podobnie jak w selektorach, przeglądarki minimalizują wykonywanie zapytań do zewnętrznych serwerów, więc przeglądarka nie spróbuje pobrać tła do poziomego paska przewijania, jeżeli nie będzie takiej potrzeby. Możemy to zobaczyć na przykładzie poniżej.

W momencie, w którym używam ligatury „sekurak” – pojawia się poziomy pasek przewijania i przeglądarka natychmiast wysyła zapytanie do serwera. Wniosek jest taki, że napastnik jest w stanie wykryć, czy ten pasek się pojawia. Kwestią, która jeszcze nam pozostaje, jest właściwe użycie tej informacji.

Wróćmy więc do naszego wcześniejszego przykładu. Mamy token w następującej formie:

Załóżmy, że utworzymy sobie cztery fonty, w których każdy znak alfanumeryczny będzie miał zerową szerokość za wyjątkiem pojedynczych ligatur:

  • W pierwszym foncie dużą szerokość będzie miała ligatura  "0
  • W drugim foncie dużą szerokość będzie miała ligatura  "1
  • W trzecim foncie dużą szerokość będzie miała ligatura  "2
  • W czwartym foncie dużą szerokość będzie miała ligatura  "3

Każdy z tych fontów umieścimy w bardzo wąskim elemencie <iframe> i ostylujemy paski przewijania. Co się więc teraz wydarzy? Dokładnie w jednym z tych iframe’ów pojawi się pasek przewijania, w tym w którym zdefiniowano ligaturę dla: "0. Jaki wniosek dla napastnika? Że pierwszy znak tokena to 0.

Zanim jednak przejdziemy do zaprogramowania praktycznego ataku, musimy zmierzyć się jeszcze z jednym problemem. Przeglądarki traktują fonty jako zasoby o stosunkowo małym priorytecie. Może się więc okazać, że w iframie, w których nie powinno się to wydarzyć, poziomy pasek przewijania pojawi się dosłownie na ułamek sekundy – jak przeglądarka zinterpretuje już styl CSS, ale jeszcze nie zdąży pobrać fonta. Widać to na poniższym filmiku w slow-motion, na którym odświeżam stronę. W trakcie odświeżania na małą chwilę pasek przewijania się pojawił, co spowodowało niepotrzebne wysłanie zapytania do zewnętrznego serwera.

Musiałem zatem rozwiązać problem i tak zmodyfikować swój atak, by mieć pewność, że pasek przewijania nie pojawi się nawet na ułamek sekundy w takim iframie, w którym nie powinien się wyświetlić. Rozwiązaniem okazał się cache! Jeśli używamy Chrome i pobieramy jakiś cache’owalny zasób dwa razy w stosunkowo krótkim czasie, Chrome może użyć tzw. memory-cache. Jeśli tylko dane znajdują się w memory-cache’u to czas ich ładowania schodzi z kilku milisekund do kilkudziesięciu mikrosekund (widać to na rysunku poniżej).

Pobieranie danych z memory-cache to czas rzędu mikrosekund

Pobieranie danych z memory-cache to czas rzędu mikrosekund

Zatem by mieć pewność, że dany font zostanie pobrany z memory-cache, muszę wcześniej utworzyć iframe, gdzie odwołam się do niego, a w odpowiedzi serwera dodam nagłówki cache’ujące. Okazuje się – niestety – że Chrome skorzysta z memory-cache tylko wtedy jeśli dany zasób był pobrany z tego samego originu oraz w takim samym kontekście (tj. nie mogę pobrać fonta jako obrazka by go sobie cache’ować). Oznacza to, że przed wykonaniem próby wydobycia tokenu, muszę wysłać jeszcze jedno zapytanie z tak zdefiniowanym stylem, by mieć pewność, że zostanie scache’owany.

Zastanówmy się jeszcze przez chwilę w jaki sposób atak można uczynić bardziej wydajnym. Najprostszym możliwym wariantem wydaje się taki atak, w którym tworzymy szesnaście iframe’ów i w każdym z nich definiujemy ligaturę dla jednego możliwego znaku tokena (czyli 0-9a-f). Oznacza to, że dla każdego kolejnego znaku, który chcemy wyciągnąć musimy utworzyć szesnaście fontów i utworzyć szesnaście iframe’ów. Może to spowodować całkiem spory narzut na nasz atak. Zamiast tego, spróbujmy użyć metody „dziel i zwyciężaj”:

  1. W pierwszym kroku przygotowujemy dwa fonty: w jednym z nich zdefiniowane są ligatury dla:  "0"1"2"3"4"5"6"7, a w drugim dla:  "8"9"a"b"c"d"e"f.
  2. Pasek przewijania wyświetli się przy dokładnie jednym z tych fontów. Zakładając, że to będzie ten pierwszy zestaw, to musimy go następnie podzielić na dwa fonty: w pierwszym ligatury dla: "0"1"2"3, a w drugim dla: "4"5"6"7.
  3. I tak dalej, aż będziemy mieli dwa fonty z pojedynczymi ligaturami, co pozwoli nam wydobyć konkretny znak tokena.

Przygotowanie Proof-of-Concept ataku

Po stronie serwera będziemy potrzebowali jedynie endpointa, który wygeneruje nam fonta z odpowiednimi ligaturami oraz endpointa do otrzymania informacji jakie znaki mogą występować na danej pozycji tokena. Zacznijmy więc od zaprogramowania tej części.

Poniżej plik package.json:

Po uruchomieniu polecenia „npm install” w tym samym katalogu, w którym znajduje się plik package.json, automatycznie zostaną pobrane wszystkie zależności niezbędne do działania kodu.

Funkcja generująca fonta musi przyjmować tylko przedrostek (prefix) dla którego ma utworzyć ligatury oraz z jakich znaków te ligatury ma utworzyć. Wykorzystamy bibliotekę js2xmlparser, która pozwala wygenerować plik XML na podstawie JSON-a (w ten sposób więc zbudujemy fonta w SVG), a następnie wykorzystamy fontforge, by zamienić SVG na WOFF.

Następnie zaprogramujemy endpoint przyjmujący połączenie zwrotne i serwujemy statycznie js-cookie oraz index.html. Poniżej pełny kod pliku serwerowego index.js:

Od strony JavaScriptu przeglądarkowego, musimy przeprowadzić następujący atak:

  1. Mamy token o znanej długości (32 znaki) i znanym zestawie znaków (0-9a-f) i wszystkie operacje poniżej wykonujemy tak długo, dopóki wyekstrahowany token jest krótszy niż oczekiwany.
  2. Metodą „dziel i zwyciężaj” dzielimy możliwy zestaw znaków dla danego znaku tokena na dwa i przygotowujemy dwa fonty z odpowiednimi zestawami ligatur.
  3. W pierwszej kolejności upewniamy się, że fonty są w cache’u nim przeprowadzimy dalsze ataki.
  4. Tworzymy dwa iframe’y odwołujące się do dwóch różnych fontów. W dokładnie w jednym z nich powinien wyświetlić się pasek przewijania.
  5. Połączenie zwrotne z paska przewijania ustawia ciasteczko z informacją, przy którym zestawie znaków się on pojawił. Jeśli nadal istnieje więcej niż jeden możliwy znak – wróć do punktu 2.
  6. Jeśli wiadomo jaki jest następny znak tokenu: dopisujemy go do tokenu i wracamy do punktu 1.

Poniżej zatem pełny, okomentowany kod przeprowadzający atak :)

A na żywo ten atak prezentuje się tak:

Podsumowanie

W artykule pokazałem dwa sposoby, w jakie tak niepozorna akcja jak wstrzyknięcie własnego treści CSS do strony, może skutkować możliwością kradzieży treści ze strony – na przykładzie wydobywania tokenów CSRF. Pierwszy, stosunkowo łatwy sposób dotyczył tokenów zaszytych w atrybutach; drugi zaś pozwolił na wydobywanie właściwie dowolnej treści ze strony: w bardziej skomplikowany sposób, z użyciem generowania własnych fontów oraz stylowania pasków przewijania w Chromie.

Wnioski z tego są takie, że o ile wstrzyknięcie własnych stylów CSS nie daje tak potężnych możliwości ataku jak XSS, ale jednak pozwala wyrządzić realne szkody użytkownikowi w kontekście danej aplikacji webowej.

Michał Bentkowski, prowadzi warsztaty z bezpieczeństwa aplikacji, wyjaśniając na nich również prostsze – niż opisane w tekście – tematy :-)

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Dobra rada

    Chciałbym tylko napomknac, ze w pierwszym przypadku to nie jest token tylko hash. Token z zasady jest jednorazowy i zmienia sie z kazdym przeladowaniem strony. Dlatego ten atak nie moze sie powiesc na tokeny. Drugiej czesci nie czytalem bo szkoda juz mi bylo na to czasu.

    Odpowiedz
  2. Okej. A teraz pokażcie pięć prawdziwych stron, na których można tak wstrzyknąć CSS. Bo atak nie wygląda na ani trochę praktyczny.

    Odpowiedz
  3. Marcin

    „Tego fonta”? Litości.. Tego fontu! Pisz lepiej po angielsku.

    Odpowiedz
  4. Florian

    Chwileczkę… u mnie to nie działa dla tagu script (nawet z display:table) i szczerze powiedziawszy nie wyobrażam sobie, żeby tag script miał jakikolwiek wpływ na renderowanie strony (bez wykonania jego treści)… przecież ten tag nie jest wizualnym elementem… Czy coś pominąłem?

    Odpowiedz
    • Florian

      Sprawdziłem ponownie – faktycznie jeśli przed tagiem script jest coś innego niż koniec innego tagu – działa… ale to definitywny bug w przeglądarce.

      Odpowiedz
      • Michał Bentkowski

        To zakładane działanie przeglądarek. Niektóre tagi HTML-owe mają ustawione jakieś domyślne style w przeglądarce: np. w przypadku tagu script jest to „display: none”, natomiast wszystkie takie właściwości można nadpisywać.

        Podobnie jest też z tagiem style. Poniżej najprostszy przykład edytora CSS:

        https://jsbin.com/midorexufa/edit?html,output

        Do tagu style dodałem contenteditable i można edytować styl i na żywo oglądać zmiany ;)

        Odpowiedz
  5. Dziadu z Lasu

    Nie łapię. W drugim przypadku zawartość zmiennej TOKEN ze script jest umieszczana w DOM? Co mają fonty i ligatury do treści dokumentu w tagu script?

    Odpowiedz
  6. wk

    Niesamowite :O

    Odpowiedz
  7. LeńZieeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeew

    Po co się tak męczyć żeby „ukraść” jakieś losowe dane ze swojej maszyny wirtualnej?

    Odpowiedz
  8. Jednym słowem

    A script {display: block} tu nie pomoże jeszcze bardziej?

    Odpowiedz

Odpowiedz