Witam,

Jestem ciekawy Waszych doświadczeń i sposobów zabezpieczania formularzy przed niebezpiecznymi wpisami (zaznaczam ze nie chodzi mi o to jak zrobić aby cyferek nie wpisać).

Moje doświadczenie w tym zakresie jest znikome zaś literatura w tym zakresie też jest skromna.

Skoro już temat znalazł się na php pro to proponuję go poszerzyć o ogólne zasady związane z bezpieczeństwem aplikacji. Sądzę, że ktoś rozwinie temat. Na początek kilka uwag:

Instalacja php - należy zwracać uwagę na opcje mające kluczowy wpływ na bezpieczeństwo działania serwera. php jako moduł CGI jest bardziej podatne na ataki niż skompilowane statycznie z Apache'm (niestety kompilacja statyczna jest mało elastyczna). Jeśli już php kompilujemy jako CGI to musimy dabć by były włączone flagi takie jak --enable-force-cgi-redirect - chyba, że chcemy aby ktoś nam grzebał w katalogach do których teoretycznie zabezpieczyliśmy dostęp przez .htaccess (szczegóły w książce PHP4 Aplikacje).
Pliki - wszystko co nie jest zwykłym HTML'em lepiej trzymać poza głównym drzewem Apache'a. Nigdy nie wiemy czy nie zostanie odkryta dziura w Apache'u, przez którą będzie można dostać się do udostępnianego katalogu?
Skrypty - wszystkie dane z zewnątrz (GET, POST, COOKIE <- też) należy traktować jako podejrzane. Nie zakładajmy, że ktoś po prostu kliknął na naszej stronie link i parametry, które otrzymujemy pochodzą właśnie stamtąd. Ktoś może napisać własny skrypt i walić nam dane POST'em takie jakie mu się tylko przyśnią. Każdy może zmienić zmienną i dostać się do strony, która jest nie dla niego, jeśli mu na to pozwolimy. Dlatego wszystko należy przefiltrowywać (wydaje mi się, że widziałem kiedyś na Zend'zie skrypt kontrolujący, czy zmienne przekazywane pomiędzy naszymi stronami nie zostały zmodyfikowane - test sumą kontrolną, czy czymś w tym rodzaju), a jeżeli zmienna wpływa na dostęp do plików to MUSIMY zadbać o to, żeby nikt nam nie zmieniał ścieżek dostępu (vide funkcja basename()) i nie wydawał poleceń systemowych (vide EscapeShellCmd()). O użyciu exec() już nawet nie wspominam.
Sprawa o której mało kto pamięta: długość zmiennych - lepiej to kontrolować, bo każdy bufor da się przepełnić, a DenialOfService to nie najprzyjemniejsza sytuacja.
Następna sprawa: register_globals=off to dobry nawyk. Co prawda sesji nic nie grozi ale już zmienne środowiskowe da się nadpisać (variables_order=EnviromentGetPostCookieSession). Jak mamy Off to wszystko jest pod kontrolą i w dodatku wyrabiają się nam dobre nawyki programistyczne.
Jeśli zabieramy się za szyfrowanie to róbmy to z głową - funkcje typu MD5 albo biblioteka MCrypt to dobre rozwiązanie, a własna twórczość niekiedy nie.
Próbując zydentyfikować użytkownika albo cokolwiek innego, lepiej nie używać cechy, którą da się manipulować, ani takiej, która nie jest unikalna (np. numer IP). Dla osób unikalny jest PESEL, dla firm REGON (a nie NIP), a np. dla pojazdów VIN (a nie numer rejestracyjny).
Jeśli przez sieć wędrują hasła albo tajne informacje to MUSIMY je szyfrować - najprościej przez SSL. Lepiej męczyć się przez SSL bez wykupienia certyfikatu (uciążliwe komunikaty) niż olać całą sprawę. Sniffer'a może użyć każda lama.
Jeśli można, to zrzucamy do logów wszystko co się da. Można i należy samodzielnie logować wszystkie posunięcia userów w naszym serwisie - opłaci się to, gdy trzeba będzie zidentyfikować problem.
Na koniec taki detal: komunikaty o błędach lepiej przechwytywać i nie walić userom na ekrany, bo usterka może się trafić każdemu, a dla włamywacza informacja typu: 'brak praw dostępu do katalogu cośtam/cośtam/' albo 'Postgres: syntax error in bleble' są bardzo cenne.

