Bezpieczństwo logowania

pytanie zadane 4 listopada 2016 w PHP przez michal Mądrala (5,560 p.)

Jak to jest z tym bezpieczeństwem. Czego używać na dzień dzisiejszy do logowania i przełączania się między plikami żeby było w miarę logicznie zrobione? Próbuję zrobić mały serwis na angularze i php . Czy sesje na dzień dzisiejszy są do tego odpowiednie i można ich śmiało używać do sprawdzania czy user jest zalogowany itd. Co o tym sądzicie ?

2 odpowiedzi

odpowiedź 6 listopada 2016 przez Abel Mądrala (5,140 p.)

Możesz trzymać informacje o tym czy user jest zalogowany w sesjach , możesz trzymać w bazie .

Mając info o tym czy user jest zalogowany w bazie , będziesz zmuszony do pobierania tej informacji z bazy .

Jeżeli oprzesz to na sesje to sprawa sprawdzenia czy user jest zalogowany jest znacznie prostsza , i moim zdaniem wygodniejsza

Co do bezpieczeństwa sesji ,hmm nie słyszałem żeby ktoś włamał się na jakiś serwis poprzez sesje

4	komentarz 6 listopada 2016 przez Comandeer Guru (600,810 p.) Co do bezpieczeństwa sesji ,hmm nie słyszałem żeby ktoś włamał się na jakiś serwis poprzez sesje Session poisoning, session fixation… Ogólnie: top 10 OWASP-u.

komentarz 6 listopada 2016 przez CzikaCarry Szeryf (75,340 p.)

No ale jeśli ktoś Ci ukradnie klucz sesji to raczej Client suckz a nie autor strony suckz albo sesje suckz,

1	komentarz 6 listopada 2016 przez Comandeer Guru (600,810 p.) Najczęściej sesje się kradnie przez ataki CSRF i XSS, więc jest to wina autora strony, nie użytkownika. Stwierdzenie, że użytkownik za coś ponosi winę jest stwierdzeniem, które zabiło niejedną dobrą apkę.

komentarz 6 listopada 2016 przez Abel Mądrala (5,140 p.)

z tego co doczytałem to taki atak jest mozliwy tylko jeżeli sama rejestracja jest nie przemyślana i umożliwia zarejestrowanie nicka ze znakami HTML

Więc przy odpowiednio przemyślanej rejestracji nie ma możliwości ataku

2	komentarz 6 listopada 2016 przez Comandeer Guru (600,810 p.) Nieprawda. Taki atak jest możliwy jeśli nie filtruje się jakichkolwiek danych od usera. Można przejąć zewnętrzne API, zatruć jego output i tym samy wykonać atak XSS na stronie, która ufa danym z zewnętrznego źródła.

komentarz 7 listopada 2016 przez Abel Mądrala (5,140 p.)

No tak , czyli filtrowanie wpisywanych tekstów załatwia sprawę

Hasło powinno się trzymać zahashowane i jest ono w bazie czyli jeszcze dodatkowo zapytania do bazy bindowane

Więc jeżeli nie pozwolę użytkownikom na wpisywanie znaków specjalnych w polu login to powinno załatwić problem z atakami CSRF i XSS

komentarz 7 listopada 2016 przez Comandeer Guru (600,810 p.)

Więc jeżeli nie pozwolę użytkownikom na wpisywanie znaków specjalnych w polu

Można przejąć zewnętrzne API, zatruć jego output i tym samy wykonać atak XSS na stronie, która ufa danym z zewnętrznego źródła.

Wszystko, czego sam nie wpisałeś, jest niezaufane.

odpowiedź 8 listopada 2016 przez michal Mądrala (5,560 p.)

Czyli możemy uznać że serwis, który podczas rejestracji i logowania filtruje wszystkie dane wpisane przez usera pod kontem niepowołanych znaków + bindowanie parametrów przy wykonywaniu zapytań + hashowane hasła w bazie za bezpieczny ?

Jaka na dzień dzisiejszy funkcja hashująca php jest najlepsza i powszechnie używana? Czy password_hash($haslo, PASSWORD_DEFAULT) można uznać za odpowiednią ?