Bezpieczeństwo, nie tylko w świecie Javy
Myślę, że ostatnio ujawniony wyciek danych z serwisu Wykop.pl uświadomił niektórym, jak niebezpieczne może być używanie tego samego hasła w wielu miejscach, z bankiem i Allegro włącznie. Na temat samej administracji Wykopu wypowiadać się za bardzo nie chcę, wszakże ponoć nie kopie się leżącego. Jeśli jednak to prawda, że wyciek nastąpił już jakiś czas temu i w dodatku osoby zarządzające serwisem miały tego świadomość, brak informacji dla użytkowników o tym fakcie to raczej sprawa dla prokuratora i prawników.
Osobną kwestią jest używanie prawdziwych danych produkcyjnych na potrzeby nowej, testowej wersji serwisu. Osobiście nie widzę w tym nic złego (inni widzą). Projektując np. forum internetowe zamiast tysiąca postów z "lorem ipsum" lepiej mieć dostęp choćby do setki wpisów rzeczywistych użytkowników, inwencja niektórych osób może bowiem naprawdę zaskoczyć twórców oprogramowania ;). Oczywiście takie dane muszą zostać oczyszczone z "wrażliwych" informacji (a takimi są chociażby hasła). Całkiem możliwe też, że konieczne okaże się zamazanie danych osobowych, no ale to już też bardziej kwestia prawna. Swoją drogą myślę, że Wykop powinien spodziewać się w najbliższym czasie kontroli z GIODO.
Sprawą, która zwróciła moją uwagę, jest sposób trzymania hasła w systemie Wykopu. Niewiele trzeba, aby zorientować się, że hasła były kodowane za pomocą SHA1. Jest to zabezpieczenie zdecydowanie niewystarczające, chociaż dobrze, że przynajmniej ono zostało wdrożone. To, że istnieją systemy (i to jall... kie duże), które trzymają hasła w postaci jawnej, świadczy tylko o ich twórcach (jednak warto brać poprawkę na to, że w tym wypadku mamy sporo tzw. "legacy code"). To żadna filozofia użyć "salta" w nowo powstających systemach (a takim jest Wykop, to nie jest system bankowy z lat 60-tych, którego działania nie rozumie właściwie nikt). Generalnie dobrym pomysłem jest generowanie innego salta dla każdego hasła, wtedy po wyliczeniu sha1(salt + hasło) trudno będzie poznać, że dwóch użytkowników posiada identyczne hasła. Oczywiście baza zawsze może wyciec (nieprawdaż?), zatem doklejenie do hasła i generowanego salta jeszcze jakieś stałej zapisanej w "propertiesach" aplikacji powinno nas wystarczająco zabezpieczyć. Oczywiście żadne zabezpieczenia nie uchronią przed głupotą i brakiem wyobraźni, wszakże dla niektórych "qwerty" to silne hasło.
O ile braki w wiedzy na temat bezpieczeństwa wśród zwykłych użytkowników można wybaczyć (ale nie zaakceptować), o tyle wśród programistów brak takiej świadomości może prowadzić do sporych luk w bezpieczeństwie. Weźmy np. takie tagi JSP (JavaServer Pages) i EL (expression language). Domyślnie wszystkie teksty są "escape'owane", czyli jeśli użytkownik nazywa się <script>alert('xss')</script>, to właśnie naszym oczom ukaże się taka nazwa, a nie javascriptowy alert. Pisanie własnych tagów powoduje jednak, że mamy do czynienia z tworzeniem HTML-a w kodzie Javy. Nie wolno wtedy zrobić czegoś takiego:
@Override
public void doTag() throws JspException, IOException {
PageContext pageContext = (PageContext) getJspContext();
JspWriter out = pageContext.getOut();
out.println("" + someMessage.getBody() + "");
}
Oprócz tego, że w ten sposób de facto przenosimy warstwę widoku do (zwykłych) klas Javy (a tego robić nie chcemy i nie powinniśmy, skryptlety są przecież passé), a nasz webmaster nie wie, co ma z takim tagiem zrobić, to dodatkowo prosimy się o XSS, nie mamy bowiem w takim wypadku żadnej walidacji. Lepiej zapisać tekst do wyświetlenia w kontekście JSP i wyświetlić go bezpiecznie za pomocą EL na samej stronie.
I jeszcze jeden przypadek, który nasunął mi się po lekturze sierpniowego SDJ i lekturze artykułu o Groovym. Tekst jest dobrze napisany (w przeciwieństwie do paru innych), tyle że mamy tam następujący kwiatek: "GString (...) umożliwia dostęp do zmiennych z poziomu łańcuchów znaków (...) Może to mieć zastosowanie w wielu sytuacjach, np. (...) przy tworzeniu zapytań SQL". Takie podejście do pisania w SQL-u (aż by się chciało powiedzieć, że w stylu chłopców phpowców po gimnazjum) to prośba o kolejny atak, tym razem dla odmiany SQL Injection. Za nieużywanie sparametryzowanych zapytań powinno się w IT wprowadzić kary cielesne.
Trzeba też niestety uczciwie przyznać, że z wiedzą dotyczącą bezpieczeństwa (ogólnie pojętego) jest kiepsko, zwłaszcza w różnych startupach czy garażowych firmach (a i uczelnie dokładają tutaj swoją cegiełkę, a właściwie brak cegiełki). Głównym problemem dla firm jest ROI, ale inwestycja w "security" jest bardziej ubezpieczeniem, zresztą nawet w podstawowym pakiecie bardzo tanim i efektywnym w przypadku zagrożenia. No bo co to za filozofia postawić firmowy VPN, wprowadzić salt do haseł w tworzonych systemach czy używać PreparedStatement. To przecież wydawałoby się podstawy podstaw.