Paweł Goleń, blog

Zaawansowany data mining

Prezentacja dotycząca zbierania danych ze stron była dla mnie interesująca przede wszystkim w części, która dotyczyła zabezpieczania się przed crawlingiem. Temat jest bardziej istotny, niż się może wydawać. Rzeczywiście istnieje sporo firm, których model biznesowy opiera się na publicznym, darmowym udostępnianiu informacji. Zysk czerpią na przykład z reklam wyświetlanych na swoich stronach. Jeśli ktoś skopiuje takie dane, to może dalej z nich korzystać "za darmo". W tym wypadku "za darmo" oznacza "bez generowania przychodów z reklam dla udostępniającego informacje". Oczywiście to tylko jeden z wielu przykładów dlaczego możliwość crawlingu może być niepożądana.

Autor prezentacji, Jakub Kałużny, sugerował, że jednym ze sposobów ochrony przed crawlingiem może być wymaganie rejestracji użytkownika, najlepiej z jakąś dodatkową weryfikacją. Mam wątpliwości, czy rozwiązanie takie jest rzeczywiście dobre. Sam preferuje korzystanie z serwisów, które takiej rejestracji nie wymagają. Jest to dla mnie uciążliwe, a poza tym traktuję to jako pewnego rodzaju naruszenie mojej prywatności. Nie uważam, by operator Zumi, PKT czy innego FooBar musiał wiedzieć, że aktualnie szukam usługi X. Kwestią otwartą jest to, dla jakiej części potencjalnych użytkowników taka rejestracja będzie barierą "nie do przejścia". Wygoda vs. bezpieczeństwo - to odwieczny konflikt.

Druga szybka uwaga do tej prezentacji. Innym sugerowanym zabezpieczeniem przed crawlingiem było ograniczanie liczby połączeń (w jednostce czasu) na poziomie warstwy TCP. Warto pamiętać, że protokół HTTP ma coś takie, co nazywa się Keep-Alive i pozwala wykonać w ramach jednego połączenia TCP więcej niż jedno żądanie HTTP. Z tego powodu limitowanie ilości połączeń TCP nie przekłada się wprost na limitowanie ilości żądań HTTP. O Keep-Alive warto też pamiętać tworząc lub korzystając z narzędzi wykorzystywanych w trakcie testów bezpieczeństwa (np. fuzzer), szczególnie w przypadku protokołu HTTPS. Keep-Alive drastycznie podnosi ich wydajność. Niestety, niektóre narzędzia wymagają wręcz ustawienia nagłówka Connection: close, co drastycznie wydłuża czas testów. Fiddler na przykład pozwala skonfigurować to zachowanie (opcje Reuse client connections i Reuse connections to servers).

OWASP ASVS – panel dyskusyjny

Panel dyskusyjny miał trochę inną formę, niż się spodziewałem. Przerodził się w prezentację Wojtka dotyczącą ASVS, która dopiero po pewnym czasie przerodziła się w dyskusję. Wynikło to z faktu, że na początku nie bardzo kto na temat ASVS mógł dyskutować. Mimo wszystko punkt ten uważam za udany, choćby z uwagi na popularyzację wiedzy na temat tego standardu. Chyba był również interesujący dla innych uczestników, skoro mimo przeciągnięcia się w czasie o prawie godzinę(!) nie było masowego eksodusu z sali :)

W trakcie dyskusji pojawiło się kilka ciekawych wątków. Jeden z nich dotyczył punktu V5.1 Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows (sekcja: V5 - Input Validation Verification Requirements). Tu myślę, że dobrym odniesieniem będzie 2010 CWE/SANS Top 25 Most Dangerous Software Errors, a konkretnie sekcja CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), ograniczę się do cytatu (sekcja Potential Mitigations):

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.
Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

Było również pytanie (po prezentacji) o wymagania/zalecenia odnośnie kryptografii. Znajdują się one w sekcji V7 - Cryptography Verification Requirements. Tu warto zauważyć, że większość wymagań może być sprawdzona w trakcie przeglądu kodu. Trudno na przykład sprawdzić, w jaki sposób przechowywane są hasła i czy wykorzystywany jest salt. No chyba, że gdzieś przytrafi się SQLi i listę użytkowników i hashy haseł uda się pozyskać :)

W temacie kryptografii ponownie odeślę do Top25, konkretnie do CWE-327: Use of a Broken or Risky Cryptographic Algorithm. Poniższy fragment można sobie wydrukować na kartce i powiesić na ścianie:

Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.
For example, US government systems require FIPS 140-2 certification.
Do not develop your own cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If your algorithm can be compromised if attackers find out how it works, then it is especially weak.
Periodically ensure that you aren't using obsolete cryptography. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong.

Tematy na kolejne spotkania

Wszystkich zainteresowanych tematem bezpieczeństwa aplikacji internetowych (wszystkich, nie tylko (pen)testerów) zapraszam do przyłączenia się do listy dyskusyjnej OWASP Poland i zgłaszania tematów, o których chcielibyście usłyszeć. Usłyszeć, lub opowiedzieć :)

No dobra, komentarz zrobił się trochę dłuższy, niż planowałem na początku...