Zabezpieczajac dany skrypt itp. musimy tez pamietac, ze jezeli znamy sposob jak go obejsc napewno predzej czy pozniej ktos tez go znajdzie. Najlepiej udostepnic newralgiczny kod zaufanym osobom, ktore przetestuja jego slabe punkty.

Nastepna sprawa jest funkcja printf() oraz sprintf(), ktore sa narazone na tzw blad ciagu formatujacego. Uzywajac tych funkcji w polaczeniu z danymi przeslanymi z zewnatrz moga powodowac bledy w naszych aplikacjach i umozliwic atak na nasza aplikacje.

Podczas tworzenia aplikacji bazujacych na uprawnieniach usytkownikow musimy stosowac zasade najmniejszego przywileju. Nie powinnismy odrazu nadawac uzytkownikowi najwyzszych praw, a zaczac od podstawowych w celu unikniecia dostepu przez niepowolane osoby do waznych danych.

Dane konfiguracyjne powinismy trzymac w zabezpieczonych katalogach albo w plikach, ktore nie dadza sie podejzec.

Zmienne globalne sa kolejnym 'miejscem' narazonym na atak, wiec powinnismy tak konstruowac skrypty aby nie mozna bylo w latwy sposob podmienic danych globalnych (najlepiej wlaczyc register_globals na off).

Polecam jeszcze ten link do skryptow, ktore moga nam sie przydac w zabaezpieczeniu naszych aplikacji: http://www.zend.com/codex.php?CID=246

Niema po co wpadać w oanikę, ale zawsze należy spodziewć się najgorszego . z pośród 100 odwiedzających zawsze znajdzie sie jeden który będzie chciał coś popsuć.

Zwracam tagże uwagę na "zabezpieczenie" sie przed "lamerami" którzy np. rejstrują sie, otrzymyjąc jakieś tam prawa a potem wypisują jakieś przekleństwa albo inne głupoty(chyba nie zboczyłem z tematu).

Na idiotów jest prosty sposób - zrobić bardzo rygorystyczną rejestrację. Ja np. rozdzieliłem serwis na dostępny dla ludzi "zaufanych" i "czekających na zaufanie". Ci pierwsi rejestrowali się z pełną weryfikacją swoich danych personalnych.

Potem nowi ludzie moga się rejestrować automatycznie, ale nie mają dostępu do opcji, w których mogą zrobić coś głupiego. Jeżeli nie nawywijaj nic przez miesiąc, to dostają dodatkowe prawa.

Jeżeli ktoś będzie czekał miesiąc, żeby nawrzucać fucków, to na takiego już nic się nie poradzi.

Dodałbym jeszcze bardzo staranną walidację danych (zarówno client-side jak i później server-side) w celu uniknięcia pułapek typu SQL injection czy Cross site scripting. php samo z siebie pomaga przez magic_qoutes ale sprawdzić nie zawadzi. A co do sprawdzania u klienta i na serwerze to na serwerze trzeba sprawdzać, bo JS można wyłączyć i w ten sposób probować przesłać jakieś sfabrykowane dane, a u klienta też warto sprawdzać, bo to oszczędza czas i nie wymaga przesyłania danych do serwera.

Jezeli chodzi o formularze rejestracyjne to dobe wydaja mi sie metody z ktorejs z sieci komorkowych, numer z przepisaniem z obrazka cyfr etc.

w bezpieczenstwie mozna tez wykozystac mechanizm sesji.

