Na spotkaniu SPINu mówiłem między innymi o tym, że błędy związane z bezpieczeństwem powinny być w bazie błędów oznaczane tak, by było wiadomo, że jest to błąd bezpieczeństwa oraz powinny zawierać informację o powodzie tego błędu (w sensie root cause). Dziś mogę przytoczyć kolejny argument za tym, by takie znakowanie błędów bezpieczeństwa prowadzić.
By zamknąć temat przykładu dotyczącego wykorzystania na stronie danych z różnych źródeł jedna krótka uwaga. Teoretycznie “prawidłowo” wstawiony payload XSS powinien wyglądać tak:
Jak to zwykle bywa teoria rozmija się z praktyką. Okazuje się, że większość (wszystkie?) przeglądarek jest dość liberalna i równie ochoczo zinterpretują taki payload:
<img src=“niemamnie” onerror=“alert(/XSS/)”
Każdy może sobie to sprawdzić tutaj: http://bootcamp.threats.pl/lesson09/. Istnieją co prawda dodatkowe różnice między przeglądarkami w przypadku, gdy wspomniany kod HTML jest wstawiany poprzez innerHTML , ale to niech już każdy zainteresowany sprawdzi sobie we własnym zakresie :)
Oryginał tego wpisu dostępny jest pod adresem Bootcamp XXIV: tagów nie trzeba zamykać
Autor: Paweł Goleń
Bardzo podobają mi się takie wykresy, jak ten prezentowany niżej...
A o co chodzi? Po prostu mBank zmienia stronę logowania, ktoś przy okazji domagał się hasła maskowanego, ktoś inny odpisał mu, że to nie jest najlepszy pomysł i podał przy tym link do jednego z moich wpisów na temat haseł maskowanych, których szczerze nie lubię...
Korzystając z okazji przypomnę o swojej prezentacji dotyczącej mechanizmów bezpieczeństwa w bankowości internetowej i ich odporności na ataki z wykorzystaniem malware: Zamiast slajdów z SecDay.
A tak z zupełnie innej beczki, polecam artykuł Racjonalne bezpieczeństwo w epoce mediów.
Oryginał tego wpisu dostępny jest pod adresem Nie ma to jak reklama
Autor: Paweł Goleń
Przed chwilą wróciłem ze spotkania SPINu, na którym miałem okazję mówić różne dziwne rzeczy, mam nadzieję, że ciekawe. Być może efektem ubocznym będzie kilka nowych wpisów na blogu. Po raz kolejny złapałem się na tym, że mówiąc o rzeczach oczywistych dla mnie i mojego środowiska, mogę jednocześnie mówić o rzeczach abstrakcyjnych dla innych. To chyba pokazuje, że musimy się częściej spotykać :)
Ważną rzeczą, którą chciałem przekazać jest to, że bezpieczeństwa aplikacji nie buduje się poprzez jej testowanie i przyklejanie kolejnych łatek w miejscach znalezienia i wskazania błędu. I tylko w tych miejscach. Bezpieczeństwo buduje się przez zmianę procesu tworzenia aplikacji, w którym różne testy bezpieczeństwa to tylko jeden z elementów układanki. Ważny, ale nie jedyny.
Być może spotkamy się po raz kolejny, tym razem na czymś w rodzaju prostych warsztatów. Tymczasem zapraszam do zapoznania się z moim krótkim przewodnikiem po bezpieczeństwie aplikacji internetowych. Od czegoś trzeba zacząć :) Jestem otwarty na wszelkie pytania, a może i w rezultacie pojawią się jakieś kolejne lekcje?
Oryginał tego wpisu dostępny jest pod adresem Po spotkaniu SPINu
Autor: Paweł Goleń
Tekst Co identyfikuje rachunek czyli ile cyfr (nie)wystarczy powstał już jakiś czas temu. Ostatnio temat ten ponownie się pojawił, a to w związku z niezbyt dobrze przyjętym artykułem Inteligo chciało dobrze, a wyszło jak zwykle oraz wpisem jego autora: Do czego jest dany token (polecam komentarze). Poruszany przeze mnie temat kolizji podjął ^rozie, czego rezultatem jest jego wpis Ile cyfr potrzeba, by numer konta był unikatowy? To tak w ramach kilku poczytajek dla zabicia czasu :)
PS: O, i jeszcze to: Bankowość internetowa.
Oryginał tego wpisu dostępny jest pod adresem Ile cyfr (nie)wystarczy II
Autor: Paweł Goleń
Jakiś czas temu pojawiły się zapowiedzi, że Acrobat Reader w kolejnej dużej wersji będzie miał piaskownicę. Pomysł doskonały, ilość błędów w obsłudze plików PDF była w ostatnim czasie zatrważająca. I w końcu pojawił się ten wyczekiwany Acrobat Reader X, co z tym sandboxem?
Całkiem ciekawy temat się z tego robi: Przeterminowana promocja. Dwa ostatnie ciekawe wpisy w temacie tego co jemy i naszych praw jako konsumentów z serwisu socjotechnika.net:
Jak czujecie się w roli konsumenta? Jak smakują wam kupowane przez was produkty? Jak często macie wrażenie, że coś jest produktem X tylko z nazwy i koło prawdziwego X nawet nie leżało?
Oryginał tego wpisu dostępny jest pod adresem A czy TY wiesz, co wkładasz do garnka?
Autor: Paweł Goleń
Ciekawy tekst: Changing Passwords. Przyznam się, że ja nie zmieniam swoich haseł. No, przynajmniej nie wszystkie. Uważam, że w większości przypadków zysk z takiej praktyki nie uzasadnia jej uciążliwości. Tu nawet nie chodzi o pamiętanie zmienionego hasła, pamiętać nie muszę bo korzystam z KeePass. Zmiana kilkudziesięciu haseł trwa.
Zdjęcie prezentowane w poprzednim wpisie moim zdaniem oddaje dość dobrze problem ze znalezieniem równowagi między bezpieczeństwem, a wygodą użytkowania. I nie dotyczy to wyłącznie IT.
Czy ten obraz wymaga komentarza?
Oryginał tego wpisu dostępny jest pod adresem Security vs. usability
Autor: Paweł Goleń