Bardzo dobry tekst dla początkujących. Pozdrawiam!

Ja zalecam 3 proste triki:

1. Po autoryzacji użytkownika wygenerować nowe ID sesji:

session_regenerate_id ()

2. Ciastka sesji tylko poprzez skrypt PHP przez JS nie będzie dostępu do nich.

ini_set("session.cookie_httponly", 1);

3. Jak komuś się nie chce filtrować każdej zmiennej z osoba to może:

$_GET = array_map('mysql_escape_string',$_GET);

$_POST = array_map('mysql_escape_string',$_POST);

można tajże dodać dodatkowo mysql_escape* na strip_tags i będzie kala

Ja dodatkowo daje nagłówki do Http
X-XSS-Protection 1; mode=block
oraz po zalogowaniu dodaje do SESSION adres IP jak jest inny to usuwa sesje oraz ciastko

Sam kiedyś korzystałem z PHP, ale teraz z perspektywy czasu odradzam pisanie "na czysto", w PHP na szybko strukturalnie można coś wymodzić, ale ten język nie jest zbyt czytelny, znaki dolara przy zmiennych trochę zniechęcają do używania. Jak się nie robi na czysto itp., to jeszcze znośne jest używanie PHP+framework, jak np. Kohana.

Ostatnio sukcesywnie używam Google App Engine z poziomu Python'a i nie mam problemów z bezpieczeństwem. Wielkim webmasterem może nie jestem, bo używam technologii webowych tylko na własne potrzeby (wolę programowanie aplikacji), ale swojego czasu nieco stron napisałem ;)

@The, jak pisałem, trików jest wiele. Jednak odradzał bym filtrowanie GET/POST na wejściu. Jeżeli inny programista będzie pracował z Twoim kodem to będzie miał problemy. Przykładowo wyrzuci dump z ciągiem znaków. Znaki ucieczki nie będą wyświetlone a jednak ciąg znaków np nie będzie równy innemu. W przeglądarce tego nie zobaczy ale "pod spodem" już będziesz porównywał ciąg zwykły z tym który ma znaki ucieczki.

strip_tags ma jedną zasadniczą wadę. W rzeczywistości nie usuwa tagów HTML lecz WSZYSTKO co jest w dzióbkach. Przez to może Ci nagle zniknąć cały znak tekstu bo ktoś gdzieś wsadził znak mniejszości a dalej większości.

Co do adresu IP to jest o tym w tekście. Inne dane też można zanotować (te które pozostają stałe). Zapamiętanie samego IP nie chroni np przed przechwyceniem sesji przez kogoś w sieci lokalnej.

@AnonimAnus, PHP bardzo dojrzał przez ostatnie lata. OOP pełną gębą można stosować w wersji 5+. Sam PHP ma też kilka bardzo fajnych feature (zdolność badania swojego własnego kodu (reflections) dla przykładu przez aplikację czy samoczynne poszerzanie swoich możliwości - wyobraź sobie że na koncie mam aplikację która generowała samą siebie). Nie jest to może najszybszy język ale aplikacje w nim napisane są niesamowicie skalowalne i bardzo łatwo się je później profiluje, debuguje i łata.
No i nie znam języka w którym szybko by się pisało "na czysto". Od tego są biblioteki i frameworki by z nich korzystać. Sam mam własny framework i szkielet aplikacji "od wszystkiego".

Najciekawsza rzecz jaką pisałem ? W momencie jak użytkownik odwoływał się do jakiejś bazy danych poprzez obiekt skrypt powodował błąd gdy ten obiekt nie istniał. Wtedy potrafił sobie wygenerować plik z klasą do obsługi bazy danych (mapper) poprzez zbadanie tabeli w bazie danych do której się chciałeś odwołać (nazwa mappera była zależna od nazwy tabeli wg pewnych reguł a z kolei nazwa klasy wskazywała że chodzi o mapper). Następnie wyniki swojej pracy zapisywał do pliku, kontrolował czy kod jest poprawny (tak, jest taka możliwość w PHP), ładował plik z klasą wykonywał określone czynności.

W momencie gdy poszerzam aplikację o nowe rozszerzenia, skrypt w momencie różnych błędów ma listę procedur które wykona by sobie z nimi poradzić. W wielu przypadkach nawet nie zawracam sobie głowy pisaniem czegoś (jak mapperów, chyba że potrzebne mi są jakieś skomplikowane) bo na podstawie źródła danych takich jak właśnie baza mysql skrypt potrafi sam się uzupełnić. Wiadomo że potrwa to dłużej ale jest to jednorazowa operacja, obecnie piszę sobie skrypt który podobne działanie będzie miał dla plików CSV oraz XML).

Nie wiem co autor mial na mysli... Co ma wspolnego bezpieczenstwo PHP, z atakami XSS, SQL injection, filtrowania danych wysylanych z formularza.
W innych jezykach tak samo trzeba filtrowac wszelkie dane.

Tekst jest dobry dla poczatkujacych tylko temat bym zmienil i usunal skrot "PHP"

