Blog programistów Programa.pl

Bezpieczne programowanie w PHP

W ramach zajęć z przedmiotu „Bezpieczeństwo w Systemach Komputerowych” tworzymy pewne materiały, oczywiście dotyczące bezpieczeństwa. Postanowiliśmy podzielić się tym z szerszym gronem niż tylko z kolegami z roku.

Zaczniemy od kilku tricków dotyczących PHP. Pokażemy jak wykonać pewne ataki i, co ważniejsze, jak się przed tymi atakami bronić. Będzie też kilka zasad historycznych, żeby pokazać, że język ewoluuje i sam zapewnia coraz większą ochronę.

Na początek zasada numer jeden – jedna, niepowtarzalna. Banalnie prosta, ale ekstremalnie ważna: użytkownik jest zły. Jeśli tylko będzie miał możliwość coś popsuć, to na pewno popsuje. Jeśli chcesz, żeby w dane pole wpisał liczbę, na pewno wpisze znaki specjalne.
Tak, to już jest atak. Jeśli nie zadbaliśmy o filtrowanie danych, to nasz portal jest potencjalnym celem ataków, gdyż większość ataków korzysta właśnie z tej luki.

Sprawa numer dwa: rozszerzenia plików. Jeśli tworzysz plik z kodem PHP, zawsze zapisuj go z rozszerzeniem „.php”. Jeśli zapiszesz go z innym rozszerzeniem (popularne jest „.inc”), to użytkownik wyświetli go jak zwykły plik tekstowy. Odczyta Twoje hasła. Skompromituje serwer. I po zabawie.

Sprawa numer trzy: dyrektywa register_globals. Jeśli masz możliwość – wyłącz. I to czym prędzej. Ona po prostu jest niebezpieczna! wystarczy wprawny cracker i wszelkie algorytmy bezpieczeństwa zostają skompromitowane.

Numer cztery: ataki typu Injection. Wstrzyknięcie obcego kodu w nasz kod. Sprawa bardzo niebezpieczna. Zabezpieczenie – filtrowanie danych. Do ataków tego typu należą SQL Inecjtion, Code Injection oraz Shell Injection.

Numer pięć: XSS i CSRF – umieszczenie na naszej witrynie szkodliwej zawartości. Ataki często mylone z sobą, ale pozwalające na nieco inne wykorzystanie luk.

Numer sześć: Session Fixation. Nie masz uprawnień? Możesz je sobie ukraść. I to w dość prosty sposób, korzystając z luk w portalu i łatwowierności ludzi. Jeden z ataków, przed którym można się obronić niewielkim nakładem pracy, ale jego pominięcie podczas ustalania polityki bezpieczeństwa portalu może skończyć się tragicznie.

Wreszcie numer siedem: HTTP Response splitting. Atak o znaczeniu historycznym. Jego wykonanie uniemożliwia w tej chwili sam język. W starych wersjach potrafił napsuć sporo krwii.

Tyle tytułem wstępu. O każdym z ataków i sposobach obrony postaram się napisać więcej. Mam przygotowane już pewne przykłady ataków, muszę tylko przygotować poligon. Jeśli ktoś jest niecierpliwy, to może na temat ataków poczytać m.in. w czasopiśmie Hackin9. Dwa numery w wersji pdf są do pobrania z naszej strony.

Udostępnij innym

Walidacja HTML i XHTML – to podstawa!

Przemierzając witryny www często widzimy tylko jedno oblicze – ta strona w naszej ukochanej przeglądarce wygląda wspaniale! Albo odwrotnie – strona się „rozjeżdża”, nie wygląda zupełnie tak, jak powinna. W czym rzecz? Przecież HTML powinien zawsze być publikowany tak samo!

Poprawność

HTML i XHTML są językami tagów. Oznacza to, że cała treść umieszczona jest w specjalnym drzewie znaczników. Dlaczego więc większość developerów zapomina o tym, że te tagi często trzeba zamykać? Jeśli piszemy program w języku kompilowanym, to kompilator wskaże nam nasze błędy. Tutaj do kompilacji nie dochodzi. Kiedy kod strony jest poprawny, każda przeglądarka powinna wyświetlić ją tak samo (są pewne różnice, ale nie mamy na nie wpływu). Jednak kiedy strona www jest niepoprawnym dokumentem przeglądarka przechodzi z trybu strict (zgodność ze standardami) w tryb quirks. W tym trybie przeglądarka próbuje „domyślić się” co mieliśmy na myśli, tworząc dokument. Często jej się udaje. Ale nie zawsze.

Parser HTML/XHTML?

Jak sprawdzić, czy nasza strona jest zgodna ze standardami? Najłatwiej skorzystać z usług The World Wide Web Consortium (W3C). Na ich stronie www możemy przeczytać sporo o standardach, a także znaleźć adresy narzędzi zwanych walidatorami. Te narzędzia właśnie pozwalają na sprawdzenie, gdzie w naszym dokumencie HTML są błędy.

Czy warto?

Oczywiście, że tak! Uważam, że walidacja dokumentów to absolutne minimum! Nie wyobrażam sobie, jak ktoś, kto mówi o sobie „profesjonalista”, może oddawać ludziom stronę www, która nie jest poprawnie zbudowana! Jeśli ktoś się uczy, zawsze może poprosić o pomoc w poprawieniu błędów, przeczytać opisy standardów itd.

A co z XMLem?

Używając języka XML nie mamy wyjścia – jeśli dokument nie jest poprawnie sformatowany, to przeglądarka nie wyświetli go wcale! Tylko dokumenty poprawne, tzn. well-formed są wyświetlane. I tylko takie użytkownik zobaczy. Więc może używanie XMLa jest rozwiązaniem? Możliwe. Ale to już chyba materiał na kolejny wpis i długą dyskusję.

Walidacja stron www oraz ich arkuszów stylów jest pierwszą rzeczą, jaką sprawdzam oceniając stronę www. Jeśli strona ma niewiele błędów, to można uznać je za przypadek, efekt niedawnych zmian czy świadczyć o pracy nad stroną. Oczywiście najlepiej, gdy waldiator odpowie, że strona jest zgodna ze standardami. Jeśli jednak walidator zrezygnuje ze sprawdzania poprawności po setnym błędzie, moja ocena strony drastycznie spada. Jeśli coś robisz  – rób to dobrze.

Udostępnij innym