Bezpieczeństwo Baz Danych [zamknięte]

Trafiłem raz na bazę danych która po wpisaniu odpowiedniego zapytania zwracała hasła z jakich korzystają użytkownicy. Czytałem też że zdarza się to często początkującym twórcom baz danych. Jak można wyeliminować ten błąd.

Powód zamknięcia: Udzielono odpowiedzi na pytanie, poprawna odpowiedź została zaakceptowana

  • Może chodzi Ci o SQL injection? Jesteś pewien, że widziałeś jawne hasła?

    Pierwszy przypadek to sytuacja w, której w bazie jest sprawdzany jakiś warunek, a nie sprawdzimy co dostajemy od użytkownika. Wtedy wpisujemy np.' OR 1=1 --' i po znaku komentarza'--' reszta zapytania nie jest przetwarzana, a test 1=1 jest zawsze prawdziwy, więc dostajemy wszystko.Jest to podstawowy przykład, trochę niejasno to opisałem, ale na pewno znajdziesz coś więcej w googlu.

    Jeśli widziałeś hasła, to już kompletny dramat, normą jest, że hasło trzeba haszować, choćby md5.

    Nie wiem jak w phpie, w asp.net żeby pozbyć się sql injection można na serwerze mieć dll'kę, albo w kodzie zamiast jawnych zapytań, sparametryzowane metody składowane w bazie, co ma też inne zalety i wady.

  • Tak, chodzi o SQL Injection.

    Jeżeli atakujący ma wiedzę na temat struktury bazy danych i ma rozpoznane zapytania, to sam proces wydobycia informacji z bazy danych jest już stosunkowo prosty. Przykładowo: składnia zapytania służącego do wydobycia nazw użytkowników i haseł z tabeli użytkowników ma postać:
    '; begin declare @var varchar(8000)
    set @var=':' select @var=@var+' '+login+'/'+password+'  '
    from users where login>@var
    select @var as var into temp end --
    ' and 1 in (select var from temp) --
    ' ; drop table temp --
    Powyższe zapytanie lokuje wszystkie nazwy użytkowników w zmiennej @var. Następnie zmienna @var zostaje umieszczona w tabeli temp w kolumnie var. Później kolumna var tabeli temp zostaje odesłana z wynikiem zapytania w komunikacie błędu. Ostatecznie tabela temp zostaje usunięta z bazy danych.

    Cały artykuł dostępny tutaj.

  • Atakujący może znać tylko login pewnej osoby. Wtedy jako login poda login" #, a jako hasło cookolwiek. To atak SQL Injection. Cudzysłów zamyka zapytanie, a kratka tworzy z reszty zapytania komentarz. Dobrym sposobem jest zastosowanie funkcji wejścia addslashes(), i funkcji wyjścia stripslashes(). Można dodać też htmlspecialchars(), by potem użytkownicy nie formatowali swoich danych, typu pogrubienie, pochylenie, podkreślenie. Dla pól textarea dobrą funkcją jest nl2br().

  • Rozwiązaniem jest nie ufanie niczemu, co pochodzi od użytkownika aplikacji.

    Parametryzowane zapytania SQL, escaping wartości wprowadzonych przez użytkownika przed wyświetleniem na stronie, sprawdzanie rozmiarów i typów danych przychodzących z zewnątrz, itd....

Zaloguj się, aby dodać swoją odpowiedź