Bezpieczeństwo skryptów z punktu widzenia programisty

Pisanie własnego kodu daje dużo satysfakcji, jednakże wiąże sie z pewnym ryzykiem, że ktoś znajdzie lukę w naszym kodzie i umiejętnie ją wykorzysta do kradzieży lub manipulacji danych, przejęcia konta, itp. Bardzo ważnym elementem przy pisaniu aplikacji jest walidacja wpisywanych/pobieranych danych. W pierwszym przypadku (wpisywanie danych) zazwyczaj oczekujemy określonego typu danych np. wartości liczbowej czy tekstu pozbawionego tagów html ( warto przemyśleć zastosowanie funkcji: string htmlspecialchars ( string $string [, int $quote_style [, string $charset [, bool $double_encode ]]] ) ), również w prosty sposób możemy sprawdzić czy wprowadzona wartość jest liczbą, przydatna możne być funkcja: bool is_numeric ( mixed $var ) oraz podobne( is_float(), is_int() ). Stosowanie takich zabezpieczeń minimalizuje ryzyko ataków typu XSS czy CSRF. Warto jeszcze dodać, że walidację formularzy powinno wykonywać sie dwukrotnie - za pierwszym razem po stronie klienta oraz za drugim razem na serwerze na wypadek gdyby podstępny użytkownik "majstrował" przy formularzu.

Kolejnym bardzo ważnym aspektem zabezpieczania skryptów jest ścieżka dostępu do pliku( zasobu). Szczególnie jest to poważny problem w przypadku tworzenia skryptu do przeglądania zawartości katalogu, należy bardzo uważać na odwołania typu: ../, ../../ itd. Oto przykład nie w pełni zabezpieczonego skryptu: Thepeak File Upload v1.3 . Można w prosty sposób wydobyć dowolny plik na serwerze( trzeba tylko oczywiście znać pełną ścieżkę dostępu do tego pliku).
Dobrym rozwiązaniem jest tutaj funkcja: string basename ( string $path [, string $suffix ] ).

W przypadku skryptów uploadujących pliki na serwer należy pamiętać o sprawdzeniu typów wgrywanych plików, dla przykładu nie powinno sie zezwalać na pliki typu: "application/x-httpd-php", "application/octet-stream" lub podobnych, ze względu na to, że mogą zostać wykonane na serwerze.

Wstrzykiwanie( injection) zainfekowanego kodu to temat bardzo rozległy i szczególnie niebezpieczny w przypadku tzw. SqlInjection. Po ataku na stronę Szkoły Hakerów, mamy nawet możliwość zrobienia tego legalnie: hackme.pdf. Ponieważ każde odwołanie sie do bazy sql wymaga napisania osobnego kodu, czasami bardzo łatwo popełnić błąd w postaci luki w systemie bezpieczeństwa, dotyczy do przede wszystkim początkujących programistów, ale jak widać na przykładzie Szkoły Hakerów, nie tylko. Szczególnie, że na stronie szkoły znalazłem również miejsce podatne na ataki XSS.

Należy również unikać wykonywania kodu podawanego w postaci jawnego tekstu(sringa), mam tu na myśli funkcję: mixed eval ( string $code_str ).

Na koniec uwaga dotycząca składowania danych: ważne dane(loginy, hasła, itp.) na serwerze powinno być przechowywane w bezpieczny sposób, w miejscach do których przeciętny użytkownik nie ma dostępu, najlepiej w postaci shaszowanej(md5, itp.).