Logowanie, pomoc przy logowaniu |
Logowanie, pomoc przy logowaniu |
7.09.2011, 17:40:13
Post
#1
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
Witam, napisałem skrypt logujący użytkownika wszystko działa prawidłowo lecz chcę się dowiedzieć w jaki sposób zabezpieczyć taki skrypt przed atakami. Robię coś źle? Jakieś propozycję? Dzięki |
|
|
7.09.2011, 17:48:16
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) |
a to co za wynalazek?
wepchałeś tu całą masę funkcji a i tak nie zabezpieczyłeś:
W taki sposób do niczego nie dojdziesz...dowiedz się co robią te funkcje i w jakich sytuacjach je używać i rób to z głową, a nie na zasadzie "wepcham wszystko to będzie ok", do zabezpieczania zapytań używa się mysql_real_escape_string() dla string oraz np. rzutowanie na int (int) dla int, poczytaj sobie o sql injection, bo nawet ta funkcja w pewnych sytuacjach może nie być wystarczająca |
|
|
7.09.2011, 17:52:22
Post
#3
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
To, co robisz w tym kodzie jest całkowicie zbędne. Wystarczy, że użyjesz funkcji haszującej, jest to wystarczające zabezpieczenie.
A takie zabawy są już ciekawsze:) Tylko zamiast $user_login używa się zazwyczaj soli, czyli jakiegoś indywidualnego ciągu znaków, który również zapisujesz do bazy. Możesz użyć np. funkcji http://pl2.php.net/manual/en/function.microtime.php do jego generowania. Wystarczy, że użyjesz metody: http://pl2.php.net/manual/en/function.mysq...cape-string.php Jednak osobiście uważam, że co do loginu, to walidacja powinna wyglądać trochę inaczej. Chodzi o to, że zazwyczaj login ma pewien określony zbiór znaków, z których może się składać np. litery, cyfry, _, -, spacja itp. W każdym razie zbiór dozwolonych znaków jest określony dlatego też lepiej walidować login użytkownika, a nie (tak jak ty) filtrować. Do walidacji przydaje się funkcja: http://pl2.php.net/manual/en/function.preg-match.php -------------------- |
|
|
7.09.2011, 18:26:27
Post
#4
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
ok dzięki zrobie tak ja mówicie
"Możesz użyć np. funkcji http://pl2.php.net/manual/en/function.microtime.php do jego generowania." jeśli tego użyje to co z saltem w rejestracji? Ten post edytował seba199696 7.09.2011, 18:26:54 |
|
|
7.09.2011, 19:00:12
Post
#5
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
Sorry, z tą solą to trochę pokręciłem. Tak to jest jak się robi dziesięć rzeczy na raz:P
Sól to jest unikalny string (zazwyczaj). Może on być zahardcodowany w pliku lub zapisany w bazie. Dzięki niej ciężej jest odkryć hasło, które zostało przepuszczone przez funkcję haszującą. Twoją solą może być np. 'sad8%$9sdk' lub cokolwiek zechcesz. Im bardziej przypadkowy jest to zbiór znaków, tym lepiej. I tą właśnie sól doklejasz do hasła, które przesłał użytkownik, nie ważne czy to rejestracja, czy logowanie. http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Ten post edytował bastard13 7.09.2011, 19:01:22 -------------------- |
|
|
7.09.2011, 19:17:48
Post
#6
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
Mógłbyś mi wytłumaczyć o co chodzi z mysql_real_escape_string? Czytałem tego manuala ale coś nie bardzo
o co chodzi? Ten post edytował seba199696 7.09.2011, 19:21:01 |
|
|
7.09.2011, 19:33:26
Post
#7
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
Cytat mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a. a tutaj jak chcesz masz po polsku: http://php-manual.skryptoteka.pl/function....ape-string.html -------------------- |
|
|
8.09.2011, 21:22:01
Post
#8
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
Poprawiłem skrypt, teraz dobrze?
Ten post edytował seba199696 8.09.2011, 22:24:01 |
|
|
8.09.2011, 22:29:24
Post
#9
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
Tak na pierwszy rzut oka to ok.
Usunąłbym jednak te constant value. Po co ci one? I tak z bazą łączysz się raz. Już prędzej wykorzystałbym to do przechowywania soli. A następny krok to OOP:) -------------------- |
|
|
10.09.2011, 09:53:38
Post
#10
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
Ok Mam jeszcze jedno pytanie, przeczytałem gdzieś "Nie trzymaj w sesji nazwy użytkownika tylko np. wspomniany już losowy identyfikator..." to jak użytkownik będzie edytował treści itp.?
|
|
|
10.09.2011, 11:52:45
Post
#11
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) |
w sesji trzymasz to co potrzebujesz oprócz hasła. Przeważnie trzyma się id, nazwa użytkownika, e-mail, czas ostatniego logowanie i co tam jeszcze potrzebne. Poza tym nigdy nie identyfikuj użytkownika po jego nazwie, ani w ogóle żadnego innego rekordu po nazwie - zawsze używaj do tego celu unikalnego numeru ID.
|
|
|
10.09.2011, 11:56:22
Post
#12
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
Czyli jak użytkownik dodaje komentarz to będzie ... WHERE iduser=$id?
|
|
|
10.09.2011, 12:24:30
Post
#13
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) |
tak, ale dla zabezpieczenia dajesz jeszcze rzutowanie na int czyli
i analogicznie odwołujesz się do innych rekordów z pozostałych tabel czyli np. to id w bazie ustawiasz pole INT może być UNSIGNED, autoincrement i primary key, oczywiście są też sytuacje gdzie robi się primary key z kilku kolumn ale na początek powinno Ci wystarczyć, że rozróżnianie rekordów, edycja usuwanie na podstawie pola ID Jak użytkownik dodaje komentarz to w tabeli trzymasz jego ID czyli masz tabelę: comments: - comment_id (int) - comment_text (text) - comment_date (timestamp) - comment_user (int) - i tutaj trzymasz jego numer ID |
|
|
10.09.2011, 13:00:09
Post
#14
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
a przy poprawnym logowaniu przypisać id używając:
? |
|
|
10.09.2011, 13:08:19
Post
#15
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) |
dokładnie, możesz również przypisać inne przydatne rzeczy, np. przypiszesz sobie nazwę użytkownika to będziesz mógł zrobić
generalnie tego typu kwestii jest jeszcze mnóstwo to co tu wspomnieliśmy to zaledwie wierzchołek góry lodowej, dlatego polecałbym bym Ci poszukać sobie w dziale Książki jakąś fajną książkę bo to najlepszy sposób na opanowanie podstaw i wbrew pozorom o wiele szybszy niż takie mozolne kombinowanie na własną rękę |
|
|
10.09.2011, 22:10:56
Post
#16
|
|
Grupa: Zarejestrowani Postów: 119 Pomógł: 0 Dołączył: 4.01.2011 Ostrzeżenie: (20%) |
Dzięki
Mam jeszcze jedno pytanko w bazie mam user_id, user_login, user_haslo 1. user_id pole typ INT UNSIGNED autoincrement primary key 2. user_login typ? 3. user_haslo typ? Co najlepiej wybrać do loginu i hasła? VARCHAR? Ten post edytował seba199696 10.09.2011, 22:23:50 |
|
|
11.09.2011, 00:13:48
Post
#17
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) |
tak oba varchar, ponieważ zezwalasz na użycie dowolnych znaków( various characters) na początek możesz dawać varchar(255), no chyba, że wprowadzasz walidację odnośnie maksymalnej długości wtedy pole nieodpowiednio mniejsze, jak już będziesz bardziej zaawansowany to warto precyzyjniej dobierać długość. W przypadku hasła pozwalasz na użycie dowolnych znaków, natomiast w przypadku loginu przeważnie zezwala się wyłącznie na znaki alfanumeryczne, czyli litery i cyfry
Ten post edytował tehaha 11.09.2011, 00:18:40 |
|
|
11.09.2011, 00:31:56
Post
#18
|
|
Grupa: Zarejestrowani Postów: 664 Pomógł: 169 Dołączył: 8.01.2010 Skąd: Kraków Ostrzeżenie: (0%) |
A ja mam tylko pytanie po co to rzutowanie na integer przy id użytkownika? Przecież ta wartość jest pobierana z bazy i trzymana w sesji, a więc wiemy, że jest poprawna. A w zapytaniu tak samo na zadziała '1'(string) oraz 1(integer). Nie widzę żadnego powodu, aby robić coś takiego.
-------------------- |
|
|
11.09.2011, 10:02:56
Post
#19
|
|
Grupa: Zarejestrowani Postów: 1 748 Pomógł: 388 Dołączył: 21.08.2009 Skąd: Gdynia Ostrzeżenie: (0%) |
Cytat A ja mam tylko pytanie po co to rzutowanie na integer przy id użytkownika? Przecież ta wartość jest pobierana z bazy i trzymana w sesji, a więc wiemy, że jest poprawna. no może akurat w tym przypadku w kodzie proceduralnym nie będzie to konieczne, ale przecież w praktyce zmienne są podawane do metody jako argumenty i zapytanie trzeba odpowiednio zabezpieczyć bez wnikania skąd to będzie pochodziło bo różnie może być metoda użyta. Wydaje mi się, że też jako początkujący lepiej jak się nauczy zabezpieczać 100% przypadków, bo potem są takie sytuacje, gdzie bez namysłu skopiuje sobie gotowe zapytanie na inną podstronę zamieni $_SESSION na $_GET i luka gotowa Cytat A w zapytaniu tak samo na zadziała '1'(string) oraz 1(integer). Tak, w mysql tak samo zadziała więc, tutaj można mówić jedynie o dobrym nawyku programowania, skoro mamy pole typu int to powinniśmy podawać int, a nie parsować string |
|
|
11.09.2011, 15:04:27
Post
#20
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%) |
Chciałbym dodać do wypowiedzi tehaha, co to typów, że jeżeli hashujesz hasło, to warto zastosować pole o stałej długości czyli char zamiast varchar.
-------------------- Zainteresowania: C#, PHP, JS, SQL, AJAX, XML, C dla AVR
Chętnie pomogę, lecz zanim napiszesz: Wujek Google , Manual PHP |
|
|
Wersja Lo-Fi | Aktualny czas: 10.06.2024 - 14:00 |