Jak trochę lepiej zabezpieczyć hasło i ogólnie całą aplikację?

pytanie zadane 6 lipca 2015 w PHP przez krecik1334 Maniak (58,390 p.)

Wrzucam Wam link do postawionego na testowym hostingu projektu: http://krecik.16mb.com/

Jest on zrobiony w proceduralnym PHP, to co jest w środku to czysty HTML więc o wygląd się nie czepiać. Chodzi mi o bezpieczeństwo. Jak narazie na stronę łatwo można wejść, jest ustawione proste hasło bez żadnych zabezpieczeń spróbujcie złamać metodą słownikową. Pomóżcie mi zabezpieczyć trochę lepiej tę stronę, od razu mówię że sesji też nie umiem zabezpieczyć.

3 odpowiedzi

odpowiedź 6 lipca 2015 przez Comandeer Guru (601,110 p.)

Pętla na cURL w konsoli w linuksie i można jechać na wakacje ;) Problem w tym, że nie znamy także loginu, więc czas się diametralnie wydłuży. Ale żadnego zabezpieczenia nie ma, więc to kwestia czasu.

Co do sesji: jeśli Hostinger stawia wszystko na współdzielonych to jest szansa po prostu przejąć sesję z innej strony postawionej na tym samym serwie. Wystarczy id sesji, stąd proponuję wykorzystywać funkcję session_regenerate_id.

Wypada także zabezpieczyć same cookie (flaga http_only jest obowiązkowa, flaga secure zalecana). Ogólnie o sesji polecam poczytać tutaj: http://www.forumweb.pl/php/sesje-w-przegladarce-miedzy-serwerami,62090

Co do zabezpieczenia przed słownikowymi atakami: blokada logowania na konto po x nieudanych próbach? + można blokować czasowo

komentarz 6 lipca 2015 przez krecik1334 Maniak (58,390 p.)

A propos hostingera, strona docelowo nie będzie tam stała . Jakbyś mógł coś powiedzieć konkretnie na temat biznes-host.pl, bo to raczej będzie docelowy hosting dla tej stronki.

komentarz 6 lipca 2015 przez Comandeer Guru (601,110 p.)

Co powiem? Tyle, że postawiłem tam stronę 3 lata temu i nie ma problemów :D Supportu nie znam, bo nie musiałem się nigdy kontaktować ;)

komentarz 6 lipca 2015 przez krecik1334 Maniak (58,390 p.)

Czytałem opinie o tym hostingu, od 3 lat sporo tam się mogło zmienić aczkolwiek zaryzykuję. Na pewno nie ma takiego z którym nigdy nie będzie problemów.

komentarz 7 lipca 2015 przez Schizohatter Nałogowiec (39,600 p.)

Najlepiej napisać zabezpieczenie typu antyflood na combo: baza danych po ip/sesja/cookie. Wkrótce może przysiądę i napiszę funkcję, która to realizuje.

Ew. zawsze można dać sleep() przy logowaniu. 2 sekundy sleepa zabije każdą metodę słownikową, a nie wpłynie na user-experience. Ale rozwiązanie wymyślone na poczekaniu, nie mam pojęcia, jak się sprawdza w praktyce.

odpowiedź 6 lipca 2015 przez Boshi VIP (100,240 p.)

Nikt się nie będzie bawił w metody słownikowe, szuka się innych dziur, sqli, xss itd.

komentarz 6 lipca 2015 przez krecik1334 Maniak (58,390 p.)

Jest tylko jeden user. Nie ma przy logowaniu połączeniu z bazą danych więc cokolwiek z sql od razu odpada :P

komentarz 6 lipca 2015 przez Boshi VIP (100,240 p.)

To logowanie jest z pliku?

komentarz 6 lipca 2015 przez krecik1334 Maniak (58,390 p.)

Tak, no a po co angażować w to SQL jak bazę będzie obsługiwała tylko jedna osoba.

komentarz 6 lipca 2015 przez Comandeer Guru (601,110 p.)

I pewnie hasło plaintextem?

komentarz 6 lipca 2015 przez krecik1334 Maniak (58,390 p.)

Tak, no i właśnie chciałbym zapytać czy jest sens jakoś to szyfrować/haszować. Nigdy tego nie robiłem (0 projekt).

komentarz 6 lipca 2015 przez Comandeer Guru (601,110 p.)

Oczywiście, że jest. Przepuść to przez password_hash i tyle. Włam na serwer jest zawsze możliwy - jak se nie zahashujesz, to ktoś bez żadnego wysiłku dostanie hasło admina.

odpowiedź 6 lipca 2015 przez Dorion300 Szeryf (90,250 p.)

Strona poszła...

Czego może być przyczyną?

komentarz 6 lipca 2015 przez krecik1334 Maniak (58,390 p.)

Strona poszła? Cały czas stoi, przynajmniej u mnie.

komentarz 6 lipca 2015 przez Dorion300 Szeryf (90,250 p.)
edycja 6 lipca 2015 przez Dorion300

No to mnie chyba zablokowali za.....nie wiem co dokładniej.

Albo coś poszło.

PS: strona jest zabezpieczone przeciw wstrzykiwaniu SQL?

komentarz 7 lipca 2015 przez krecik1334 Maniak (58,390 p.)
edycja 7 lipca 2015 przez krecik1334

Raczej tak. Samo logowanie zrobione na zahaszowanym pliku, więc włamywacz nie posłuży się SQL Injection. Będzie musiał użyć bardziej wyrafinowanych, aczkolwiek też prostych metod. Oprócz tego wnętrze strony zabezpieczyłem przed nieświadomym SQLinj ze strony użytkownika, np. wpisanie ' czy -- w treść zapytania.