Witam,
Strwożyłam prostą stronę z panelem administracyjnym. Właśnie dostałam wiadomość od firmy testującej ze aplikacja jest dziurawa i właśnie siedzą w moim panelu admina i mogą dowolnie modyfikować dane (podali login i hasło które faktycznie zapisałam w bazie).

Dodam ze login i hasło przechowuje w bazie w postaci jawnej (nie md5), do tego logowanie robię metoda POST. Na stronie jest tez wyszukiwarka która jak wiadomo łączy się z baza. Danych przesyłanych z formularza nie przepuszczam przez funkcje addslashes() ale czy robiąc to zapobiegłabym przed wykradzeniem z bazy loginu i hasła?

Proszę napiszcie jakie są sposoby aby porządnie zabezpieczyć prosta stronę z panelem admina aby nikt nie mógł dostać się do mojego loginu i hasła?

Umieść ten skrypt na obcym serwerze zmień hasło i login , niech wtedy testują i zobaczymy czy są tacy dobrzy. (są programy które odkodują md5 ), znajdziesz je w internecie, w książce PHP5 zaawansowane programowanie opisany jest w miarę bezpieczny sposób logowania- sesje i inne tam...,
Na każdego można mieć haka , dajcie mi tylko człowieka.

http://phpedia.pl/wiki/Jak_odkodowa%C4%87_MD5%3F

Jedno jest pewne, że jak zabezpieczysz się przed sql injection to będzie trudniej. O sql injection możesz poczytać tutaj.

Dodatkowo przechowuj tylko hash dla hasła. Zdecydowanie utrudnia to uzyskanie hasła nawet po włamie do bazy.
Pytanie w jaki sposób uzyskali login i hasło, może mają dostęp do ftp?

Co do 'odkodowania md5' - nie można odkodować md5! Co najwyżej można znaleźć ciąg znaków, który daje taki sam hash.

Jeżeli angielski nie stanowi przeszkody możesz zawsze poczytać SM

Przed SQL Injection najskuteczniej chroni się aplikację używając zapytań preparowanych i podpinania parametrów, ponieważ pod takie zapytanie silnik bazy sam podstawia przekazywane wartości i nie wykonuje SQLa w nich zawartego. Poczytaj w manualu o PDO/mysqli i prepared statements.

Ja mam jeszcze inny sposób.
Z tego co przeczytałem wnioskuję, że nie znasz się za dobrze na PHP dlatego podam Ci kilka innych metod, które w kilka sekund mogą zmniejszyć ryzyko sforsowania zabezpieczeń Twojego systemu.

1. nie używaj addslashes (bo nie do tego służy) tylko mysql_real_escape_string
2. ogranicz maksymalną ilość znaków w polu nazwy użytkownika i hasła (jeśli username nie będzie dłuższy niż 6 znaków to ustaw max na tyle ile trzeba)
3. szyfruj hasła w SHA1 lub MD5 (sugeruję to pierwsze)
4. po prostu ukryj gdzieś panel logowania dla administratora (i zablokuj dla google bot - none)
5. monitoruj logowania - będziesz wiedział, czy coś jest nie tak [użyj do tego bazy danych, zapisu IP, hosta, daty, godziny, przeglądarki, id sesji i... to chyba wystarczy] - aczkolwiek to już jest tylko dla Twojej informacji - nie zabezpieczy...

Pozdrawiam.

Wybacz, ale w jaki sposób wpłynie to na bezpieczeństwo aplikacji? Moim zdaniem tylko i wyłącznie w sposób negatywny. Wówczas dasz potencjalnemu włamywaczowi informację o maksymalnej długości pola z nazwą użytkownika.

Nie koniecznie musi być to 6 znaków. Na przykład użytkownik ma nick 'forsa', a max długość ustawić można na 7... Podobnie dlaczego by nie wprowadzić na np. 20 znaków. Przecież nikt nie wybiera tak długiej nazwy użytkownika.
Chodzi bardziej o to byś nie mógł wklepać w pole kawałka zapytania SQL. Bo przepraszam, ale bez ograniczenia to można by zrobić spore zamieszanie...
Każda metoda jest dobra, tak samo każdy ma swój punkt widzenia.
Sądzę, że jest to pewnego typu zabezpieczenie (choć mierne ale zawsze), alternatywne rozwiązanie jego problemu.

