Przeglądając forum.php.pl często widziałem, jak użytkownicy przechowują hasła w swoich bazach danych. Najczęściej używają funkcji hashujących md5, sha1 i sha2. Wszystko wygląda bardzo dobrze, hasła są przechowywanie bezpiecznie. No właśnie… na ile bezpiecznie.

Nie będę tutaj rozwodził się nad zabezpieczeniem baz danych, w których owa baza haseł się znajduje, ale nad samym zahashowanym ciągu. Wszyscy doskonale wiemy, że istnieją bazy md5 (sha1, sha2 również).

Przezorny zawsze ubezpieczony. Wiadomo, że nigdy nic nie wiadomo.

Pokażę, jak dodatkowo zabezpieczyć nasze hasła. Będą przechowywane w tej samej bazie danych, używając tych samych metod hashowania, a jednak szansa na “złamanie” hasła (wyszukania w bazie) będzie niemożliwa. Posłużymy się ciągiem znaków zwanym przez programistów solą (salt). Przykład implementacji możemy znaleźć w forum IPB, natomiast phpBB pozbawione jest tego fjuczuru ficzera. Cała sprawa sprowadza się do wygenerowania dowolnego kawałka ciągu znaków i doklejenia go do hasła. Sól potrzebna nam będzie również przy porównaniu hasła, więc trzeba ją zapisać w bazie danych obok hasła.

Poniżej zamieszczam przykładową klasę, która obsługuje solenie haseł. Doklejanie soli może być napisane w dowolny sposób, zależy to od Waszej wyobraźni. Ja dodatkowo dodałem element “losowy” w postaci doklejenia do soli wyniku działania funkcji microtime().

• Klasa, która soli hasła.
• Przykład – zapisywanie hasła do bazy danych oraz sprawdzanie go przy logowaniu.

Tak się składa, że czasem szperam w kodach źródłowych witryn. Szkoła hackerów – kurs “hackingu”, który się reklamuje po całym Internecie (padła propozycja również dla mojego serwisu lookme.pl) nie dba o swoją aplikację webową.

Jeżeli stawiamy walidator do formularza, który ma obsłużyć dane wprowadzone przez użytkownika, musimy:

1. Sprawdzić je po stronie serwera, jeżeli przejdą proces walidacji, dopiero potem podjąć akcję, w przypadku wystąienia błędów – wyświetlić je użytkownikowi.
2. (Ewentualnie) Poinformować o błędzie już po stronie użytkownika bez przeładowania strony ani bez użycia jakiegokolwiek requestu ajax (sprawa kosmetyczna, niekonieczna).

Każdy programista powinien powiedzieć, że walidacja po stronie serwera jest najważniejsza, już pomijając tą po stronie użytkownika, bo przecież kod JS można modyfikować, więc może go teoretycznie nie być.

Już raz Szkoła Hackerów dała popis – dziura SQL Injection. Specjaliści? Nawet na forum przedszkole (forum.php.pl) rzadko zdarzają się aż tak amatorskie kody.

Narzędziem firebug sprawdziłem formularz kontaktowy szkoły hackerów. Okazało się, że formularz posiada atrybut onsubmit, który wykonuje funkcję javascript valid(). Za pomocą narzędzia Firebug pozwoliłem sobie ją pominąć, tak, aby formularz zawsze otrzymywał true przy onsubmit (czyli się wykonywał). Okazało się, że dane po stronie serwera nie są sprawdzane. Nie jestem w stanie zdiagnozować, czy mail się wysłał, ale w takim przypadku użytkownik otrzymuje komunikat:

Twoja wiadomość została wysłana. Odpowiemy tak szybko, jak tylko będzie to możliwe, z reguły w ciągu 24 godzin. Odpowiedź zostanie przesłana na podany przez Ciebie adres e-mail ().

Amatorka?

Niedługo być może zaimplementuje w jeden z moich nowych projektów weryfikację właściciela strony. Pomysł pozwoliłem zrobię zaczerpnąć z Google Webmaster Tool. Natomiast troszeczkę zmieniłem jeden ze sposobów, aby mniej się napracować. Zweryfikowanie właściciela witryny odbywa się po wywołaniu jednej z poniższych metod. Oto one:

