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.

Swoje święta mają administratorzy, ma liczba PI, mają zatem też blogi. Jako że wpis ten i tak ukazuje się po deadline, który przypadał na 31 sierpnia, pozwolę sobie na modyfikację także i innych punktów regulaminu (więcej informacji na temat całej akcji można znaleźć na stronie BlogDay). Czyli będzie lista blogów, ale niekoniecznie pięciu, niekoniecznie nowo odkrytych i niekoniecznie niezwiązanych z poruszaną przeze mnie tematyką, a wręcz przeciwnie.

Swoją drogą z blogami ogólnie jest tak, że ludzie zbyt często piszą nie mając nic do przekazania. Wydaje mi się, że jednak z ludźmi zaangażowanymi w IT jest nieco inaczej - mają do przekazania całkiem sporo, lecz zbyt często kończy się to na paru wpisach, a potem blog pozostaje martwy. Z tego też powodu w Blog Day z czytnika RSS musiałem niestety wykasować sporo nieaktywnych blogów, zwłaszcza technicznych. A szkoda, bo zapowiadały się nieźle; niestety mało kto ma tyle zapału co Jacek Laskowski (który nota bene jest pośrednim twórcą i mojego bloga, ale to temat może na jakąś rocznicową notkę :).

Subiektywnie wybrane blogi javowe:

• Holistyczna inżynieria oprogramowania (http://art-of-software.blogspot.com) - chyba najlepszy według mnie w tym momencie polski blog javowy, stąd też zgłosiłem go do konkursu JDD 09 Java Guide. Autor nie opisuje kolejnych pięciuset frameworków webowych, ale kładzie nacisk na te aspekty pracy w świecie IT, których nie poznamy z dokumentacji ani też zapewne nie nauczymy się na studiach, niestety. Polecam, chociażby ze względu na humanistyczne zacięcie.

• Java and neighbourhood (http://nurkiewicz.blogspot.com) - od niedawna anglojęzyczny blog Tomka Nurkiewicza. Ciekawa dla mnie tematyka, przemyślane i interesujące notki, także jeżeli chodzi o ich formę (co często jest bolączką osób "technicznych"). Może trochę za rzadko pisze i nie ma archiwum, no ale nikt nie jest doskonały.

• Adam Bien's Weblog (http://www.adam-bien.com) - wpisy Adama w blogu są jak jego występy na konferencjach (w Polsce m.in. JDD i GeeCON) - oszczędne w formie (oraz krótkie), ale zazwyczaj z maksimum interesującej treści. Poza tym pisze często, bardzo często.

Wśród moich ulubionych blogów javowych (a nawet i czasem w czytniku) brak nazwisk takich jak Gosling czy chociażby Strachan, ciekawa treść bowiem często nie idzie w parze z zasługami danej osoby dla javowej społeczności. A Wy macie jakieś ulubione javowe zakątki w sieci, którymi chcielibyście się podzielić?