Punkt 5ty kolegi rozwinąłbym o dodawanie do bazy wpisanej treści w pole hasła.
Fajnie potem sobie poczytać co to hakierzy próbowali wpisać w hasło (w stylu or 1=1).
Najlepiej o błędnych logowaniach informować przez maila - można szybciej zareagować, a jeśli dostaną się do bazy to raporty mogą usunąć.

Co do długości loginu / hasła - ja bym po prostu zaproponował walidacje, która by określała dozwolone znaki (preg_match) i w pregu lub osobnej funkcji także liczbę znaków.

I tu się mylisz. Czasami nazwa użytkownika = adres email.

Na wszystko są sposoby FILTER_VALIDATE_EMAIL

Poza tym argumenty "bo loginem może być data urodzenia" są bezpodstawne - na każdy typ danych znajdziesz metodę zabezpieczenia a skracanie do określonej ilości znaków loginu czy hasła to raczej podstawa

No i co w związku z tym, że istnieje wbudowana walidacja maila? Rozchodzi się o ograniczanie ilości znaków, a adres e-mail może być spokojnie dłuższy niż przykładowe 20 znaków.

@down:
Raczej o to, że ciężko jest czasami ograniczyć liczbę znaków do takiej ilości, żeby taka forma zabezpieczenia miała sens. Jak chcesz się spierać o głupoty to mogę napisać, że nie ma też informacji o tym, że login mailem nie jest.

Rozchodzi się o to, że szukasz dziury gdzie jej nie ma... bo z tego co widziałem [czytałem] nie ma wzmianki o tym, że login to mail...

Kto dzisiaj próbuje "odkodować" hashe?
Tęczowe tablice - to jest odpowiedź ;]

@topic
Zobacz sobie teraz logi z serwera, zobacz jakich ataków próbowali, jak modyfikowali adresy, jakie dane przesyłali do Twoich skryptów.
Wtedy będzie można myśleć jak to zabezpieczyć a nie strzelać w ciemno.

Zapewne ograniczysz długość loginu za pomocą atrybutu maxlength, czyż nie? No to mistrzu FireBug i w 5 sekund podmieniam tą wartość na dowolną inną. Jak już chcesz ograniczać to tylko poprzez substr() po stronie aplikacji. Pewnie teraz napiszesz "to miałem na myśli!" w co i tak nie uwierzę.

PS: czepiam się, bo Twoje wypowiedzi mają charakter typu "ja się znam" - chciałbym Cię nieco sprowadzić na ziemię.

A nie przypadkiem strlen / dla polskich znaków: mb_strlen ? ;]

Chyba nie, bo tym się raczej nie da ograniczyć długości stringa...

Nie możesz ucinać loginu! W ten sposób użytkownik Test|owy będzie mógł się zalogować na konto Test|era. (| symbolizuje maksymalną długość).

Tak czytam tą dyskusję i zastanawiam się, czy jest sens w ogóle dalej się rozwodzić nad skracaniem loginu? Skracasz dane do długości takiej, jaką ma odpowiednie pole w bazie. Resztę musisz i tak zabezpieczyć odpowiednim escapeowaniem zapytań, przed ich wysłaniem do bazy. Kropka. Co z tego, że ograniczysz login, np. do iluś znaków, jak ktoś Ci może w pole z nazwą usera wpisać:

[SQL] pobierz, plaintext 
' OR 1=1;
[SQL] pobierz, plaintext 

Jeśli nie zabezpieczysz kodu przed spreparowanym zapytaniem, to żadne skracanie nic Ci nie da.

A to ciekawe

[PHP] pobierz, plaintext 
if (strlen($string) > 12) {
echo 'Uciekaj !';
}
[PHP] pobierz, plaintext 

Jak nie wiesz, to błagam nie mieszaj w temacie.

Chyba sobie żartujesz... Napisałem wyraźnie, że POPRZEZ STRLEN NIE DA SIĘ OGRANICZYĆ długości łańcucha.Zastanów się proszę, czy w takim wypadku lepiej używać ifowania i tego typu cudów, zamiast prostego substr, które zaproponował @phpion. Równie dobrze możemy liczyć długość za pomocą count. Ale po co? Tylko dlatego, że się da? @Phpion miał w 100% rację. Do ograniczania długości stringa w PHP służy substr, nie strlen. Kropka.

Ciekawe.

[PHP] pobierz, plaintext 
<?php
 
$string = 'aasdfasdf';
 
var_dump(strlen($string));
echo '<br/>';
var_dump(count($string));
 
