Zabezpieczenie formularzy Opcje

[itsme]

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.

[dragossani]

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.

[Seth]

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

[mazy]

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).

[freyman]

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.

[puklos]

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.

[halfik]

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.

[Pianandrill]

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?

[spenalzo]

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?

[halfik]

//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"] ?

[Wankster]

//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

[halfik]

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 ?

[LeWaR]

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

[kwiateek]

//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

: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?

[halfik]

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.

[DeyV]

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

[LeWaR]

ale w tym momencie latwo jest dostac sie do serwisu.

podpowiesz jak? przyda mi się

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.

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

[Pianandrill]

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ł?

[halfik]

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.

[spenalzo]

ad 3. no i to jest ten bol

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.