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.