$_SESSION i Uwierzytelnianie - pytanie |
$_SESSION i Uwierzytelnianie - pytanie |
4.06.2008, 17:32:36
Post
#1
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 18.09.2007 Ostrzeżenie: (0%) |
Witam.
Męczę się nad bezpiecznym systemem uwierzytelniania i proszę ocenić, czy takie coś będzie bezpieczne:
Głównie chodzi mi o to, czy ktoś może zmienić wartość tablicy sesji $_SESSION['logged'] na 1 i tym samym zdobyć uprawnienia admina. Ten post edytował MGreg 4.06.2008, 17:35:26 |
|
|
4.06.2008, 17:38:11
Post
#2
|
|
Grupa: Zarejestrowani Postów: 2 291 Pomógł: 156 Dołączył: 23.09.2007 Skąd: ITALY-MILAN Ostrzeżenie: (10%) |
Ja bym zmienil jak juz cos jedna rzecz zamiast dawac mysql_num_rows() wez sobie za pomoca mysql_fetch_assoc() sprawdzaj jeszcze raz dane to raz a dwa dodal bym else z header'em na google gdy ktos poda zle dane wtedy nie bedzie nic widzial etc ogolnie jak trzymasz identifikator w url to generuj za kazdym razem nowe id dla sesji i potem na kazdej podstawie sprawdzaj czy jest dany login z sesji w bazie
-------------------- Zainteresowania: XML | PHP | MY(SQL)| C# for .NET | PYTHON
http://code.google.com/p/form-builider/ Moj blog |
|
|
4.06.2008, 17:52:21
Post
#3
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 18.09.2007 Ostrzeżenie: (0%) |
Umieściłem tylko przykład, dlatego nie dodawałem else z informacją typu "błędny login lub hasło" a identyfikator sesji przecież nie jest przekazywany w url-u, no chyba, że coś przeoczyłem
|
|
|
4.06.2008, 17:58:16
Post
#4
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
jeszcze zabezpieczenie przed XSS by można było ^^
-------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
4.06.2008, 18:10:55
Post
#5
|
|
Grupa: Zarejestrowani Postów: 1 085 Pomógł: 231 Dołączył: 12.05.2008 Ostrzeżenie: (0%) |
Nie jest, ale czy dyrektywa session.use.cookies.only jest włączona? Jeśli nie identyfikator pójdzie przez adres w przypadku gdy cookie nie zostanie przyjęte. Także regeneracja nie jest aż tak zbędna, jakby się wydawało, chociaż dzisiaj praktycznie większość serwerów wymusza sesje przez ciacha ^^
@up A gdzie tu masz wypisywanie jakichkolwiek danych wprowadzonych przez użytkownika? Ten post edytował Shili 4.06.2008, 18:12:24 |
|
|
4.06.2008, 18:15:58
Post
#6
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 18.09.2007 Ostrzeżenie: (0%) |
@up A gdzie tu masz wypisywanie jakichkolwiek danych wprowadzonych przez użytkownika? Nie umieszczałem formularza, bo chodzi mi głównie o kod php Ale jak to ma się na coś zdać to dodałbym tam np. Ten post edytował MGreg 4.06.2008, 18:17:14 |
|
|
4.06.2008, 18:28:19
Post
#7
|
|
Grupa: Zarejestrowani Postów: 1 085 Pomógł: 231 Dołączył: 12.05.2008 Ostrzeżenie: (0%) |
Nie nie, to było do @pyro. Powinnam była wyraźniej zaadresować
|
|
|
4.06.2008, 20:15:32
Post
#8
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Nie jest, ale czy dyrektywa session.use.cookies.only jest włączona? Jeśli nie identyfikator pójdzie przez adres w przypadku gdy cookie nie zostanie przyjęte. Także regeneracja nie jest aż tak zbędna, jakby się wydawało, chociaż dzisiaj praktycznie większość serwerów wymusza sesje przez ciacha ^^ @up A gdzie tu masz wypisywanie jakichkolwiek danych wprowadzonych przez użytkownika? No tak... to co pokazał autor to jest pewnie cały skrypt, prawda Shili? -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
4.06.2008, 20:27:34
Post
#9
|
|
Grupa: Zarejestrowani Postów: 1 085 Pomógł: 231 Dołączył: 12.05.2008 Ostrzeżenie: (0%) |
Nieprawda, ale przekazywane jest tylko login i hasło (bo i po co więcej do logowania), co można podejrzeć na dodanym przez autora kodzie. Zresztą nie do końca poprawnym, ale to inna bajka. Zresztą...
Bez zobaczenia reszty kodu można gdybać, bo może być tam brak zabezpieczenia do każdego możliwego błędu, autor może nawet wypisywać wszystkie swoje hasła. Ale po co gdybać, jeśli wyraźnie dostaliśmy taki fragment kodu do analizy, jaki MGreg chce by zanalizowano? Co najwyżej można poprosić o resztę i wtedy się odnosić Ten post edytował Shili 4.06.2008, 20:28:08 |
|
|
4.06.2008, 20:54:44
Post
#10
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 18.09.2007 Ostrzeżenie: (0%) |
Co do XSS stosuję strip_tags(); i chyba to mi wystarczy Jutro wstawię poprawioną wersję i będziemy dyskutować dalej
|
|
|
4.06.2008, 21:02:40
Post
#11
|
|
Grupa: Zarejestrowani Postów: 240 Pomógł: 13 Dołączył: 1.06.2007 Skąd: Wrocław Ostrzeżenie: (0%) |
No tak... to co pokazał autor to jest pewnie cały skrypt, prawda Shili? To jeszcze powiedz autorowi jak powinien zabezpieczyć serwer bo przecież gdzieś to musi uruchomić Autor pisze o systemie autoryzacji a Ty opowiadasz o XSS jakby to miało cokolwiek wspólnego. Wracając do tematu to zależy co rozumiesz pod słowem "bezpieczny"... Ogólnie przy systemach autoryzacji powinieneś wziąć pod uwagę jeszcze takie rzeczy jak Brute-force i zastosować np. 1. Po 3 nieudanych próbach - kolejne próby dostępne co minutę. 2. Max. 10 nieudanych prób logowania, potem blokada konta, aktywacja poprzez mail do właściciela. Poza tym, już niezwiązane z brute-force: 1. Zastosować SSL. 2. Uważać na tzw. replay attack poprzez nieużywanie danych, które umożliwiają trwały dostęp do zasobów. Szczególnie tzw. trwały login. Jeśli już używasz takich zabawek to nie trzymać w ciastkach hasła i loginu, nawet zhashowanych, tylko zastosować dodatkowy identyfikator zamiast loginu + token zamiast hasła. 3. Przy logowaniu zastosować hasła maskowane, klawiaturę ekranową... No i oczywiście SQL Injection. Wszystko zależy od tego jak bardzo "bezpieczny" chcesz mieć system autoryzacji. Jeśli chodzi bezpośrednio o kod, który podałeś to: 1. Nie używaj Select *... 2. Dodaj LIMIT do zapytania 3. Nie sprawdzaj mysql_num_rows($query)>0 tylko mysql_num_rows($query)===1 -> zalogowany 4. Dodaj ograniczenie długości dla wprowadzanego hasła i loginu. 5. Nie trzymaj w sesji nazwy użytkownika tylko np. wspomniany już losowy identyfikator... ..i to tyle z rzeczy, które teraz przyszły mi do głowy. Ten post edytował LonelyKnight 5.06.2008, 09:36:37 -------------------- Good programming is 99% sweat and 1% coffee.
Make it idiot proof and someone will make a better idiot... |
|
|
5.06.2008, 08:25:43
Post
#12
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 18.09.2007 Ostrzeżenie: (0%) |
Zobaczcie czy teraz jest lepiej. Dodałem sprawdzanie długości loginu i hasła, wstawiłem session_regenerate_id();, dodałem limit do zapytania, wywaliłem zapisywanie loginu do sesji i dodałem wylogowywanie.
Czy teraz jest lepiej? Ten post edytował MGreg 5.06.2008, 10:27:15 |
|
|
5.06.2008, 10:22:53
Post
#13
|
|
Grupa: Zarejestrowani Postów: 57 Pomógł: 12 Dołączył: 6.01.2008 Skąd: Wrocław Ostrzeżenie: (0%) |
|
|
|
5.06.2008, 11:27:19
Post
#14
|
|
Grupa: Zarejestrowani Postów: 240 Pomógł: 13 Dołączył: 1.06.2007 Skąd: Wrocław Ostrzeżenie: (0%) |
Dlaczego trzymanie nazwy użytkownika w sesji może być niebezpieczne? Dlatego, że w niektórych przypadkach można ujawnić dane sesji użytkowników. Jeśli atakujący to zrobi i zobaczy jak sesja wygląda, co zawiera, którego użytkownika dotyczy... to będzie miał spore pole do popisu. Szczególnie trzeba uważać na współdzielonych hostingach. -------------------- Good programming is 99% sweat and 1% coffee.
Make it idiot proof and someone will make a better idiot... |
|
|
5.06.2008, 11:49:12
Post
#15
|
|
Grupa: Zarejestrowani Postów: 24 Pomógł: 0 Dołączył: 18.09.2007 Ostrzeżenie: (0%) |
Wracając do tematu... czy może ktoś obiektywnie ocenić, czy ten mój poprawiony system uwierzytelniania jest lepszy niż poprzedni i czy trzeba w nim coś zmienić?
|
|
|
5.06.2008, 12:33:43
Post
#16
|
|
Grupa: Zarejestrowani Postów: 240 Pomógł: 13 Dołączył: 1.06.2007 Skąd: Wrocław Ostrzeżenie: (0%) |
Może być.
session_regenerate_id(true) zamist session_regenerate_id(). Ten post edytował LonelyKnight 5.06.2008, 12:34:06 -------------------- Good programming is 99% sweat and 1% coffee.
Make it idiot proof and someone will make a better idiot... |
|
|
5.06.2008, 15:49:34
Post
#17
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
To jeszcze powiedz autorowi jak powinien zabezpieczyć serwer bo przecież gdzieś to musi uruchomić Autor pisze o systemie autoryzacji a Ty opowiadasz o XSS jakby to miało cokolwiek wspólnego. Autor pyta o ten kawałek kodu co podał, a tam NIE MA zabezpieczenia przed XSS, dlatego o tym powiedziałem. 1. Nie używaj Select *... Niby dlaczego nie? 2. Dodaj LIMIT do zapytania Co to ma dać? Dłuższe zapytanie? 3. Nie sprawdzaj mysql_num_rows($query)>0 tylko mysql_num_rows($query)===1 -> zalogowany W przypadku tego kawałka kodu co to za różnica? Lecz powinno się też sprawdzać czy użytkownik już istnieje. 5. Nie trzymaj w sesji nazwy użytkownika tylko np. wspomniany już losowy identyfikator... A co? Uważasz, że to niebezpieczne? Cytat Dlatego, że w niektórych przypadkach można ujawnić dane sesji użytkowników. Jeśli atakujący to zrobi i zobaczy jak sesja wygląda, co zawiera, którego użytkownika dotyczy... to będzie miał spore pole do popisu. Szczególnie trzeba uważać na współdzielonych hostingach. To może nie używajmy wogóle baz danych, plików txtowych ani wogóle niczego, bo w niektórych przypadkach można je ujawnić? w -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
5.06.2008, 16:55:39
Post
#18
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Nie Select * tylko wybrane pola czyli Select pole1, pole2. Chodzi o to aby w przypadku ataku luki itp. można było wyciągnąć dane z tych pól a nie np. z pola password itp. Limit to samo w razie ataku pobierze jednego usera a nie całą tablice userów. A co do sesji to lepiej dmuchać na zimne
|
|
|
5.06.2008, 18:44:24
Post
#19
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Nie Select * tylko wybrane pola czyli Select pole1, pole2. Chodzi o to aby w przypadku ataku luki itp. można było wyciągnąć dane z tych pól a nie np. z pola password itp. Czy chociaż sam rozumiesz co tu napisałeś ^^? Limit to samo w razie ataku pobierze jednego usera a nie całą tablice userów. Co to za różnica, tak czy inaczej mozna pobrac całą tablicę userów. A co do sesji to lepiej dmuchać na zimne aha... czyli potwierdzają się moje słowa panie "włamywacz"? Cytat To może nie używajmy wogóle baz danych, plików txtowych ani wogóle niczego, bo w niektórych przypadkach można je ujawnić?
Ten post edytował pyro 5.06.2008, 18:45:21 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
5.06.2008, 20:25:36
Post
#20
|
|
Grupa: Zarejestrowani Postów: 1 085 Pomógł: 231 Dołączył: 12.05.2008 Ostrzeżenie: (0%) |
Dalej nie ma tam żadnej wzmianki o tym, że autor chce wyświetlać tekst pochodzący z formularza. Już nawet napisałam, że może tam spokojnie umieścić swoje wszystkie hasła, ale póki tego nie zrobi nie ma po co męczyć go stwierdzeniami: pamiętaj, nie wypisuj swoich haseł na stronie
Jedna uwaga - jeśli action jest logout, to mimo wszystko wykona się dalszy kawałek kodu. Co prawda pewnie nic się nie stanie, ale po co maszyna ma mielić coś, czego użytkownik nie ma na myśli. Spokojnie użyj tam else. |
|
|
Wersja Lo-Fi | Aktualny czas: 18.04.2024 - 09:38 |