?>
[PHP] pobierz, plaintext 

Mądralo, przeczytaj opis obu funkcji o których mowa, bo w tym momencie sypiesz jakimiś teoriami wyssanymi z palca.
Przeczytaj dokładnie do czego służy substr - według mojej wiedzy do "przycinania"/"wycinania" odpowiedniej długości ze stringa - ni jak ma się to do sprawdzania jego długości. W momencie użycia tej funkcji w sposób jaki zaproponowałeś, nie zawiadomisz użytkownika o zbyt długim tekście, lecz przytniesz go do swojej ustalonej długości, a przy rejestracji konsekwencje mogą być dramatyczne, bo ktoś dostanie zupełnie inny nick niż zakładał.

luck, wyobraź sobie sytuacje, że wpisujesz numer konta bankowego w formularzu, który składa się z 26 cyfr. Podczas wpisywania niechcący nacisnąłeś 2x dowolną liczbę. Wysłałeś przez formularz 27 cyfr i jak sugerujesz lepiej od razu uciąć ciąg do określonej liczby - 26, zamiast sprawdzić przez strlen długość ciągu i wyświetlić odpowiedni komunikat. Nie wolno ucinać ciągu i zapisywać do bazy bez powiadomienia i ewentualnego poprawienia tych danych przez użytkownika.

Taa, jasne... Mów mi jeszcze Przeczytaj powoli, najlepiej kilka razy: nasza dyskusja rozpoczęła się od postu @phpion, który poruszał problem ograniczania długości poprzez maxlength, tego że jest to tylko w niewielkim stopniu skuteczne i należy do tego celu dodatkowo stosować substr po stronie serwera. Przypominam, że Ty stwierdziłeś, że do tego służy strlen, prawda? Sorry, ale jeśli nie odróżniasz słów "sprawdzać długość" od "ograniczać" to nie mamy o czym dyskutować. Cały czas piszę o ograniczeniu, tudzież przycinaniu łańcucha. Koniec z mojej strony w tym temacie.

No właśnie, do przycinania/wycinania, czyli ograniczenia długości ciągu. Dokładnie to samo robi atrybut maxlength - pozwala wpisać X znaków, resztę odrzuca (nie można wpisać). Zwróć uwagę, że w tym momencie nie chodzi o walidację wprowadzanych danych tylko ograniczenie długości wprowadzanego tekstu.

Nie robi dokładnie tego samego. Jak sam zauważyłeś "pozwala wpisać X znaków" ale nic nie przycina. Przykład, który podał Wicepsik jest bardzo dobry. Jeżeli programiści mieliby podejście takie jak Wy, to szkoda gadać...człowiek się gdzieś pomyli i pełno kłopotów.

Co do walidacji, zapytam się tak: Jeżeli Ci ktoś nie powie, że musisz zjeść śniadanie to go nie zjesz?

phpion - równie dobrze, według Twojego rozumowania, można ustawić w bazie pole o ustalonej wielkości powiedzmy 20 znaków i równie dobrze MySQL sobie sam przytnie. To może ja Ci pokaże jakie są tego konsekwencje.

Tutaj !

Poza tym, może nie zwróciłeś uwagi ale nazwa tematu brzmi: "włam do bazy" - chyba wystarczy, aby ruszyć głową że trzeba będzie walidować dane wprowadzone przez użytkownika.

Z łaski swojej zobacz czego tyczy nasza dyskusja:

Kolega podał pomysł ograniczenia maksymalnej ilości znaków w polu nazwy użytkownika dodając "ustaw max na tyle ile trzeba". W tym przypadku ustaw = przytnij. To, że normalna walidacja powinna opierać się na sprawdzaniu długości wprowadzanych danych, a nie na ich skracaniu to sprawa oczywista. Jednak dyskusja toczy się w innym kontekście.

Zajedwabista dyskusja...


Jak dla mnie to raczej [ $ustaw_max = 15; if(strlen($login) > $ustaw_max)]... ale widać każdy interpretuje ten kawałek tekstu jak wiersze Szymborskiej

a po cóż to w ogóle ograniczać długość wprowadzonych danych?
odpowiednia walidacja i styknie....

