Z dzisiejszych wykładów na Confidence najbardziej podobał mi się The Presence and Future of Web Attacks Multi-Layer Attacks and XSSQLI. Dlaczego akurat ta prezentacja, o tym później. Na pewno warto zapoznać się z zasobem HTML5 Security Cheatsheet. To przy okazji jest częściowa odpowiedź na pytanie, które padło na ostatnim spotkaniu OWASP, czyli "Co zmieni HTML5?".
HTML5 Security Cheatsheet
Ta prezentacja dotyczyła tematu, którym się zajmuje, ale nieco innym jego aspektem. Mario Heideri powiedział (chyba, bo wentylatory trochę przeszkadzały, ale o to chodzi), że (...) he is living in the browser. Zajmuję się testowaniem bezpieczeństwa aplikacji internetowych, ale aplikacje te są w pewnym stopniu specyficzne, nie są to aplikacje Web 2.0. Owszem, pojawiają się w nich modne technologie typu AJAX czy JSON, ale nadal są to aplikacje "tradycyjne". Celem ataku jest przede wszystkim serwerowa część aplikacji, a nie klient.
Jak najprościej wytłumaczyć różnicę? W bankowości elektronicznej opis przelewu jest tekstowy. Możliwość przekazania znaków typu < czy > i wypisanie ich przez aplikację bez właściwego encodingu jest już podatnością, która zwykle prowadzi do XSS. Najlepiej jeśli będzie to stored XSS i będzie można przy jego pomocy zaatakować innego użytkownika, na przykład wysyłając mu przelew z odpowiednim payloadem w tytule.
Nie we wszystkich aplikacjach jest to takie oczywiste. Jako przykład wykorzystam tu blip.pl, ale spokojnie, nie będę go hakował :) Chodzi mi po prostu o pokazanie pewnej funkcjonalności, w tym wypadku niech będzie to Profil -> Wygląd -> Zmień szablon. Użytkownik otrzymuje możliwość spersonalizowania w pewnym zakresie swojego profilu, który później wygląda na przykład tak (akurat u mnie zmiany są niewielkie): http://pgolen.blip.pl/. Aplikacja nie pozwala jednak na wstawienie dowolnej zawartości, jakiś filtr kontroluje, czy użytkownik nie wstawił czegoś szczególnie niebezpiecznego. Co zrobić w takiej sytuacji? Oczywiście - spróbować obejść filtr, czyli znaleźć taki wektor, który nie jest wychwytywany przez filtr, a zostanie prawidłowo zrozumiany przez przeglądarkę. Część z tych wektorów bezpośrednio wynika z niedbałej implementacji HTML5. Ich lista dostępna jest we wspomnianej już ściągawce. W ramach ciekawostki z historii mojego bloga: Wykorzystanie data: do wstawienia skryptu.
Ciekawe były również przykłady wykorzystania ataków wielowarstwowych, na przykład wykorzystanie SQLi do obfuskowania kodu JavaScript. Tu warto wspomnieć o Structured client-side storage i o tym, że nawet nie koniecznie trzeba szukać SQLi w aplikacji, można sobie po prostu obsługę zapytań SQL dodać, o ile oczywiście przeglądarka już wspiera odpowiednie funkcje.
ten to strona projektu, z którego korzysta heideri.ch http://code.google.com/p/html5security/
Piotr Konieczny z niebezpiecznik.pl dał też linka : http://www.veracode.com/blog/2010/05/html5-security-in-a-nutshell/
Co do XSS i podobnych problemów współczesnej Sieci ciekawy pogląd na sprawę przedstawił wczoraj Dan Kaminsky razem z próbą wprowadzenia type safety do środowiska webowego. Implementacja trochę odstręczała od użycia, ale można to potraktować jako dopiero pierwszy, roboczy szkic.