Do napisania tego posta skłonił mnie ten komunikat. Wynika z niego, że konta w grze są bardzo słabo chronione.

Jak zauważyłem ochrona kont jest słabą stroną wielu aplikacji napisanych w php. Wynika to z faktu, że php nie ma wbudowanych mechanizmów zapewniających ochronę przed atakami typu XSS i SQL Injection. Wszystkie mechanizmy trzeba tworzyć samemu. Można co prawda użyć modułów do Apacha lub włączyć np. użycie magicquotes, ale po pierwsze nie każdy hosting to umożliwia, a po drugie nie samymi cudzysłowami haker żyje.

Łukasz Lach opisał kiedyś sposób ataku na wordpressa. Banalny, prosty i pomysłowy

Czy Java jest bezpieczna

I tak i nie. Z jednej strony specyfikacja kontenerów serwletów i serwerów aplikacji wymusza na ich twórcach implementację odpowiednich mechanizmów, ale z drugiej strony implementacja może być nieprawidłowa. Tak jest w przypadku Tomcata i problemu ze złą obsługą nagłówka „Accept-Language” co może ułatwić potencjalnemu bandycie atak. Problem polega na wywalaniu się przy sekwencji \” w cookie i możliwości wstrzelenia HTML na stronę. Podobnie ma się sprawa z jsp, które mogą wywalić się na sekwencjach cudzysłowów, apostrofów i (back)slashy. Możemy jednak uniknąć problemu stosując Velocity lub xhtml-view z Egg’a.

Troche inaczej ma się sprawa SQL Injection o zabezpieczenie, których trzeba zadbać ręcznie, ale i na to jest sposób. Wystarczy stworzyć filtr, który zamieni niebezpieczne znaki na encje. Później już nic nie musimy robić. Jesteśmy zabezpieczeni.

Niebezpieczeństwa serwerów wieloplatformowych

Mam, a w zasadzie to już miałem, do czynienia z rozwiązaniem polegającym na użyciu w ramach jednego serwera fizycznego zarówno Javy w postaci JBossa jak i php. Niebezpieczeństwo tego rozwiązania polega na tym, że jeżeli kod php jest słabo zabezpieczony to nawet początkujący włamywacz będzie wstanie dowiedzieć się co nieco o naszym serwerze. W jaki sposób? Wystarczy, że znajdzie metodę na wstrzyknięcie własnego kodu do kodu php. Jak już to zrobi to następnym krokiem będzie wypisanie zawartości drzewa katalogów, w tym katalogu WEB-INF. Skutek wiadomy, hasło do bazy, konfiguracja aplikacji i kilka innych ciekawostek może być tam ukrytych.

Jak się bronić?

Po zakończeniu testów warto poddać strony dodatkowym testom bezpieczeństwa. Powinny być one przeprowadzone przez „świeży” zespół testerów, którzy nie spotkali się jeszcze z aplikacją. Będą wstanie wyłapać błędy w zabezpieczeniach. Ponad to warto napisać własne narzędzie, które będą używane zamiast potencjalnie niebezpiecznych domyślnych metod rozwiązywania problemów. Sztandarowym przykładem niech będzie:

<%= request.getParameter("FOO")%>

Zamiast tego należało by użyć własnego narzędzia, które przeanalizuje string z funkcji getParameter i w odpowiedni sposób zabezpieczy jego treść.

Ostatnim elementem jest dokładne przemyślenie architektury aplikacji i hostingu w celu uniknięcia niebezpiecznych połączeń. Jeżeli musimy używać kilku technologii niech dla każdej będzie oddzielny chroot lub serwer. Nie łączmy technologii w jednej funkcjonalności. Nie warto ryzykować, a użycie jakiegoś kodu pośredniczącego w komunikacji jest lepszym rozwiązaniem niż bezpośrednie dogadywanie technologii na jednej maszynie.

Zresztą co byśmy nie zrobili i tak znajdzie się jakiś cwaniak, który znajdzie dziurę i to trzeba zapamiętać