• Weryfikacja poprzez upload pliku na serwer.
• Chwilowe dodanie meta-tagu do sekcji HEAD.

W stosunku do google, zmianie uległa u mnie weryfikacja pierwsza.

Sposób Google: Upload pliku bez zawartości (lub z dowolną) o nazwie jako hash aktywacyjny, np: <?php md5( secret-salt ) . '.html'; ?>

Mój sposób: Upload pliku ze stałą lub hashowaną nazwą o zawartości 32 znakowego hashu md5.

Zmienia się tylko zawartość pliku. Dlaczego? Niektóre strony zamiast zwracać kod 404 dla nieistniejących plików/podstron zwracają kod 200 (sukces). Wówczas trudno stwierdzić, czy jest to oczekiwany plik. Google dodatkowo sprawdza, czy strona zawsze zwraca kod 200, ale po co się babrać i wykonywać więcej requestów, jak można zrobić to trochę prościej. Jeżeli plik nie będzie fizycznie istniał na serwerze, a strona zwróci kod 200, skrypt musi oczekiwać w odpowiedzi tylko i wyłącznie hashu strony. Nazwa pliku na serwerze może być stała, ale niekoniecznie (dla większego bezpieczeństwa zalecane jest logiczne hashowanie nazwy pliku).

Przygotujmy zatem zarys klasy (od tego zawsze zaczynam):

• public function CheckFile($sUrl, $sFilename) funkcja sprawdzająca hash w pliku na serwerze.
• public function CheckMetatag($sUrl, $sTagName) funkcja sprawdzająca hash w metatagu.
• public static function Hash($sUrl) funkcja budująca hash na postawie adresu URL (jako że podajemy go jako parametr obu metod sprawdzających, zmienna jest łatwo dostępna dla systemu).
• public static function Metatag($sHash, $sTagName) generowanie kodu XHTML dla metatagu – metoda potrzebna nam przy podaniu użytkownikowi meta tagu oraz do prega w metodzie CheckMetatag();
• protected static function _Request($sUrl) tworzenie requestu za pomocą HttpRequest i zwracanie treści metodą getResponseBody() wspomnianej klasy.

Jako że komponent jest niejako zewnętrzną biblioteką, nie mogłem go wcisnąć w komponentu frameworka. Otrzymał status biblioteki: VframeLib_WebVeryfication.

Oczekiwane API:

var_dump(VframeLib_WebVeryfication::CheckFile('http://example.com/', 'Veryfication.txt')); // bool result
var_dump(VframeLib_WebVeryfication::CheckMetatag('http://example.com/', 'Veryfication')); // bool result

Gotowy kod:

http://athlan.pl/code/VframeLib_WebVeryfication

Uwaga. Kod jest w fazie testowej. Wszelkie Wasze komentarze będą uwzględniane przy poprawkach.

Dziś postanowiłem przeglądnąć opcje prywatności konta na naszej klasie. Co się okazało, jest opcja pozwalająca na blokadę wysyłania zdjęcia na telefony komórkowe (“Nie pozwalaj innym wysyłać moich zdjęć na komórki” ):

Spróbowałem to przetestować. Po zaznaczeniu opcji przycisk “Wyślij na komórkę” zniknął spod zdjęcia. Postanowiłem wywołać wcześniej skopiowany adres odnośnika w pasek adresu:

javascript:nktapeta('Tutaj adres URL zdjęcia')

Ujrzałem okienko z możliwością przycięcia wybranej fotografii. Ja sobie tego nie życzę :)

Analiza? Dobrze jest w widoku, źle lub brak (stawiam na to) sprawdzania opcji w kontrolerze. Każdy popup powinien być najpierw sprawdzany, nawet przy ręcznym wywołaniu. Sprawdzany przynajmniej po stronie NK, wówczas portal nie będzie odpowiadał za kopiowanie fotki na dysk i ręczny upload na serwery serwisu umożliwającego wysyłanie tapet na telefon komórkowy.