Nagłówek X-FRAME-OPTIONS pojawił się w IE8 (IE8 Security Part VII: ClickJacking Defenses) w odpowiedzi na tak zwany clickjacking. Wykorzystanie tego nagłówka jest wciąż niewielkie: Adoption of X-FRAME-OPTIONS header co, przy potencjale jaki w sobie kryje clickjacking, może wydawać się dziwne. Z drugiej strony warto się zastanowić nad scenariuszami wykorzystania clickjacking, samo istnienie podatności to nie wszystko, konieczne jest jeszcze skonstruowanie skutecznego ataku. Tam, gdzie taki atak jest możliwy (i jego scenariusz nie przypomina wirusa albańskiego), nagłówek X-FRAME-OPTIONS warto stosować. W innych przypadkach też, zgodnie z zasadą defence-in-depth, choć... No właśnie, samo ustawienie nagłówka nie wystarczy, musi go jeszcze zrozumieć przeglądarka klienta, a z tym bywa już różnie. Każdy może sprawdzić to na prostym przykładzie: http://bootcamp.threats.pl/lesson15/. Przy okazji warto wspomnieć o Content Security Policy i frame-ancestors, choć to już nieco inna bajka.
Tuesday, October 20. 2009
Monday, October 19. 2009
Podatności stają się oczywiste III
Kilku osobom udało się znaleźć oczywistą podatność (patrz Podatności stają się oczywiste II). Jeśli komuś się jeszcze nie udało, to podpowiem, że podatny jest parametr pRadio, przy czym podatność występuje wtedy, gdy walidator (jedyny walidator to walidacja kodu pocztowego) rozpozna wpisany kod jako nieprawidłowy. Wówczas wartość przekazana w pRadio wypisywana jest w skrypcie JavaScript bez właściwego kodowania znaków specjalnych. Efekt prosty do przewidzenia - XSS. Pora na wyjaśnienia głębszego sensu tego przykładu.
Ciąg dalszy "Podatności stają się oczywiste III" »Sunday, October 18. 2009
OpenBSD 4.6 released
A więc jednak przed 1 listopada: OpenBSD 4.6 released! Więcej informacji na oficjalnej stronie wydania. No to już wiem, co będę robił w najbliższym czasie :)
Tuesday, October 13. 2009
Szukania SQLi i XSSów mam już dość
Ten wpis jest nieco przewrotnym komentarzem do wpisu Przemka:Testowanie logiki biznesowej. Mam dość szukania SQLi i XSSów, bo jest to umiarkowanie efektywne podejście, dodatkowo często uwsteczniające intelektualnie, monotonne i nużące. Skupiając się na tego typu podatnościach można przeoczyć inne, ciekawsze, a przede wszystkim istotniejsze. Można nawet nie mieć czasu, by zabrać się za co ciekawsze kwestie związane z logiką biznesową. W dodatku i tak istnieje spora szansa, że jakiś XSS lub SQLi pozostanie niezauważony, co pokazałem(?) choćby w przykładzie z podatnościami, które stają się oczywiste zaraz po tym, jak się je już znajdzie...
Ciąg dalszy "Szukania SQLi i XSSów mam już dość" »Cache-Control w akcji, czyli "to nie moje dane!"
Wczoraj natknąłem się na praktyczny przykład podatności, która może wynikać z braku właściwie ustawionego nagłówka Cache-Control. Mechanizm wystąpienia podatności jest bardzo prosty: serwer nie oznacza określonej treści zawierającej dane specyficzne dla użytkownika odpowiednim nagłówkiem Cache-Control (lub nie ustawia nagłówka Expires, który wskazuje, że treść już wygasła). Kolejny użytkownik korzystający z tej samej przeglądarki po uwierzytelnieniu widzi nie swoje dane. Dzieje się tak, bo przeglądarka po prostu nie odwołuje się do serwera, by pobrać nową wersję strony. Nie robi tego, bo wersja, którą pobrała poprzednim razem, jest wciąż ważna.
By było ciekawiej, problem objawia się tylko w przeglądarce Internet Explorer 8 (w innych wersjach nie sprawdzałem). W przypadku Firefox, Opera i Chrome problem, w tym konkretnym przypadku, nie występuje.