Może powinienem to umieścić w osobnym wątku ale tutaj to też chyba pasuje...
Problem sklepu interentowego:
1. Do jakiego stopnia i w jaki sposób kontrolować userów kożystających z zamówień przez internet
2. Jak przekazywać między stronami wartość loginu (to czy user jest zalogowany) zakładając ze strona działa na zasadzie include i czy przekazywanie przez cookie jest bezpieczne - w końcu to tez da się od biedy podmienić. Czy za każdym wejsciem na stronę sprawdzac przekazany w cookie login (ew. tez hasło) czy jest zgodne z zawartością bazy?
3. W jakiś sposób można kontrolować skąd dane przyłażą (z jakiej strony) i na tej podstawie validować je, ale jak?

1. Sprawdzać poprawność danych i weryfikować email poprzez wysłanie emaila kontrolnego a potem telefonicznie. Im więcej "zabezpieczeń" tym mniejsza przychylność użytkowników.
2. Jest opcja zapisania cookie przez SSL - nie wiem jak to działa w praktyce. Możesz jeszcze z sesji skorzystać, ale nie jestem pewien bo dopiero poznaje mechanizmy sesyjne.
3. Tablice post, get, cookie, server, session - o to chodzi?

//1. Do jakiego stopnia i w jaki sposób kontrolować userów kożystających z zamówień przez internet

Im wiecej informacji o urzytkownikach tym na wiecej mozna im pozwlic, i tym latwiej pozniej znalezc winowajce jakby co... np. pobieranie IP usera, gdy wchodzi na witryne, wysyla formularz i takie tam...

//2. Jak przekazywać między stronami wartość loginu (to czy user jest zalogowany) zakładając ze strona działa na zasadzie include i czy przekazywanie przez cookie jest bezpieczne - w końcu to tez da się od biedy podmienić. Czy za każdym wejsciem na stronę sprawdzac przekazany w cookie login (ew. tez hasło) czy jest zgodne z zawartością bazy?

bron boze nei przechowuj w cookie hasel! login - mozna, ale haslo i login nie! jesli chodzi o hasla i loginy, to dobrze jest uzyc sesji, bo wowczas w cookie na kompie uzytkownika przychowujesz tylko SID, a to nie jest juz az tak grozne...

//3. W jakiś sposób można kontrolować skąd dane przyłażą (z jakiej strony) i na tej podstawie validować je, ale jak?

nie wiem, ale moze chodzi Ci o HTTP_ENV_VARS["HTTP_REFERER"] i
HTTP_ENV_VARS["REDIRECT_URI"] ?

//2.//halfik:
Ja po zalogowaniu wysyłam 3 ciacha:
1. Zakodowane przez md5 i base64_encode hasło
2. Zakodowany przez base64_encode login
3. Zakodowane przez base64_encode ID użytkownika

A później sprawdzam w bazie

Wankster: ale mi nie o to chodzilo. Co Ci da kodowanie jesli ktos dobrzierze sie userowi do cookie: wie z jakiej to strony i ma zakodowane haslo i login, ktore przeciez Twoje skrypty lykna z utesknieniem. Generalnie - uwazam ze nie powinno sie przychowywac nic waznego w cookie.

btw. po zahashowaniu loginu i hasla, zapisujesz je do bazy, ew. do pliku. a pozniej sprawdzasz dane z cookie z danymi zapisanymi w bazie/pliku ?

Ja w sesji ustawiam czy klient jest zalogowany czy nie, bo przecież hasło i login podaje na etapie logowania.
Dopóki sesji nie straci to może sobie łazić gdzie mu sie podoba (w zakresie serwisu).

Tak więc kto jest kto sprawdzam na etapie logowania, a reszte trzyma sesja

:arrow: A jesli user ma wylaczona olusge ciastek to przy tylko takim zalozeniu skrypt nie bedzie dzialac?
:arrow: Po co wysylac przy tego typu weryfikacji ID usera skoro login tak czy inaczej musi byc unikalny?

LeWaR: ale w tym momencie latwo jest dostac sie do serwisu. po drugie, tym sposobem nie zrobisz, aby kazdy user mial swoje konto z mozliwosciami integorawania w niktore czesci strony oraz by kazdy uzytkownik mogl otrzymywac, tracic pewne uprawnienia.

