FRONT-END SECURITY SZYMON GRZYBOWSKI NSENSE POLSKA S.A.
KIM JESTEM? absolwent PP, systemy rozproszone i sieci komputerowe security consultant przez ostatnie 2 lata bezpieczeństwo aplikacji webowych i mobilnych penetracyjne testy bezpieczeństwa audyty bezpieczeństwa serwerów reverse engineering aplikacji mobilnych
AGENDA Cross-site scripting reflected persistent DOM-based Content Security Policy Cross-site request forgery Cross-origin resource sharing
DLACZEGO AKURAT TE? (1) XSS Google Bug bounty - 100$-7.500$ Twitter - up to 1400$ PayPal - 100$-750$ Facebook - 500$+
DLACZEGO AKURAT TE? (2) CSRF Google - 100$ - 7.500$ PayPal - 0-750$ Twitter - up to 1400$ Facebook - 500$+
CVEDETAILS.COM 2014 XSS - 1107 CSRF - 263 Info leakage - 2104 2015 XSS - 104 CSRF - 38 Info leakage - 26
CROSS-SITE SCRIPTING Definicja Atak na aplikacje wykorzystujące technologie internetowe, polegający na osadzeniu w treści HTML kodu (zazwyczaj JavaScript), wykonywanego w momencie wyświetlenia złośliwej treści ofierze.
3 MIEJSCE W OWASP TOP 10
W PRAKTYCE?
JEDEN Z NAJPOPULARNIEJSZYCH ATAKÓW WEBOWY CENZIC REPORT 2014
ALE RÓWNIEŻ MOBILNY (ANDROID)* WebView
ALE RÓWNIEŻ MOBILNY (IOS) * UIWebView
TYPY XSS
REFLECTED w parametrach, nagłówkach... http://google gruyere.appspot.com/128972877451/%3cscript%3eprompt(1)%3c/sc Payload %3Cscript%3Eprompt(1)%3C/script%3E
DLACZEGO? (1) gruyere.py def _DoBadUrl(self, path, cookie, specials, params):... self._senderror('invalid request: %s' % (path,), cookie, specials, param... def _SendError(self, message, cookie, specials, params, new_cookie_text=no... self._sendtemplateresponse('/error.gtl', specials, params, new_cookie_te
DLACZEGO? (2) error.gtl... [[if:_message]] <div class='message'>{{_message}}</div> [[/if:_message]]...
PERSISTENT (1) zapisywany na serwerze GET /128972877451/newsnippet2?snippet=%3Cimg+src%3Dx%3Aalert%28alt %29+onerror%3Deval%28src%29+alt%3D%22akai 2015%22%3E HTTP/1.1 Host: google gruyere.appspot.com
PERSISTENT (2) Payload <img src=x:alert(alt) onerror=eval(src) alt="akai 2015">
DOM-BASED aka type-0 XSS podatność front-end wykonanie złośliwego kodu wynika z dynamicznych zmian w DOM
DEMO https://public-firing-range.appspot.com var payload = window.location.hash.substr(1); window.location.assign(payload);
WEKTOR ATAKU najczęstszy wektor ataku to parametry URL po # /address/location.hash/assign#javascript:alert(5) ale nie tylko http://public firing range.appspot.com/redirect/ parameter?url=data:text/html;base64,phnjcmlwdd5hbg VydCgxMTEpPC9zY3JpcHQ%2b
DLACZEGO TAKI GROŹNY? narzędzia istnieją, ale słabo sobie radzą coraz większa popularność Rich JavaScript Applications zawartość po #nie jest wysyłana do serwera, brak logów
ALE TRZY TYPY TO NIE WSZYSTKO
MNÓSTWO SPOSOBÓW WSTRZYKIWANIA CSS-based SVG-based XHTML-based UTF-7 po wstrzyknięciu tagu META ładowane z local/session storage przez niezabezpieczone API
<img/src="xyz.jpg"alt="xyz"> ORAZ OBEJŚĆ FILTRÓW (1) bez białych znaków
ORAZ OBEJŚĆ FILTRÓW (2) mało znane tagi <isindex type=image src=1 onerror=alert(1)>
ORAZ OBEJŚĆ FILTRÓW (3) proste kodowanie data:text/html;base64,phnjcmlwdd5hbgvydcgwktwvc2nyaxb0pg==
ORAZ OBEJŚĆ FILTRÓW (4) lub bardziej wyszukane korzystające z właściwości JS $=~[];$={ :++$,$$$$:(![]+"")[$], $:++$,$_$_:(![]+"")[$],_$_:++$, $_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$ :++$, $_$:++$,$$ :({}+"")[$],$$_:++$,$$$:++$,$ :++$,$ $:++$};$.$_=($. $_=$+"")[$.$_$]+($._$=$.$_[$. $])+($.$$=($.$+"")[$. $])+((!$)+"") [$._$$]+($. =$.$_[$.$$_])+($.$=(!""+"")[$. $])+($._=(!""+"")[$._$_] )+$.$_[$.$_$]+$. +$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$. +$._+$.$+$. $$;$.$=($. )[$.$_][$.$_];$.$($.$($.$$+"\""+$.$_$_+(![]+"")[$._$_]+$. $$$_+"\\"+$. $+$.$$_+$._$_+$. +"(\\\"\\"+$. $+$. $+$. +$.$$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$._$+",\\"+$.$ +$. +"\\"+$. $+$. $+$._$_+$.$_$_+"\\"+$. $+$.$$_+$.$$_+$.$_$_+"\\"+$. $+$._$_+$. _$$+$.$$ +"\\"+$. $+$.$$_+$._$_+"\\"+$. $+$.$_$+$. $+"\\"+$. $+$. $$_+$. +$. +"\\\"\\"+$.$ +$. +")"+"\"")())();
OBRONA dobre i sprawdzone frameworki i bilbioteki walidacja wejścia i filtrowanie wyjścia konfiguracja: serwerów aplikacyjnych, filtrów, bibliotek, frameworków świadomość, które komponenty są niebezpieczne
PRZYKŁADY.NET - AntiXSS lub System.Web.Security.AntiXss od 4.5 Uwaga: e.g Html.Raw(...) w Razor Python/Django - domyślnie auto escaping, Uwaga: ale przypadki szczególne Django AngularJS - domyślnie encoduje lub można użyć $ngsanitize Uwaga: ale przypadki szczególne AngularJS NodeJS - e.g. Caja-HTML-Sanitizer Java spring MVC - konfiguracja w web.xmllub atrybut
ĆWICZENIA Google Gruyere Google Public Firing Range HTML5 Security
CONTEN SECURITY POLICY (CSP) Definicja Mechanizm instruujący przeglądarkę kliencką jakie zasoby i skąd mogą być pobrane lub wykonywane. Działa na zasadzie black/white listy.
dodatkowe nagłówki HTTP głównie Content Security Policy w Firefox i Chrome ale również CO NOWEGO? X Content Security Policy X WebKit CSP Firefox do 23, Chrome do 25, a w IE 10 (częściowa implementacja)
PRZYKŁAD - HTTP RESPONSE Content Security Policy: default src 'self' https://example.com https://example.net; connect src 'none'; Content Security Policy: connect src https://example.com/; script src https://example.com/
PRZYKŁAD - TAGI META lub w tagach meta <meta http equiv="content Security Policy" content="script src 'self'">
W PRAKTYCE? dodatkowa warstwa podczas ochrony przed XSS kontrola nad ładowanymi zasobami blokowanie zewnętrznych skryptów, w tym inline jeśli dobrze skonfigurowane i wspierane, może w znaczny sposób zwiększyć bezpieczeństwo
default src script src object src style src img src media src frame src font src connect src form action sandbox script nonce plugin types reflected xss report uri GRANULARNOŚĆ
<!doctype html> <html ng app ng csp>...... </html> PRZYKŁAD - ANGULARJS
PRZYKŁAD - ASP.NET MVC public class ContentSecurityPolicyFilterAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterco { var response = filtercontext.httpcontext.response; response.addheader("content Security Policy", "script src 'self'") response.addheader("x WebKit CSP", "script src 'self'"); response.addheader("x Content Security Policy", "script src 'self' base.onactionexecuting(filtercontext); } }
PRZYKŁAD - RUBY https://github.com/twitter/secureheaders ::SecureHeaders::Configuration.configure do config... config.csp = { :default_src => "https: self", :frame_src => "https: http:.twimg.com http://itunes.apple.com", :img_src => "https:", :report_uri => '//example.com/uri directive' } end class ApplicationController < ActionController::Base ensure_security_headers end
RÓWNIEŻ INNE TECHNOLOGIE nodejs RoR Django etc.
PROBLEMY kompatybilność Android 4.4+, IE10/11 inne nagłówki Opera Mini nie wspiera CSP 1.1 vs CSP 1.0 koszty utrzymania bezpiecznej polityki
CROSS-SITE REQUEST FORGERY (CSRF) Definicja Atak, w którym przeglądarka nieświadomej ofiary, wykonuje akcję w jej imieniu w atakowanej aplikacji.
8 MIEJSCE W OWASP TOP 10
SCHEMAT ATAKU złośliwa strona zwiera formularz (lub wiele) atakujący przekonuje ofiarę do odwiedzenia złośliwej strony ofiara będąc zalogowana w podatnej aplikacji odwiedza złośliwą stroną przeglądarka wykonuje zapytanie do serwera serwer często nie rozróżnia skąd pochodzi zapytanie zapytanie zmienia stan (email, hasło, dodaje komentarz, robi transfer pieniędzy)
DEMO http://www.fauxbank.co.uk/account
CSRF <form name="f" action="http://www.fauxbank.co.uk/transfer" method="post"> <input type="hidden" name="submitted" value="1" /> <input type="hidden" name="accountto" value="34534523902" /> <input type="hidden" name="amount" value="6" /> <input type="hidden" name="submit" value="transfer" /> <input type="submit" value="submit request" /> </form>
OBRONA (1) nagłówek HTTP ale: GET /index.html HTTP/1.1 Host: example.com Referer: http://example.com w niektórych przypadkach można zespoofować czasami nagłówki są wycinane, żeby dane nie wyciekały sprawdzanie tylko początku domeny (e.g. example.com.attacker.com)
OBRONA (2) nagłówek HTTP Origin tokeny anti-csrf wbudowane we frameworki, których jednak często nikt nie używa...
OBRONA - PRZYKŁADY
.NET MVC (1) View <div> @using (Html.BeginForm("", "api/values", FormMethod.Post)) { @AntiForgery.GetHtml() <button id="..." name="...">...</button> } </div> @Html.AntiForgeryToken() lub w Razor
[ValidateAntiForgeryToken] public ViewResult DoAction() {... }.NET MVC (2) Controller code
ANGULARJS framework szuka cookie ustawionego przez serwer o nazwie XSRF TOKEN do wszystkich requestów wykonywanych w JavaScript dodaje haeder X XSRF TOKEN serwer sam musi zadbać o generowanie i walidowanie tokenów
RUBY ON RAILS W kontrolerze class ApplicationController < ActionController::Base protect_from_forgery with: :exception skip_before_action :verify_authenticity_token, if: :json_request? protected def json_request? request.format.json? end end RoR CSRF
TOKENY OK, ALE? jeśli istnieje XSS, to prawie zawsze można obejść token wielkorotnie token może być ponownie użyty po dłuższym czasie aplikacje mogą sprawdzać czy token jest ważny, a nie czy jest ważny dla danego użytkownika
O CZYM PAMIĘTAĆ? w CSRF można wykorzystać zarówno requesty typu GET, jak i POST, a czasem da się również wysłać JSON'a nagłówki Refereri Originnie są wystarczające wielopoziomowe kreatory również są podatne na te ataki
CROSS-ORIGIN RESOURCE SHARING (CORS - HTML5) Definicja Mechanizm pozwalający na współdzielenie zasobów pomiędzy serwerami w różnych domenach.
PORÓWNANIE DO CROSSDOMAIN.XML (Flash/Silverlight) Cross Origin Requests pozwala na lepszą granularność, gdyż każda odpowiedź z serwera musi zawierać określony nagłówek interpretowany przez przeglądarkę.
ALE? To developerzy są odpowiedzialni, jakie zasoby są dostępne dla innych domena, a jakie nie.
CO NOWEGO I CO TO ZNACZY? nowe nagłówki HTTP Access Control Allow Origin: http://foo.example Access Control Allow Methods: POST, GET, OPTIONS Access Control Allow Headers: X REQUIRED HEADER Access Control Allow Credentials: true XMLHttpRequestpomiędzy różnymi domenami możliwy (luźniejsze podejście do Same-origin policy)
CORS W AKCJI? http://arunranga.com/examples/access-control/
NAJPOPULARNIEJSZY PROBLEM... HTTP/1.1 200 OK... Access Control Allow Methods: POST, GET, OPTIONS Access Control Allow Origin: *... wszystkie domeny mogą żądać zasobów ze zdalnego serwera eksfiltracja danych z sieci wewnętrznych
PODSTAWOWY ATAK? 1. W sieci wewnętrznej znajduje się aplikacja używająca Access Control Allow Origin: * 2. Atakujący nie ma dostępu do tej aplikacji. 3. Ofiara odwiedza złośliwą stroną atakującego. 4. JavaScript na stronie żąda zasobów z serwera wewnętrznego. 5. Przeglądarka ofiary wykonuje zapytania cross-origin do wewnętrzych zasobów i przesyła dane do serwera atakującego.
BARDZIEJ SKOMPLIKOWANY? 1. W sieci wewnętrznej znajduje się aplikacja internal.example.com 2. Aplikacja ta ufa aplikacji external.example.com i definiuje Access Control Allow Origin: external.example.com Access Control Allow Credentials: true 3. Aplikacja external.example.com jest podatna na atak XSS. 4. Ofiara odwiedza link ze wstrzykniętym XSS na stronie external.example.com 5. Atakujący w XSS exfiltruje dane, używając zapytań crossorigin, w kontekście uwierzytelnionej ofiary.
DEMO http://jsfiddle.net/xk89qyru/
WNIOSKI? Nie klikajcie we wszystkie linki do JSFiddle :-)
CZY TO WSZYSTKIE ATAKI FRONT-END?
PODSUMOWANIE to tylko część znanych ataków ale dla wielu z nich istnieją mechanizmy obrony podstawa to aktualne frameworki/biblioteki aktualne CMSy i sprawdzone rozszerzenia bezpieczna konfiguracja i security guidelines dla różnych technologii
JAK JESZCZE SIĘ BRONIĆ? przede wszystkim świadomość ataków i odpowiedzialność programisów testy bezpieczeństwa warsztaty bezpiecznego programowania dobra znajomość poszczególnych technologii, konkretnych ustawień i środowisk produkcyjnych współpraca, pomiędzy programistami, dev-ops i działami bezpieczeństwa
DODATKOWO
OGŁOSZENIE (1) interesujesz się tematyką bezpieczeństwa? potrafisz programować obiektowo? znasz podstawowe elementy sieciowe (stos TCP/IP, protokół HTTP)?
ZGŁOŚ SIĘ DO NSENSE poszukujemy programistów i konsultantów PISZ DO Leszek Tasiemski (lta@nsense.net) Dominik Sadowczyk (dsa@nsense.net)
OGŁOSZENIE (2) chcesz wziąć udział w warsztatach bezpieczeństwa? dowiedzieć się jak hackować aplikacje internetowe lub mobilne? obejrzeć lub przygotować prezentację związaną z bezpieczeństwem? być może połączoną z warsztatami? porozmawiać z ludzmi, pracującymi w branży bezpieczeństwa?
WARSZTATY W NSENSE start czerwiec/lipiec 2015 wstępna tematyka zajęć ~ kwiecień 2015 tylko dla studentów WIĘCEJ INFORMACJI DLA ZAINTERESOWANYCH SGR@NSENSE.NET
END