Pomyśl logicznie...
Ile jest ludzi w naszym świecie, którzy za wszelką cenę chcą udowodnić jacy to z nich hakerzy.
Jak dla mnie ograniczenie max. ilości znaków to podstawa. Nie mówię tu o ograniczeniu do tylu ilu trzeba, lecz tak by nie mógł wprowadzić w pole nieskończonej ilości znaków.
Jest to zabezpieczenie marne ale jest i z początku może zniechęcić początkującego 'włamywacza' (a raczej pseudo) do dalszych prób.
Nie wiem po co ta dyskusja. Podałem to jako przykład co nie znaczy, że kolega musi go wykorzystać.
Fakt; jest na pozycji 2 (i jak się domyślam zasugerowało Wam to, że uważam to jako bardzo istotny element) ale najistotniejszym jest jednak poprawna walidacja otrzymanych danych. =)

Pozdrawiam.

po to żeby ktoś nie wrzucił "jfiewofjiwoefjiwoejfioefjwkeljfklwjefkldsjklfe4nmwf4wfhdiowjfioejfwkl3irjw3
o4fuiewojiofjweofhdfsjhfsdkhfjkehfksdjebgwkhrjkwehfsdkjfhenmfbushejkdsfk" x 100
do bazy stworzonej przez początkującego programistę, który jako typ kolumny ustawił text a nie varchar(10) ? ? ?

Pomnóż to przez ilość rejestracji zrobionych cURLEM i masz odpowiedź..

Pięknie ujęte CuteOne

źle mnie zrozumiałeś...
oczywiście od strony serwera musi być zabezpieczenie przed tym, aby nie wysyłać do bazy niepotrzebnych danych, jednakże tutaj były propozycje o ograniczeniach po stronie klienta i do tych chciałem się odnieść jako bezcelowe.

To chyba oczywiste, że po stronie klienta można zmienić niemalże wszystko. Wystarczy 5min w google i znajdzie się masę rozwiązań.
Aczkolwiek nie zgadzam się z Tobą w 100%. Są bardziej i mniej zaawansowani (początkujący) hakerzy, którzy nawet tego typu zabezpieczenia (choć trudno go tak nazwać) przez "maxlength" nie potrafią ominąć.
Wszystko zależy od tego kogo się spodziewamy
Dużo pracy w to nie włożysz, a czasem może uratować...

załózmy, że mamy taką sytuacje:
- system jest odporny na ataki zaawansowanych hakerów
i teraz wynika z Twojego postu, że pisząc dodatkową walidację po stronie klienta typu ograniczenia długości loginu "czasem może mnie uratowac". Przed czym moze mnie uratowac, jesli zgodnie z założeniem mamy system odporny na ataki.

Rozumiem walidację po stronie klienta jako ułatwienie dla klienta wypisywania formularzy, przykład:
w polu daty urodzenia podał 32-20-9000 no to od razu obok pola jakiś krzerwony krzyżyk, informacja, że pole jest błędnie wypełione, żeby od razu zobaczył gdzie ma bląd, a nie potem szukał po wysłaniu zgodnie z wyswietlonym mu komunikatem "cos jest źle, przejrzył cały formularz jeszcze raz, zastanów sie, gdzie popełniłes bład, powodzenia w szukaniu"


Aha, czyli jeszcze pisząc aplikację mam tworzyć rozne systemu zabezpieczen:
1. jesli klient jest potencjalnym hakerem o małej wiedzy, to daj tylko maxlength
2. jesli klient jest potencjalnym klientem o dużej wiedzy, to filtruj pakiety już w routerze, bo jeszcze wirusa prześle na serwer ...

System zabezpieczeń powinien być uniwersalny, ale również minimalistyczny i optymalny, czyli taki aby nie powodował dodatkowych trudności u klienta jak i nie wykorzystywał na daremno mocy obliczeniowej komputera,
przykład:
$super_haslo = sha1(sha1(sha1(sha1( ... sha1( $login ) ... ))));

up: co za problem dać dwa rodzaje zabezpieczeń? te po stronie przeglądarki, żeby ino zwykły użytkownik wiedział ile liter na login może "wykorzystać" i te po stronie serwera czyli właściwe zabezpieczenie przeciwko wszelkiej maści hakierom i hakerom

rzymek01...



