Paweł Goleń, blog

Taka ta pogoda niezdecydowana. Raz słońce, raz deszcz (z lodem). Deszcz na zdjęciu, choć nie do końca to widać. Okolice Obidowca, konkretnie zaraz przy pomniku w miejscu katastrofy lotniczej.

Firma Veracode udostępniła ostatnio pięć przewodników odnośni bezpieczeństwa aplikacji internetowych. Dotyczą one następujących tematów:

• SQL Injection,
• Cross Site Scripting,
• Cross Site Request Forgery,
• LDAP Injection,
• Mobile Code Security,

Choć zwykle unikam na swoim blogu promowania cudzych akcji marketingowych, to w tym wypadku uczynię wyjątek. Przejrzałem te opracowania i muszę przyznać, że choć poruszają podstawowe zagadnienia związane z wymienionymi tematami, to jednak merytorycznie w tym zakresie, który obejmują, są OK. Jeśli dodatkowo popatrzeć na CWE, to podatności/słabości:

• CWE-352: Cross-Site Request Forgery (CSRF),
• CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'),
• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'),

mają tak dużą szansę wystąpienia i wykorzystania, że należy się cieszyć z każdej inicjatywy, która może zmienić ten stan rzeczy. Przy okazji można też sprawdzić, jak te podatności zostały "wycenione" w OWASP Top10 2010 (chodzi mi o Weakness Prevalence oraz Weakness Detectability):

• A1-Injection: (COMMON, AVERAGE),
• A2-Cross Site Scripting (XSS): (VERY WIDESPREAD, EASY),
• A5-Cross Site Request Forgery (CSRF): (WIDESPREAD, EASY),

Przypominam, że na informacje i przykłady dotyczące tych trzech problemów (SQL, XSS, CSRF) można znaleźć również w moim przewodniku po bezpieczeństwie aplikacji internetowych.

Sponsorem tego wpisu jest BP, który zupełnie przypadkowo spowodował, że zacząłem sobie przypominać różne dziwne języki, w których popełniłem choć trochę kodu. Czasami bardzo trochę. Przypominam, że nie jestem (i nie uważam się) za programistę, ale w razie czego coś, co jakoś działa jestem w stanie napisać.

Wyniki kolejnego eksperymentu dotyczącego "przyspieszania" blind sql injection przez zmianę układu znaków, na którym wyszukiwane jest rozwiązanie, czyli kontynuacja wpisów Blind SQL Injection z wykorzystaniem regexpów oraz Szybszy(?) blind sql injection. Tym razem postanowiłem sprawdzić jak układ (kolejność) znaków wpływa na szybkość znajdowania rozwiązania przy "klasycznej" strategii podziału.

Tak, jest to nawiązanie do wcześniejszego wpisu: Blind SQL Injection z wykorzystaniem regexpów. Postanowiłem sprawdzić, czy rzeczywiście uda się zmniejszyć ilość pytań, które trzeba zadać, by odgadnąć słowo. Rezultat: 66976481 63650628. Lepiej?