![]() |
![]() |
![]()
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 :-) |
|
|
![]() |
![]()
Post
#2
|
|
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 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 16.10.2025 - 18:11 |