[PHP] przekazywanie ostrzeżen ze skryptu logującego do formularza |
[PHP] przekazywanie ostrzeżen ze skryptu logującego do formularza |
2.04.2008, 19:08:48
Post
#1
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 26.02.2008 Ostrzeżenie: (0%) |
Wityam :-)
Mam taki mały problem. Mianowicie mam takie 2 skrypty odpowiedzialne za lpogowanie użytkowników na stronę. Formularz
oraz skrypt logujący
I teraz mój problem polega na tym, że chem zrobić coś takiego, że jak user powiedzmy poda złe hasło (lub login) to przekierowuje go na strone z formularzem i wyskakuje napis "Podane hasło jest niepoprawne!!!" i adekwatnie ze złym loginem (Napis: "Podane przez Ciebie konto nie istnieje") nad formularzem logowania. Chciałbym żeby takie coś działo się tylko w przypadku gdy ktoś poda złe dane- kiedy loguje się po raz pierwszy to nie ma nic po za formularzem. Mam nadzieje, że wiecie o co mi chodzi :-) Szukałem podobnego tematu, ale nie znalalęm więc proszę Was o pomoc :-) -------------------- |
|
|
2.04.2008, 19:18:24
Post
#2
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
|
|
|
4.04.2008, 15:50:31
Post
#3
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 26.02.2008 Ostrzeżenie: (0%) |
Witam ponownie sorki, że dopiero teraz odpisuje ale nie miałem specjalnie czasu.
Wlamywacz zrobilem tak jak mi poradziłeś i mój kod formularza wygląda teraz tak:
Ale niestety to dalej nie działa Już nie wiem jak to zrobić Teraz jak chcem się zalogować to wyskakuje mi biała strona na której nic nie ma Proszę Was jeszcz o troche cierpliwości...nie jestem jeszcze az tak bardzo doświadczonym skrypciarzem jak Wy ale robie co moge ;-) Ten post edytował paffcio87 4.04.2008, 15:51:27 -------------------- |
|
|
4.04.2008, 18:28:44
Post
#4
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Zrób tak i powiedz czy działa:
I formularz:
Powinno działać |
|
|
5.04.2008, 08:52:24
Post
#5
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 0 Dołączył: 4.04.2008 Ostrzeżenie: (0%) |
Biała strona - Bo dałeś exit();
Buforowania nie dawaj.. ___ Wyżej formularz ___ Niżej skrypt logujący ___ Czy na pewno hasła do bazy wstawiasz kodujac algorytmem base64_encode(); ? Daj session_start(); na początku i usuń buforowanie. Zmienną $message i require(); configa możesz dać po tym. Usuń nawiasy sprzed $password. If-a if($row) zmień na if(isset($row)). |
|
|
6.04.2008, 20:13:44
Post
#6
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 26.02.2008 Ostrzeżenie: (0%) |
Oki wygląda na to, że działa .Tylko jeszcze będę musiał to dopracować ale to już jest najmniejszy problem. Dzięki włamywacz . Tylko chciałbm się jeszcze zapytać jak zrobić takie coś, że kiedy uytkownik poda właściwe dane to opóźnić działanie skryptu i przez chwile pokazać komuniak "Logowanie poprawne czekaj..." czy coś w tym stylu. próbowalem za pomocą "sleep(x)" gdzie x to liczba sekund, ale gdzie bym tego nie dał to skrypt najpierw się opóźnia a dopiero potem przeżuca na index.php bez pokazania żadnego komunikatu.
Ten post edytował paffcio87 6.04.2008, 20:42:02 -------------------- |
|
|
7.04.2008, 14:48:07
Post
#7
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Może klikniesz pomógł ; p
Jeśli dane ok -> przekieruj na taką stronę z preloaderem -> przekierowanie przez html po x sekund Ogólnie google.pl ! |
|
|
8.04.2008, 04:32:51
Post
#8
|
|
Grupa: Zarejestrowani Postów: 74 Pomógł: 4 Dołączył: 7.03.2008 Ostrzeżenie: (0%) |
jak juz piszesz logowanie to:
- poczytaj o session hijacking - konieczni esprawdzaj IP skad sie logowano + ustaw dziwna zmienna dodatkowo i ja sprawdzaj, resetuj ja przy kazdym logowaniu - haslo zapisuj w md5, sha1 i dodawaj swoj ciag znakow do hasla, base64 to kodowanie a nie szyfrowanie da sie odkodowac wiec bez sensu jest go stosowac do utrudniania odczytu hasla, dotego jest szyfrowanie jednostronne - nie uzywaj ", zacznij stosowac ', przyspieszysz kod to popularny blad wsrod programistow powinno byc: 'SELECT * FROM userzy WHERE login="'.$log.'"'; a dokladnie to powinno byc 'SELECT * FROM userzy WHERE login="'.$log.'" LIMIT 0,1'; dla pewnosci ze maksymalnie jeden rekord zostanie zwrocony albo zero wtedy badasz czy wynik == 1 - zauwazylem tez ze przesylasz haslo w postaci jawnej, to blad () przed wyslaniem zdarzeniem onsubmit() zakoduj haslo po stronie usera w md5 lub sha1 i wyslij zakodowane haslo, login tez mozna jak ktos lubi utrudnia to podsluchanie lub zapamietanie danych w komputerze więcej: http://skrypta.pl/porada/dlaczego_unikac_f...anej_w_mysql/44 pozdrawiam i powodzenia -------------------- Skrypty php, ajax, javascript
|
|
|
8.04.2008, 19:47:49
Post
#9
|
|
Administrator wortalu Grupa: Przyjaciele php.pl Postów: 960 Pomógł: 39 Dołączył: 21.10.2003 Skąd: Kraków Ostrzeżenie: (0%) |
Ja troche OT ale...
Cytat - zauwazylem tez ze przesylasz haslo w postaci jawnej, to blad przed wyslaniem zdarzeniem onsubmit() zakoduj haslo po stronie usera w md5 lub sha1 i wyslij zakodowane haslo, login tez mozna jak ktos lubi utrudnia to podsluchanie lub zapamietanie danych w komputerze więcej: http://skrypta.pl/porada/dlaczego_unikac_f...anej_w_mysql/44 Beeezeeduraa. Powiedz co mi da jak ktoś będzie sniffował że będę wysyłał hasło już zahashowane? Nic. Jak przechwyci hashe to potem tak samo jak otwarty tekst będzie mógł ich użyć do zalogowania. |
|
|
8.04.2008, 20:11:57
Post
#10
|
|
Grupa: Zarejestrowani Postów: 1 387 Pomógł: 273 Dołączył: 18.02.2008 Ostrzeżenie: (0%) |
Cytat - poczytaj o session hijacking - konieczni esprawdzaj IP skad sie logowano + ustaw dziwna zmienna dodatkowo i ja sprawdzaj, resetuj ja przy kazdym logowaniu Masz na myśli niszczenie sesji, gdy tylko zmieni się IP użytkownika? Wg. mnie nie najlepsze rozwiązanie, są takie łącza, przy których co każde odświeżenie strony mamy inne IP... -------------------- XMPP: l0ud@chrome.pl
|
|
|
8.04.2008, 21:04:08
Post
#11
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Ogólnie dla mnie herezja i spam raport
|
|
|
8.04.2008, 21:12:12
Post
#12
|
|
Grupa: Zarejestrowani Postów: 74 Pomógł: 4 Dołączył: 7.03.2008 Ostrzeżenie: (0%) |
1) kontrola ip podczas logowania to juz podstawa bezpieczenstwa to juz nie opcja, niestety jesli uzytkownik ma zmienne ip to dla jego dobra nalezy sesje niszczyc i uniemozliwc autologwanie do serwisu - odsylam do http://phpsec.org/projects/guide/4.html o bezpieczenstwie sesji
2) dodatkowa zmienna unikalna dla twojego serwisu resetowana przy kazdym poprawnym logowaniu co utrudni (nie uniemozliwi) porywaczowi id sesji uzycie jej zakladajac ze znajduje sie on w tej samej podsieci i ma ten sam numer ip, wartosc ta powinna byc trzymana w bazie najlepiej w postaci niejawnej i rotowana jak wyzej, podobnie jak token bankowy 3) nie ma 100% zabezpieczenia sesji, sesja z definicji jest dyskusyjna jesli chodzi o bezpieczenstwo 4) Sabistik oczywiscie ktos wysnifuje twoje haslo i przechwyci np: login: marcink haslo: 0ikjn68jh6g7jk97m08k <- juz zakodowane haslo w np md5 (minimum sha1 zalecany) twoj system otrzyma pare login+haslo i zacznie przetwarzac login + wynik md5(0ikjn68jh6g7jk97m08k) w wyniku czego otrzymamy nowe haslo np. 8ujh7891nk1289kn1tr7 co nie odpowiada prawdziwej wartosci hasla wpisanego prze zuzytkownika w postaci jawnej, zatem podsluchiwacz ma teraz dwa wyjscia: - 1 - odgadywac haslo zakodowane w md5 np prze brute force (odsylam wikipedia) co jest wysoce niemozliwe do zrobienia - 2 - odgadnac inny wyraz ktory daje identyczna wynik po parsowaniu szyfrem md5 o ile pierwsza opcja jest niemozliwa z definicji o tyle druga jak najbardziej co udowodnil chinski wykladowca wykorzystujac birthday efekt poprzez szukanie powtorzen w parze wynikowej (wikipedia birthday effect) podsumowujac takie rozwiazanie to nie bzdura to standard! w dzisiejszych czasach jelsi ktos nie stosuje kodowania ssl jesli ktos ma wiecej pytan o bezpieczenstwie chetnie odpowiem -------------------- Skrypty php, ajax, javascript
|
|
|
8.04.2008, 21:25:31
Post
#13
|
|
Grupa: Zarejestrowani Postów: 1 387 Pomógł: 273 Dołączył: 18.02.2008 Ostrzeżenie: (0%) |
guitarnet.pl, nie zrozumiałeś Sebastik a. Nie mówił tu o zapisywaniu hashu w bazie bo to standard. Mówił o braku sensu przesyłania hasła w takiej postaci, bo po co to? Jeżeli ktoś to podsłucha to i tak zaloguje się dla usera. System logowania wymaga przecież hasha i go dostanie.
Co do sesji, sam sobie przeczysz. Artykuł, który podajesz przecież odradza stosowania sprawdzania IP, a jako właściwy przykład podaje porównanie user-agenta. Ten post edytował l0ud 8.04.2008, 21:26:04 -------------------- XMPP: l0ud@chrome.pl
|
|
|
8.04.2008, 21:27:01
Post
#14
|
|
Administrator wortalu Grupa: Przyjaciele php.pl Postów: 960 Pomógł: 39 Dołączył: 21.10.2003 Skąd: Kraków Ostrzeżenie: (0%) |
4) Sabistik oczywiscie ktos wysnifuje twoje haslo i przechwyci np: login: marcink haslo: 0ikjn68jh6g7jk97m08k <- juz zakodowane haslo w np md5 (minimum sha1 zalecany) twoj system otrzyma pare login+haslo i zacznie przetwarzac login + wynik md5(0ikjn68jh6g7jk97m08k) w wyniku czego otrzymamy nowe haslo np. 8ujh7891nk1289kn1tr7 co nie odpowiada prawdziwej wartosci hasla wpisanego prze zuzytkownika w postaci jawnej, zatem podsluchiwacz ma teraz dwa wyjscia: - 1 - odgadywac haslo zakodowane w md5 np prze brute force (odsylam wikipedia) co jest wysoce niemozliwe do zrobienia - 2 - odgadnac inny wyraz ktory daje identyczna wynik po parsowaniu szyfrem md5 o ile pierwsza opcja jest niemozliwa z definicji o tyle druga jak najbardziej co udowodnil chinski wykladowca wykorzystujac birthday efekt poprzez szukanie powtorzen w parze wynikowej (wikipedia birthday effect) podsumowujac takie rozwiazanie to nie bzdura to standard! w dzisiejszych czasach jelsi ktos nie stosuje kodowania ssl jesli ktos ma wiecej pytan o bezpieczenstwie chetnie odpowiem No i dalej pogrążasz się w bzdurze. Nie interesuje mnie co z tym robi twój system po stronie serwera. Ktoś podsłuchuje twoje dane wysłane POSTem/GETem: login: marcink haslo: 0ikjn68jh6g7jk97m08k I w w celu fałszywego logowania wysyłam dokładnie takie dane i zostaje zalogowany bez problemu. Takie hashowanie nic nie daje. Jeśli chcesz się jakoś zabezpieczyć to zainteresuje sie kryptografia asymetryczną np RSA. |
|
|
8.04.2008, 21:33:48
Post
#15
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
guitarnet.pl
Próbujesz robić z siebie eksperta jednak masz braki w wiedzy i troszkę się gubisz... |
|
|
8.04.2008, 22:18:58
Post
#16
|
|
Grupa: Zarejestrowani Postów: 74 Pomógł: 4 Dołączył: 7.03.2008 Ostrzeżenie: (0%) |
nie jestem ekspertem i nigdy nie bede, zapewne z braku czasu i zdolnosci
Sabistik niescislosc z mojej strony, juz wyjasniam, szyfrowanie hasla na lini user-serwer ma na celu ukrycie prawdziwego hasla ktorego przechwycenie pozwoliloby na zwykle zalogowanie sie jako uzytkownik, odnosnie proby zalogowania sie z podsluchanym haslem rowniez sie zgodze, jest to naturalny krok al enie taki oczywisty - nie wiem czy to powszechne ale ja nie pozwalam na odwolanie do pliku obslugujacego proces logowania z innego adresu anizeli adres formularza logowania (dostep do domena.pl/loguj_exe.php ma tylko plik domena.pl/index.php) stad moja teza, brak takiego ograniczenia naturalnie pozwoli na napisanie skryptu ktory wysle dane przez GET lub POST z innej domeny do mojego skryptu logowania co skompromituje caly system. Ograniczenie mozna zmniejszyc do jakiegolwiek pliku nalezacego do dopuszczonej domeny, ciagle pozstaje bezpieczne - jesli uwazasz ze nie, z pokora przyjme nauke zauwaz ze przy jawnym przesylaniu hasla, podsluchiwacz zna login i haslo logujacego i moze skorzystac z formularza logowania na domena.pl, w przypadku zakodowania go w JS musi znac niezaszyforwane haslo aby JS moglo je zaszyfrowac i wyslac, ktos moze krzyczec ze strona wymagajaca JS to amatrostwo, no coz, taki koszt mojego bezpieczenstwa jestem w stanie zaplacic - chetnie poznam mozliwe luki tej metody, stosujemy ja z powodzeniem w firmie i dziala.. mam nadzieje! l0ud artykul to dobry przyklad analizy sesji ale jak zauwazysz oni odradzaja poleganie "wylacznie na sprawdzaniu ip" a nie odradzaja tego calkowicie - sprawdzanie ip + przegladarki + dodatkowej zmiennej daje duzo wieksze szanse zabezpieczenia id sesji niz jedna z opcji samodzielnie. temat sesji jest bardzo szeroki a to o czym rozmawiamy to zaledwie czubek gory lodowej, kazdy kto choc troche wglebial sie w bezpieczenstwo sesji wie ze to watek na osobna dyskuje - nie bylo moim zamiarem narzucanie sie z metoda zabezpieczania ani opisana jej, ale czytajac post rzucil mi sie w oczy ten szczegol w wywolaniu sesji wiec odpisalem. zgadzam sie , na bepzieczenstwo sesji sklada sie wiele czynnikow, konfoguracja php, prawa w systemie, miejsce przechowywania sesji i sporo wiecej rzeczy, ba nawet kod obslugi logowania sesji jest dosc dlugi i kazdy ma swoj, moim zamiarem bylo raczej zasygnalizowac problem i pokazac przynajmniej to minimalne zabezpieczenie ktore powinno sie stosowac nie wiem czy to co napisalem da sie odczytac bo sam sie pogubilem stylistyczno-gramatycznie, mam nadzieje ze merytorycznie ujalem moje zdanie i metode w tej odpowiedzi pozdrawiam -------------------- Skrypty php, ajax, javascript
|
|
|
8.04.2008, 22:52:17
Post
#17
|
|
Administrator wortalu Grupa: Przyjaciele php.pl Postów: 960 Pomógł: 39 Dołączył: 21.10.2003 Skąd: Kraków Ostrzeżenie: (0%) |
Cytat nie wiem czy to powszechne ale ja nie pozwalam na odwolanie do pliku obslugujacego proces logowania z innego adresu anizeli adres formularza logowania (dostep do domena.pl/loguj_exe.php ma tylko plik domena.pl/index.php) stad moja teza, brak takiego ograniczenia naturalnie pozwoli na napisanie skryptu ktory wysle dane przez GET lub POST z innej domeny do mojego skryptu logowania co skompromituje caly system. Ograniczenie mozna zmniejszyc do jakiegolwiek pliku nalezacego do dopuszczonej domeny, ciagle pozstaje bezpieczne - jesli uwazasz ze nie, z pokora przyjme nauke zauwaz ze przy jawnym przesylaniu hasla, podsluchiwacz zna login i haslo logujacego i moze skorzystac z formularza logowania na domena.pl, w przypadku zakodowania go w JS musi znac niezaszyforwane haslo aby JS moglo je zaszyfrowac i wyslac, Wybacz, ale przy pomocy jedynie Firebuga mogę wywalić twojego js'a przy zachowaniu odpowiedniego referera. Jeszcze raz powtarzam, poczytaj o kryptografii asymetrycznej. |
|
|
8.04.2008, 23:22:13
Post
#18
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 26.02.2008 Ostrzeżenie: (0%) |
Hehe widze, że prosząc Was o pomoc wywołałem niezłą dyskusje . Szczerze mówiąc to przeczytałem Wasze posty tak po łebkach narazie bo coś nie chce mi się myśleć o tej porze dzisiaj i dochodze do wniosku, że nie wiele z tego rozumiem. Może jak przysiąde do tego któregoś dnia bardziej dokładnie to się od Was czegoś naucze. Stronka, nad którą obecnie pracuje jest moim pierwszym projektem, a głównym jej zadaniem jest to żeby poduczyć się troszkę PHP, a kwestia zebezpieczeń to chyba jest obecnie moja nasłabsza strona (wiem wiem...aż wstyd się przyznać ). W każdym razie dziękuje wszytkim za spam w tym temacie na pewno coś dobrego z tego wyciągnę (jak tylko zachce mi się myśleć) .
-------------------- |
|
|
9.04.2008, 14:05:34
Post
#19
|
|
Grupa: Zarejestrowani Postów: 1 033 Pomógł: 125 Dołączył: 17.09.2005 Skąd: Żywiec Ostrzeżenie: (0%) |
Myślę, że hash'owanie hasła po stronie przeglądarki nie jest głupim pomysłem.
Wiadomo, że nie zabezpieczy to przed włamaniem na stronę, do której leciały podsłuchane pakiety. Jednak trudniej jest w takim przypadku odzyskać oryginalne hasło użytkownika - a to już ma spore znaczenie. Szczególnie jeśli podsłuchujemy kogoś, kto używa tego samego hasła udostępniając zdjęcia na http//milosnicykotowperskich.prv.pl i obracając grubszymi pieniędzmi na https//zakladysportowe.com Nie ma też problemu z przeglądarkami w których JS jest wyłączony - można wtedy wysyłać hasło jawnie. Do tego kilka linijek w PHP, które w razie potrzeby przepuszczą hasło przez md5" title="Zobacz w manualu PHP" target="_manual i mamy w pełni funkcjonalne logowanie. -------------------- "Sumienie mam czyste, bo nieużywane."
|
|
|
9.04.2008, 16:19:12
Post
#20
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Cytat Nie ma też problemu z przeglądarkami w których JS jest wyłączony - można wtedy wysyłać hasło jawnie. Do tego kilka linijek w PHP, które w razie potrzeby przepuszczą hasło przez md5 i mamy w pełni funkcjonalne logowanie. Chyba nie przemyślałeś tego co napisałeś... Jeśli podsłuchał jedno hasło to zrobi to samo przy drugim |
|
|
Wersja Lo-Fi | Aktualny czas: 27.04.2024 - 15:08 |