[PHP]czy nalezy filtrowac dane z inputa password? Opcje

[michat34]

witam zalozmy ze mam na stornie autoryzacje uzytkownikow. login,haslo,email.

login i email filtruje strip tags oraz trim.

a co z hasłem? strip_tags usunie znaki specjalne, przez co uzytkownik nie bedzie sie mogl po rejestracji zalogowac i nie bedzie wiedział co sie dzieje.
a czy jak nie zrobie filtracji to moze mi sie włamac na strone przez formularz?

ciezka sprawa, co robic?

[abort]

A co do hasła:
1. trzymasz zakodowane w bazie
2. przy logowaniu się usera wykonujesz na zmiennej $_POST['pass'] takie operacje, jakbyś chciał zaszyfrować hasło i porównujesz szyfr z danymi z bazy

[michat34]

wiem o hashowaniu (IMG:style_emoticons/default/tongue.gif)
ale mi chodzi o to czy przed wysłaniem hasła do bazy nalezy je wczesniej przefiltrowac czy nie?

no bo jak do inputa user da jako hasło:
Marek<123&&
to po filtracji do bazy zapisze sie
Marek123
i przy logowaniu uzytkownik bedzie sie dziwił czemu nie moze sie zalogowac

a z kolei jak go nie przefiltruje to moze mi wstrzyknąc do bazy jakis niefajny kod..


Ten post edytował michat34 21.10.2012, 19:22:30

[Crozin]

Skoro wiesz o hashowaniu to niby jakim cudem do bazy miałby trafić "niefajny kod"?

[PanGuzol]

W obu przypadkach do zapytania podajesz hash hasła(md5 lub sha-1), bez żadnego filtrowania przed hashowaniem. Hash na 100% niema niebezpiecznych znaków.

[michat34]

ok dziekuje wszystkim tak zrobie

[pamil]

[...] filtruje strip tags oraz trim. [...]

Żadne zabezpieczenie, używasz funkcji o których nie masz pojęcia.

[webdice]

Generalnie powinieneś filtrować każde dane. Często wykonuje się takie zapytanie:

[SQL] pobierz, plaintext 
SELECT * FROM `TABLE` WHERE `PASSWORD` = SHA1( '[PASSWORD]' )
[SQL] pobierz, plaintext 

a w takim wypadku już nie jest fajnie:

[SQL] pobierz, plaintext 
SELECT * FROM `TABLE` WHERE `PASSWORD` = SHA1( 'password' ) OR 1 = 1 --' )
[SQL] pobierz, plaintext 

[erix]

Zacznijmy od tego, że głupotą jest obarczanie bazy takim zadaniem, jak hashowanie. Ktoś nie filtruje długości pola i mamy zajechany serwer. (IMG:style_emoticons/default/tongue.gif)

Tak, pole na hasło trzeba filtrować. Właśnie ze względu na długość, bo jakoś nie spotkałem się z sytuacją, w której ktoś używa haseł dłuższych niż 100 znaków, a brak obcinania do jakiejś długości po prostu zajedzie Ci serwer, gdy do hashowania puści Ci kilka MiB, zwłaszcza gdy używasz hasha, który celowo jest zasobożerny.

[webdice]

Zacznijmy od tego, że głupotą jest obarczanie bazy takim zadaniem, jak hashowanie. (...)

Tu się w żadnym wypadku nie zgodzę. Weryfikacja długości pola to jest jedna sprawa, a używanie funkcji hashujących w zapytaniu to druga. Równie dobrze możemy powiedzieć że używanie CONCAT to głupota z tego samego powodu.

Zresztą tak jak napisałem w poprzednim poście, trzeba filtrować każde pole. Nigdy nie powinno się ufać danym pochodzącym od użytkownika.

[erix]

Tu się w żadnym wypadku nie zgodzę.

Jakieś argumenty?

[webdice]

Piszesz że korzystanie z hasowania w zapytaniu jest głupotą ze względu na to że ktoś może wrzucić do zmiennej bardzo długi ciąg znaków. Tak samo może wrzucić do zmiennej wykorzystywanej przykładowo przez CONCAT czy inną funkcje.

[erix]

Ale fakt wydajności, to tylko jeden z powodów.

Admin włącza slowlogi, chcesz, aby hasła użytkowników się w nich znalazły?

[Niktoś]

Ja się zgodzę z erixem, że należy filtrować dane pod względem długości(wystarczy zwykłe wyrażenie regularne z klamerkami określającymi długość ciągu, chyba nie powinno być to trudne), w innym przypadku co jeśli dane wejściowe przekroczą dozwolony zakres znaków w danej komórce ,czy będzie ona typu int czy varchar w bazie danych? Należy się liczyć z tym ,że każda baza danych, czy to będzie MySql, czy MSSQL, czy ORACLE, takie ograniczenia ma a przekroczenie takiego zakresu może mieć przykre konsekwencje.

[webdice]

~Niktoś długości nie sprawdzałbym wyrażeniami regularnymi, są zbyt wolne.

~erix nie popadajmy w paranoje, jeśli chcemy mieć bezpieczny serwis to nie stawiamy go na hostingu współdzielonym gdzie administratorem jest obca dla nas osoba. Równie dobrze może przechwytywać komunikacje między klientem, a trudno wszędzie stosować SSL.

Każdy ma swoje zdanie i raczej z nasz nie udowodni drugiemu wyższości swojego, jednak uważam że nie ma nic złego w korzystaniu z funkcji hashujących w zapytaniu.

[erix]

~erix nie popadajmy w paranoje, jeśli chcemy mieć bezpieczny serwis to nie stawiamy go na hostingu współdzielonym

Czasem nie ma takiej możliwości, bo klient sobie życzy tak, a nie inaczej.

Równie dobrze może przechwytywać komunikacje między klientem, a trudno wszędzie stosować SSL.

Wynika to zazwyczaj ze skąpstwa. (IMG:style_emoticons/default/tongue.gif)

[nospor]

Nawet jak postawisz SSL to admin serwera może poprostu wpisać w Twój kod php odpowiednią linijkę i będzie znał każde hasło (IMG:style_emoticons/default/wink.gif)

Ja tam osobiście też nie jestem zwolennikiem hashowania w mysql a to dlatego ze mysql nie zrobię hashowania tak, jak to mogę zrobic w php.
Pozatym już był raz przypadek w historii mysql ze w jednej wersji mysql HASH zwracał co innego niż w nowszej (IMG:style_emoticons/default/smile.gif)