Jeżeli dane mają być przechowywane tylko na czas sesji, to znacznie bezpieczniejszym sposobem jest trzymanie ich w ... sesji. Tam nie będą mogły być przechwycone.
Natomiast jeśli jest konieczne ciastko...
Można zapisać 3 wartości:
a = zahaszowane (numer IP), (na przykład)
b = zakodowany login,
c = zahaszowana (a +

A sprawedzenie tego?
Po pierwsze - test czy a + b ?= c
Po drugie - czy md5($ip) ?= a

Jeśli tak - przechodzimy do wyciagania numeru Ip

podpowiesz jak? przyda mi się

to akurat nie jest mi potrzebne. w moim serwisie nie nadaje żadnych uprawnień. Skrypt ma sprawdzać czy ktoś jest zalogowany i pokazać mu jedne dane, natomiast osobnik nie zalogowany obejrzy sobie inne dane.

Pozdrawiam

Dzięki za odpowiedź

oczywiście ze haseł nie przechowuje się w cookie - tak jakoś walnąłem

1) Jeszcze propos kontroli loginu i hasła.
Jezeli strona jest zrobiona na zasadzie przekazywania zmiennych przez adres i includowania odpowiednich stron z wskazanymi zmiennymi to czy w takim przypadku po zmianie strony (po każdym kliknięciu) kontrolować czy user jest zalogowany i sprawdzać czy login jest w bazie?

2) Czy zachowywać cookie na dłużej niż czas przebywania na stronie?
czy usuwać po rozłączeniu ze stroną i wymuszać logowanie przy każdym odwiedzeniu strony. A moze lepiej logować tylko w momencie składania zamówienia, albo w formularzu zamówienia pytac to login i haslo?

3) czy wykorzytanie sesji rozwiązuje problem wyłączonych cookie u uzytownika?

4) "nie wiem, ale moze chodzi Ci o HTTP_ENV_VARS["HTTP_REFERER"] i
HTTP_ENV_VARS["REDIRECT_URI"] ?"

czy takim czymś można sprawdzić czy formularz został wysłany z mojej stronki czy czasem ktoś sobie nie zrobił własnego i tylko action=http//bla.bla/index.php nie ustawił?

ad 1. wg. mnie tak, jesli chesz odrobine zwiekszyc bezpieczenstwo serwisu, ale mozesz tez np. jak niektorzy - raz sprawdzaja a pozniej zapisuja w zmiennej sesyjne 1 zeminna ktora okresla ze user jest zalogowany.

ad 2. ja proponuje ten 1 system, jak wiemy dziala on na wielu serwisach i jakos nikt nie nazeka, a te drugi coz- bylby nawet troszke nowatorski

ad 3. no i to jest ten bol

ad 4. przy pomocy zmiennych srodowiskowych mozna sprawdzic skad pochodzi zapytanie o strone i woczas na nie odpowiedziec - jesli to nasz skrypt - lub nie.

Jak to? Nie wiem czy dobrze zrozumiałem książkę, ale jeżeli php nie może zapisać cookie to przekazuje ID sesji w linkach. Więc odpada problem z wyłączonymi cookie.

spenalzo: php jak tako samo nie ustawia SID przy linkach, no chyba ze masz tak skonfigurowane, bo chyba sie tak da. ja np. mailem takie konto ze sam musialem dodawac SID do linkow i szczerze mowiac toszke to uciazliwe, ale z drugiej strony mozemy gwizdac na to jak user ma skonfigurowana lub nie, przegladarke

Gdzieś się pojawił pomysł z sprawdzaniem IP - a co jak ktoś ma dynamiczne??

Przechowywanie samego loginu w cookie jest wygodne, acz również niebezpieczne. Natomiast przecchowywanie hasla i id jest raczej zbytkiem - w koncu jezeli ktos sie juz dobierze do cookie to i tak powyciąga z nigo co mu trzeba. Hashowanie tez jest dobrym pomyslem, ale nadal pozostaje problem przechowywania tych danych i przekazywania ich między userami.

halfik: dlaczego TYM sposobem nie zrobisz żeby user mógł ingerować w stronę? przeciez na czas przechowywania sid ma prawa dostepu do strony.

