Taka mała refleksja...
Jak teraz zaczyna się spotkanie biznesowe? Wymianą wizytówek... Jak będzie się zaczynać? Od wzajemnego pstrykania fotek swoimi wypasionymi komórkami...
Oryginał tego wpisu dostępny jest pod adresem Przyszłość jest ZŁA!
Autor: Paweł Goleń
Też napiszę kilka słów w temacie, którego dotyczył ten radosny artykuł: FBI zaszyło pluskwy w szyfrowaniu dla serwerów. Od razu dla przeciwwagi trzeba podać coś bardziej rzetelnego:
Przy każdej informacji o wycieku haseł z reguły pojawia się wątek o “słabości” MD5 oraz o tym, że trzeba dodawać salt. Jest z tym trochę jak ze słynnym radiem Erewań. Konkretnie chodzi mi o dwie sprawy:
Dzisiaj kontynuacja cyklu “zrób to sam w weekend”. Tym razem przykład jak szukać błędów typu sql injection (patrz: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) Podobnie jak ostatnim razem wpis nie będzie zawierał jakiejś wiedzy tajemnej. Chcę po prostu pokazać w jaki sposób błędy typu SQLi można w stosunkowo prosty sposób zidentyfikować. Oczywiście przy użyciu tej techniki nie da się znaleźć 100%25 błędów, ale przynajmniej całkiem sporą ich ilość. Nie jest to podejście typu fire and forget , wymaga trochę myślenia, ale to raczej jego zaleta, niż wada. No i każdy może w stosunkowo prosty sposób dostosować to podejście do swoich potrzeb.
Ten wpis nie będzie zawierał jakiejś wiedzy tajemnej. Będzie raczej pokazywał w jaki sposób można podejść do tematu testowania kontroli dostępu. A kontrola dostępu jest bardzo ważnym elementem bezpieczeństwa aplikacji. Jeśli nie jest zrealizowana w sposób konsekwentny i prawidłowy, może się to skończyć takimi informacjami: Poważny błąd w Gadu-Gadu i Gadu Air.
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ń