Rzeczywiście, maxlength bardzo obciąża procesor, powoduje dodatkowe problemy u klienta i na dodatek trzeba włożyć ogromny wysiłek żeby tego typu 'pseudo zabezpieczenie' wprowadzić. Gratuluję rozumowania.
A pisząc "Wszystko zależy od tego kogo się spodziewamy" miałem na myśli to, że mała stronka chyba będzie mniej popularna od na przykład serwisu społecznościowego (gdyby ktoś chciał się za tego typu projekt zabrać ;p), a co za tym idzie zabezpieczenia nie muszą być idealne i milion razy sprawdzone. To chyba oczywiste, że nk / facebook atakowane są częściej niż dajmy na to http://dpage.pl/ (bez urazy xP).

Pomyśl czasem zanim cokolwiek napiszesz...

skoro już taki temat jest.. zapytam się o rade.. moja walidacja wygląda w następujący sposób.. na dane pole ustawiam maxlength . dane wysyłam POSTem . przy odbiorze danych używam if + strl sprawdzając czy dany POST ma minimalna długośc i mieści się w max jeśli wszystko ok następnie POST przypisuje 'zwykłej zmiennej" używajac albo ABS - jeśli POST musi być INT albo htmlspecialchars(addslashes( jesli to string . następnie dodaje do tabeli używajac jeszcze mysql_real_escape_string . Czy to dobre zabezpieczenie (nie jestem pewien ale chyba addslashes nie powinno się używac w połączeniu z real escape string mam racje

A to nie mogłeś sprawdzić co robi każda z funkcji? Zamiast zapytać, najpierw czytaj, potem testuj, potem pytaj.

źle mnie zrozumialeś pytanie nie było czy funkcja addslashe działa tak samo real escape string tylko czy taka forma walidacji jest prawidłowa a może zła lub nie do końca

Do czego innego użyjesz mysql_real_escape_string a do czego innego addslashes, tutaj chyba nie ma czego tłumaczyć. ;p

Podsumowując wystarczy Ci przy zapisie do bazy mysql_real_escape_string

wg mnie starczy informacja o tym, a nie "na siłę" zakazywać, nie bo nie, nie róbmy z użytkownika totalnego idioty,
oczywiście jeśli wpisze np. 10 znaków, a max ma być 8, to powinno się wyświetlić cokolwiek co poinformuje użytkownika o tym.
Dla przykładu załózmy taką sytuację:
starsza osoba, niech będzie to babcia, rejestruje się na stronie,
patrzy cały czas na klawiaturę, bo nie umie pisac bezwzrokowo i wpisuje sobie 10 znakowy login (a w formularzu jest maxlength 8), gdzie tutaj jeszcze jest możliwa korekta błędu, gdy zauwazy że literki sie nie zgadzają, ale w polu typu password literek nie widac i tak zamiast 10 znakowego hasła wymyślonego przez babcię, do bazy zostaje zapisane hasło 8 znakowe
tutaj powiecie: zaraz, zaraz, ale w formularzu do logowania, rowniez jest ustawiony maxlength dla hasła, więc wszystko cacy,
otóz nie, bo niech chociażby zmienimy sobie maks. długosc hasła na stutek jakiejś propagandy na temat długości hasła i ustawiomy wszędzie maxlength 9, i co?
babcia się nie zaloguje....

@modern-web, to samo co wyżej napisałem + to, że jednak musisz to napisać oraz pamiętać o tym, gdzie to napisałeś, aby w przyszłości móc zmieniać system zabezpieczeń

Pozdrawiam

Po 1: mały procent 'starszych' osób korzysta z internetu - nie wiem czy to zauważyłeś ale wątpię.
Po 2: prędzej poproszą o to bystrego wnusia...
Po 3: zszedłeś z tematu (który tak na serio został już rozwiązany...)
Po 4: każdy ma odmienne zdanie więc nie widzę sensu, by dalej ciągnąć tę dyskusję.

nie wiem czy zauwazyłes, ale opisana przeze mnie sytuacja nie dotyczy tylko osób starszych, to był taki przykład najbardziej obrazujący problem,
równie dobrze może to dotyczyc Ciebie, bo jak wpisujesz kilkunaste znakowe hasło do formularza nie mieszącego wszystkiich znakow to nie zobaczysz czy jeszcze wpisujesz, czy juz nie


odwracasz bieg wydarzeń, staram się jedynie sprostować niektóre wypowiedzi, które już zeszły z tematu


hmm, każda osoba może mieć odmienne zdanie na cokolwiek, to znaczy, żeby ze sobą nie rozmawiać?
Wolę rozmawiać i spierać się, gdyż to jest cywilizowany sposób wymiany zdań, chyba, że wolisz prawo dżungli

Pozdrawiam