Aplikacje systemowe można kompilować kompilatorem, który dołoży kanarka, zlinkować z biblioteką, która podmieni funkcje z definicji niebezpieczne na ich bezpieczniejsze odpowiedniki, kernel ma lepiej albo gorzej zaimplementowaną ochronę stosu. Po co to wszystko? Poza marnowaniem kolejnych cykli procesora ;) chodzi o minimalizację ryzyka skutecznego wykorzystania podatności, które nas otaczają.
Co można zrobić dla poprawienia bezpieczeństwa aplikacji webowych bez względu na podatności związane z błędną walidacją danych wejściowych czy iluzorycznym bezpieczeństwie korzystania z szyfrowanych kanałów transmisji? Jak pokazuje świat przeglądarek, można zrobić całkiem dużo. Pytanie tylko co? Jaki da to efekt? Ile to będzie kosztowało? I czy ktoś z tego (s)korzysta?
Atrybuty cookie
Poza takimi jak site, path, expire mamy jeszcze dwa: secure oraz httponly. Secure przyda się w sytuacji kiedy przez cały czas pracujemy z aplikacją webową z wykorzystaniem szyfrowanej transmisji (https) i chcemy obronić się przed atakami typy surfjacking. HttpOnly spróbuje uniemożliwić XSS'om (Javascriptowi) ukraść ciastka.
X-FRAME-OPTIONS
O którym już kiedyś[1] pisałem[2]. Niestety chyba nie zdobył on (nagłówek) popularności[3].
Frame breaker
Nikt nie lubi być w czyjejś ramce. W stosunku do rozwiązania X-FRAME-OPTIONS wspierany jest przez większą rzeszę przeglądarek. Niestety napisanie kawałka kodu w JS, który tak samo zachowa się w każdej przeglądarce aktualnie nie jest takie proste i oczywiste.
Content Security Policy
Stary temat w nowej wersji - narazie w wersji beta. (zapowiada się całkiem ciekawie :-))
Aby powyższe zabezpieczenia zadziałały potrzebna jest odrobina dobrej woli po stronie programisty i/lub administratora. To wszystko dlatego, że wprowadzenie odpowiednich atrybutów dla ciastek czy dodanie nagłówków HTTP można wykonać przez modyfikację kodu aplikacji lub zmiany w konfiguracji serwerów www/load-balancerów.
Jak często rekomendujecie wybrane z powyższych zabezpieczeń?
Jak często się z nimi spotykacie podczas testów bezpieczeństwa?
Subskrybuj:
Komentarze do posta (Atom)
6 komentarze:
Ja się spotykam z httpOnly w każdym raporcie zewnętrznej firmy wykonującej testy penetracyjne na naszych systemach :) W samych systemach spotykam się z httpOnly wtedy, kiedy framework jest odpowiednio nowy co nie jest problemem w ASP.NET, ale w J2EE jest dopiero od wersji 6 w którymś tam patchlevelu (podobnie np. WebSense).
Tak, httpOnly natywnie w J2EE od wersji 6 - http://blip.pl/s/13178659 to dobra wiadomość :) Taki język jak PHP ma to od dawna. Co ciekawe httpOnly można dodawać także na poziomie "lepszego" load-balancera.
Jeśli chodzi o httpOnly czy Secure to jak najbardziej, do tego uwagi odnośnie Path na przykład. Zdarza mi się również sugerować przerzucenie jakiejś potencjalnie bardziej ryzykownej części serwisu pod inny adres, tak, by działało same-origin-policy.
X-FRAME-OPTIONS i podobne nie, choć np. Watcher je (a właściwie ich brak) sygnalizuje. Ale chyba trzeba będzie zacząć, bo udział przeglądarek wspierających te nowinki, zaczyna robić się znaczący.
Tak jak wszyscy powyzej, czyli httpOnly, Secure. Stosujac httpOnly nalezy uwazac, bo jest pare sposobow na wyciagniecie cookie pomimo ustawienia tej flagi.
Co do iframe to najczesciej zalecam 'wyskakiwanie' z ramki.
Jak najbardziej Michale, słuszna uwaga odnośnie httpOnly. Na szczęście coraz lepiej to wygląda w samych przeglądarkach.
W temacie X-FRAME-OPTIONS to nowsze wyniki nadal wskazują na mizerne wykorzystanie tej funkcji:
Adoption of X-FRAME-OPTIONS header.
"Of the TOP 10,000 sites from the Alexa’s list, only 4 sites have the header specified."
Prześlij komentarz