Stały login (pozostawiany po rozłączeniu ze stroną) jest często bardzo przydatny. Moze być uciązliwe jezeli user musi korzystać ze strony co jakiś czas i za każdym razem się logować.

na pewnym forum jest zachowywany login i jakoś to działa.
poza tym czy próby przełamania zabezpieczen są az tak częste?

Sam login bez hasla niewiele daje.

Dopoki nie trafi na Ciebie bedziesz myslal, ze nie.
Pozatym lepiej dmuchac na zimne w tych sprawach.

Pianandrill: "TYM sposobem..." pisz prosze bez polslowek, bo ja nie znam watku na pamiec i nie pamietam co napisalem wczesniej, a na modemie nie bardzo mam czas zeby zalookac...

a IP to tez dobra rzecz, zwlaszcza w polaczeniu z cookie

Myslalem nad przechowywaniem id w cookie i sprawdzaniu przy każdym wejsciu czy dany id wystepuje w bazie - jezeli tak to ok, bo mozna zalozyc ze odwiedzajacym jest ten kto posiada aktualny login - jezeli to nie on to oznacza ze nie dopilnowal przejecia danych.
login!=id - takie jest zalozenie oczywiscie
Zaklada to także ze na kazdej stronie trzeba przeprowadzic sprawdzenie.
Ale można to ominąć poprzez pozostawienie na czas połączenia ze stroną cookie zawierające zmienną 1 lub 0, której wartość jest nadawana przy kontroli loginu. Jezli juz byl sprawdzany to jest 1 inaczej 0 - wyklucza to koniecznosc łączenia się za każdym przeładowaniem strony z bazą w poszukiwaniu loginu.

Co o tym sądziecie i czy macie jakieś zastrzeżenia do tego?

co do literatury to prosze bardzo : ftp://ftp.helion.pl/online/phpbb/phpbb-9.pdf, dzieki uprzejmosci helion caly darmowy rozdzial poswiecony tylko i wylacznie formularzom w php, choc nie ma tam wszystkiego to jest sporo, polecam

Jesli uzywamy ip do kontroli podczas uzywania serwisu to zdaje mi sie ze nic nie stoi na przeszkodzie aby wykozystac rwoniez dynamiczne ip poniewaz jest ono unikalne dla danej sesji i podczas trwania sesi nie zmienia sie, oczywiscie jako wartosc wysciowa ip bowinna byc wzieta wartosc ip podczas logowania a nie podczas rejstracji. Takie moje skormne zdanie

Niektórzy uważają że najprostsze metody są najlepsze... Podstawowa sprawa to pożądna kontrola wprowadzany danych, dalej strip_tags() lub HTMLSpecialChars().

Najefektywniejsza metoda to sprawdzanie zgłoszeń wysłanych na mail, ale to też najbardziej czasochłonna metoda...

hmm... ale dlaczego chcesz przechowywac jakis id w cookie? przeciez uznawanie ze uzytkownik X jest zalogowany jedynie na podstawie id jest co najmniej bezcelowe. a co jak taki uzytkownik wezmie i przestawi sobie to id, dajmy na to z 1 zrobi sobie 4 - bo nei wiem czy dobrze rozumuje Twoj pomysl - czy system potraktuje go jako innego usera ?


wg. mnie wszelkie dane na czas polaczenia naly trzymac w sesji, a jesli chcemy aby uzytkownik nie musial sie logowac za kazym wejscie na strone: wystarczy zapisac mu w cookie id sesji, nie niszczyc danych sesyjnych, a przy ponownym wejsci sprawdzac, czy istotnie w cookie jest SID - jesl itak to odczytujemy dane sesyjne.

Co do sesji trzeba uważac na multi hosting -- ponieważ sesje są skłądowane w jednym miejscu i można je podglądnać. Tu może dać rade rozmowa zadministratorem aby ustalał każdej stronie inny tmp do sesji lub własny system sesji oparty o baze danych. taki jak jest opisany w artykułach na php.pl i innych stronach a nawet w podręczniku php

I twój problem jest rozwiązany ;]

Możesz też przechowywać sesje w bazie danych (sql bądź tekstowej).

