Tag: XSS

W niniejszym artykule opiszę trzy XSS-y, które zgłaszałem do Google w tym roku w ramach ich programu bug bounty. Wszystkie z nich miały swoje źródło w możliwości wyjścia z sandboksa w narzędziu Google Caja.

Mechanizm Service Workers został wprowadzony w najnowszych wersjach przeglądarek internetowych, by rozwiązać problem, z którym świat aplikacji webowych boryka się od dawna – mianowicie: jak aplikacja powinna się zachowywać w przypadku utraty połączenia z Internetem. Niniejszy artykuł ma na celu przybliżenie zasad działania Service Workers oraz wskazanie największych zagrożeń związanych z tym mechanizmem, którymi w szczególności powinni być zainteresowani twórcy stron internetowych.

W 2014 roku na Sekuraku (oraz w pierwszym e-zinie) pisaliśmy czym jest Content Security Policy. Była to wtedy młoda technologia utrudniająca eksploatację ataków XSS. Od tego czasu standard mocno się rozwinął. Czy obecna wersja CSP 2.0 jest remedium na nieznane luki XSS? Na jakie problemy można natknąć się podczas wdrożeń CSP?

Persistent XSS na stronie głównej wykopu. Zrobiliśmy małe PoC przygotowując odpowiednią reklamę sekuraka…

Dodawanie plików przez użytkowników web aplikacji wiąże się z wieloma zagrożeniami. Pentesterzy w tym obszarze często szukają luk prowadzących do zdalnego wykonania kodu po stronie serwera. A co gdyby dodanie nowego pliku skutkowało wykonaniem złośliwego skryptu JS? Taką możliwość dają pliki SVG opisujące grafikę wektorową we współczesnych przeglądarkach.

Opis aplikacji utworzonej przez Google – Safen Me Up, która prezentuje nowe, ciekawe podejście do ochrony przed skutkami ataków XSS.

Opis kolejnego XSS-a znalezionego w domenie www.google.com. Tym razem reflected XSS, który da się wykorzystać wyłącznie w Internet Explorerze.

Kilka dni temu na liście dyskusyjnej full disclosure został opublikowany błąd pozwalający na wykonanie XSS-a w kontekście dowolnej domeny w najnowszych wersjach Internet Explorera. Odkrywca błędu, David Leo, zgłosił ten błąd do Microsoftu 13 października 2014, jednak błąd nie jest wciąż poprawiony. Oryginalny PoC (proof of concept) nie był zbyt czytelny,…

Opis błędu XSS w domenie www.google.com. Historia omijania kolejnych przeszkód, by napisać kod wykorzystujący podatność, nie wymagający interakcji użytkownika.

Nikt nie dziwi się tym, że w wielu książkach o bezpieczeństwie można znaleźć przykłady wykorzystania podatności XSS. Jednak ciekawe jest to, że czasem takiego „papierowego” XSS-a można aktywować on-line: zobaczcie na stronę www.safaribooksonline.com: PS Lepiej nie szukajcie książek o OS Command Exec ;-) –ms

W artykule przedstawiam kilka przykładów ataków XSS, których przeprowadzenie jest możliwe ze względu na użycie nietypowych (japońskich) kodowań znaków.

Wykrywanie podatności w aplikacjach internetowych z reguły polega na enumeracji tzw. punktów wejścia, manipulowaniu żądaniami HTTP oraz analizie odpowiedzi. Skuteczność takiego przepływu pracy można zwiększyć dzięki Burp Proxy. Zobaczmy, jak z jego pomocą wykonywać podstawowe testy bezpieczeństwa web aplikacji.

Pośrednik HTTP analizujący ruch między przeglądarką a serwerami WWW jest podstawowym narzędziem pracy testera web aplikacji. Burp Suite – popularne akcesorium bezpieczeństwa skonstruowane wokół funkcji lokalnego proxy – jest narzędziem, koło którego żaden inżynier bezpieczeństwa nie może przejść obojętnie.

Poszukiwanie XSS-ów w ciasteczkach http jest równie uzasadnione, jak w parametrach GET czy POST. Na takie podatności szczególnie narażone są firmy, które korzystają z wielu subdomen do hostowania swoich stron, wówczas XSS z jednej domeny może być eskalowany do innej (potencjalnie o wyższej istotności). Takie poszukiwania to także świetna okazja do rozwinięcia swoich umiejętności.

XSS jest jednym z najczęściej opisywanych błędów bezpieczeństwa aplikacji internetowych. Na Sekuraku podatność miała już swój artykuł, było też kilka tekstów o XSS-ach w Google’u, a nawet o wykorzystaniu ich do ataku DDoS. Dzisiaj ciekawy przypadek, nieoczywistego błędu XSS.