@Przemo, może tytuł to za duży skrót myślowy. Ogólnie chodziło o zachowanie odpowiedniego poziomu bezpieczeństwa skryptów PHP.
A dlaczego PHP ? Ponieważ zajmuję się nim zawodowo a chciałem tekst napisać w oparciu o jakieś w miarę realne przykłady (mój pierwszy tekst tutaj). I tak na ten język padło.

Większość tych zasad ma zastosowanie niemal w każdym języku. Nie mniej jednak obserwuje po sytuacji na rynku pracy że jest ogromna ilość programistów którzy wychodzą prosto po studiach i myślą że nadają się do pracy. Ten tekst możesz potraktować jako małą przestrogę dla tych osób (chodzi mi o takich którzy wyszli tylko z wiedzą z uczelni).
Dla Ciebie to są podstawy podstaw gdzie dla nich może to być prawda oświecona (i często jest). I dla takich ludzi ten tekst jest.

To jest tylko poradnik jak się bronić przed takimi ataki dla początkujących. Bo jak wiadomo nieświadomi programiści mogą skleijać SQL ze zmeinnymi i takie są tego efekty. Dobre zwytczaje zostają więc jak się już od początku nauczy programiste że ma zwracać na pewne rzeczy uwagę to tylko świat będzie od tego lepszy :) .

Jak dla mnie, czyli początkującego programisty php ten tekst jest świetny. Wiem już na co zwracać uwagę nawet przy prostych skryptach formularzy. Ta wiedza mi się znacząco przyda i dziękuję ogromnie autorowi za ten tekst. Swoją drogą temat bezpieczeństwa trzeba zgłębić bardziej się okazuje, bo jest on obszerny.

Jeszcze raz dzięki wielkie.

Jak się pisze w czystym php bez użycia frameworków - owszem trzeba się martwić o takie szczegóły. Jednak gdy masz już jakieś gotowe forum (PHPBB, SMF itp.) to one już wykorzystują te funkcje i mają w miarę dobre zabezpieczenia. Jak korzystasz z funkcji udostępnianych przez frameworki (np. w Python'ie Django itp.), to możesz tworzyć formularze, wykonywać zapytania itp. zgodnie z frameworkiem i wtedy to jest bezpieczne ;) Ale jak piszesz na czysto w PHP to musisz znać te funkcje do zabezpieczania.

@AnonimAnus rozmawiamy tutaj o programowaniu w php, a nie o używaniu framework-ów, jeśli się chce być dobrym programistą to nie zaczyna się od dupy strony, nigdy nie zagrasz z orkiestrą symfoniczną jeśli nie bedziesz znał nut :)

@AnonimAnus, po pierwsze ktoś takowego frameworka musi napisać. Po drugie frameworki nie mają wszystkiego. Zawsze będziesz coś musiał napisać od podstaw, dodać nowe biblioteki do już istniejących itp.
Co w tedy ? Oddawanie się w ręce magii gotowych rozwiązań to rzecz wygodna do czasu gdy sami tej magii nie musimy tworzyć. A jak już się za tworzenie magii bierzemy to tego typu i inne podstawy wracają.

@AnonimAnus bardzo się cieszę że programujesz w Python'ie. Ale zaraz zaczniesz tutaj świętą wojnę języków programowania.
Jakość i bezpieczeństwo aplikacji nie zależy od języka(framework-a) ale od umiejętności programisty który ją pisze.
W każdym języku i w każdym frameworku da się "skopać" program.

To ja tylko nieco dodam od siebie. Też jestem webmasterem i dodam, że komunikat, że strona jest niebezpieczna nie musi wynikać z faktu, że komuś cokolwiek zrobiła. Zdarzyło mi się to bowiem już, że google założyło mi ten komunikat prewencyjnie. Powodem był jeden ze skryptów dołączanych, który miał pewną lukę bezpieczeństwa. Mimo faktu takiego, że nie można jej było użyć do ataku na bazę serwisu, to wykrycie go w kodzie przez robota indeksującego skończyło się komplikacjami. Musiałem kod usunąć i zgłosić sprawdzenie ponowne do google by zdjęli blokadę.

A wracając do gotowych frameworków i rozwiązań... Myślisz, że używając ich masz gwarancję bezpieczeństwa? Sam musiałem komercyjne skrypty poprawiać nieraz, bo były zbugowane. Nie będę rzucał nazwami firm, ale niektóre pisząc soft webowy o problemie ataków wiedzą tyle co kot napłakał. Ktoś tutaj rzucił mysql_escape_string zamiast mysql_real_escape_string. Fajnie, ale jeśli strona nie ma połączenia z bazą to funkcji nie można użyć, bo używa ona kodowania bazy a inne funkcje są zawodne o wiele bardziej. Żadne addslashes, htmlspecialchars czy htmlentities nie dadzą takiego bezpieczeństwa.

Zresztą bezpieczeństwo skryptów to temat rzeka na kilka książek :)

Witaj,
studiujesz może na PRz?

Tak