Pozdrawiam.

proboje wlasnie zabezpieczyc formularz przed dodaniem wpisu z innej strony, ale cos mi nie dziala ten referer :/

czy moge uzyc funkcji sprawdzenia referera w przypadku gdy dane nadchodza poprzez POST?

Po prostu należy filtrować wszystkie zmienne $_POST i $_GET i 'no problem':

[PHP] pobierz, plaintext 
<?php
 
foreach($_GET as $a => $b)
	 $_GET[$a] = htmlspecialchars($b);
 
?>
[PHP] pobierz, plaintext 

podobnie z $_POST:

[PHP] pobierz, plaintext 
<?php
 
foreach($_POST as $a => $b)
	 $_POST[$a] = htmlspecialchars($b);
 
?>
[PHP] pobierz, plaintext 

.

mam dwa pytanka
1) na zajeciach facet nam powiedzial ze trzymanie hasla w sesji jest niebezpieczne niestety nie powiedzial dlaczego, moze wy cos wiecie na ten temat ?

2) mowil tez ze jezeli w osobnym pliku ktory jest potem dolaczany mamy zmienne globalne w ktorych znajduje sie nazwa hosta, user i haslo potrzebne do polaczenia sie z baza to nalezy go trzymac w innym miejscu gdzie znajduja sie pliki ze strona(?) czy jakos tak, niezbyt zajazylem o co mu chodzilo

1. Nie zakodowane napewno jest niebezpiecznie trzymać Mnie jakoś wpadło w naług dawanie md5(sha1(haslo/sid/etc.));
2. Jeżeli dobrze zrozumiałem, to pewnie chodziło mu o tworzenie plików trzymających tylko dane do łączenia się z bazą danych.

@snaiper: Taki scenariusz: Ktoś włamał się na serwer, twoja strona jest dobrze zabezpieczona. "Haker" nie ma dostępu do twoich baz MySQL a także nie może podglądać plików .php
Jednak prawa pozwalają mu na odczyt danych z katalogu /tmp
Tworzy odpowiedni skrypt, dzięki czemu jako użytkownik "Apache" ma prawo odczytać każdy plik sesji z katalogu /tmp. Teraz bez problemu zdobędzie twoje niezakodowane hasło.

Ja raz, tak zdobyłem admina na pewnej stronie. Hasła tam nie było, ale był znacznik wskazujący na poziom uprawnień. Nic nie mogłem zrobić z plikami i sql, ale zedytowałem plik swojej sesji przyznając sobie prawa admina.

Sesje powinny byc przechowywane w bazie danych, a jesli nawet sa zapisywane w plikach, to katalog w ktorym sa przechowywane powinien byc stosownie zabezpieczony przy pomocy .htaccess. W ciasteczkach - jesli juz zachodzi koniecznosc ich uzycia np. w celu umozliwienia autologowania moznaby przechowywac zahaszowana kombinacje identyfikatora sesji i IP. Jesli uzytkownik ma dynamiczne to albo rezygnujemy ze sprawdzania IP i obnizamy poziom zabezpieczen, albo niestety wymuszamy koniecznosc logowania za kazdym razem. Tak czy inaczej jest to sposob traktowania IP opisany wczesniej przez squida.

Osobiście uważam za bezcelowe przehowywanie w ciachu loginu, id uzytkownika, a juz tym bardziej hasla.

numer IP to zły przykład... tak samo jak przegladarka... i inne dane które mogą być 'zmienne' tylko dlatego ze istnieje cos takiego jak serwery proxy.

[PHP] pobierz, plaintext 
<?php
 
#Podajesz nazwe adres twojej www
$domena = &#092;"http://twojastrona.pl/\";
 
$http_referer= (!empty($_SERVER['HTTP_REFERER'])) ? $_SERVER['HTTP_REFERER'] : $domena;
 
if (!preg_match(&#092;"#\".$domena.\"#si\", $http_referer)) { echo \"Próba włamania\"; } 
else { echo&#092;"Wszystko OK\"; }
 
?>
[PHP] pobierz, plaintext