Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

Bezpieczne logowanie

Pierwszą czynnością podczas logowania (zaraz po filtracji danych) jest sprawdzenie czy podany użytkownik istnieje w naszym systemie. Z zasady odbywa się to za pośrednictwem zapytania SELECT, które wyszukuje użytkownika na podstawie podanych przez niego danych.

SELECT id FROM users WHERE login = "user" AND password = "pass";

Powyższe zapytanie ma jedna słabość. Jeśli napastnikowi uda się wstrzyknąć komentarz w zmienna z loginem będzie on zdolny do zalogowania się na dowolne konto bez konieczności podawania hasła.

SELECT id FROM users WHERE login = "user"--- AND password = "pass";

Możliwość taka należy brać pod uwagę nawet w sytuacji gdy filtrujemy dane użytkownika. Może się bowiem okazać, że za jakiś czas zostanie upubliczniona dziura umożliwiająca obejście aktualnych zabezpieczeń.

Rozwiązaniem powyższego problemu jest wyszukanie użytkownika na podstawie jedynie loginu, a następnie porównanie hasła z bazy z tym, które podał użytkownik.

SELECT password FROM users WHERE login = "login";

Dodatkową kwestią do rozważenia podczas tworzenia systemu logowania jest sposób informowania użytkownika o podaniu złych danych. Możemy dokonać tego dwojako: pokazać, która wartość jest niepoprawna („użytkownik o podanym loginie nie istnieje” / „podane hasło jest nieprawidłowe”), bądź tez zwrócić ogólny komunikat błędu („podane dane są niepoprawne”). W pierwszym przypadku napastnik otrzymuje informacje czy login, który podał istnieje, a co za tym idzie może przeprowadzić próbę złamania hasła. Rozwiązanie to powinno być stosowane wszędzie tam gdzie wygoda użytkownika jest ważniejsza od bezpieczeństwa.


Tagi:
Kategoria: Bezpieczeństwo, Logowanie


6 komentarzy

  1. a nie prościej użyć funkcji escapującej znaki na podawanych przez użytkownika danych?

  2. prościej i nawet trzeba to zrobić, cały sens tej notki polega ta tym, że to co dziś jest bezpieczne, niekonicznie będzie bezpieczne jutro :)

  3. Jesli chodzi o ostatnią kwestie do rozważenia dotyczącą informowania o tym czy login, czy hasło są niepoprawne. Zawsze i wszędzie powinno stosować się ogólnikowy komunikat „Podany login LUB hasło są nieprawidłowe. Załóżmy, że nick ani mail nie jest loginem, to zdobycie informacji o loginie „zosia84739” już może być połową sukcesu w zapoczątkowaniu ataku, choćby brute force.

  4. Dobrym nawykiem jest także zastosowanie bindowania w PDO oraz objęcie całej akcji klauzurą try i w razie jakichkolwiek problemów odnotować ten fakt w logach aplikacji, o czym autor strony wspomniał w jednym z postów.

    Można także dołożyć limit błędnych logowań, po którym logowanie na dany nick jest blokowane np przez 1h. Skutecznie wydłuża to czas łamania hasła i zniechęca napastnika. Wysłać mail do właściciela konta o zaistniałej sytuacji, administrator będzie miał historie w logach wiec do niego nie trzeba a wręcz jest to niewskazane, ponieważ przy większym portalu dostałby białej gorączki :)

    Pamiętajcie aby wszystko logować :) wydaje się to śmieszne, ale nawet prawidłowe logowania powinny być logowane w dzienniku. Aby potem w razie jakichkolwiek problemów wiedzieć co i jak.

    Tyle z mojej strony.

  5. Panie Michale, napisał Pan, że z uwagi na możliwość jakiegoś włamania i wstrzyknięcia kodu do zapytania SQL, lepiej zastosować dwa zapytania – najpierw sprawdzić, czy login istnieje, a potem czy jego hasło jest takie samo jak wpisane. Myślę, że to nie ma sensu, bo jak ktoś może wprowadzić „SELECT COUNT(*) FROM users login = ‚wpisany login–‚ AND haslo = ‚haslo’ „; to może wprowadzić i do pierwszego zapytania o sprawdzenie loginu i do drugiego do sprawdzenia hasła ;)
    Co do zabezpieczenia samego logowania dobrym pomysłem jest tworzenie za każdym razem – czy udana próba czy nie – dziennika logowania – zawsze potem mamy więcej danych o „włamywaczu” ;)

    Pozdrawiam!

  6. Panie Karolu, na początku notki napisałem o spr id, co miało przedstawić podejście wielu osób do zagadnienia weryfikacji, następnie zasugerowałem rozwiązanie, które moim zdaniem jest lepsze tzn nie pobieramy id, tylko hasło, a następnie spr je z tym co podał użytkownik.

    Jeśli chodzi o dziennik logować to od dłuższego czasu mam w planach napisanie notki na ten temat.

    Pozdrawiam

Dodaj komentarz