Paweł Goleń, blog

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:

• FBI odpowiedzialne za backdoor w stosie IPSEC (OpenBSD)?,
• OpenBSD skompromitowane do końca świata,

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:

• zmiana MD5 na "coś mocniejszego" niekoniecznie rozwiązuje problem,
• salt nie rozwiązuje wszystkich problemów,

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% 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ć.