Blog programistów Programa.pl

Hackfest Poznań 2011

1 października 2011 roku. Godzina 19.00.  26 godzin temu rozpoczął się wyścig z czasem. Około 30 zespołów ma tylko 48 godzin, aby wykazać się nieprzeciętnymi umiejętnościami  w zakresie tworzenia aplikacji. Ich dzieła konkurują o tytuł najlepszej aplikacji w dwóch kategoriach: e-commerce oraz mobile. Czy mogło nas tam zabraknąć? Oczywiście, że nie! Na Hackfest wystawiliśmy dwa zespoły, po jednym dla każdej kategorii.

Przeczytaj Całość »

Udostępnij innym

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

FirePHP – dodatek do Firefoxa dla developerów PHP

Dość znanym sposobem debugowania aplikacji jest sposób „na echo”. Nie jestem w stanie policzyć ile razy już w taki sposób szukałem dziury w moich stronach www. Tworzenie własnych klas logujących działanie strony jest czasochłonne i nikt tego nie robi. I dobrze – od tego jest FirePHP.

Co muszę mieć

Ponieważ FirePHP jest nieodłączną częścią Firebuga, musimy posiadać tę wtyczkę do Firefoxa. Oprócz tego potrzebna nam biblioteka pobrana ze strony projektu. Jest to malutka paczuszka zawierająca klasę  odpowiedzialną za logowanie informacji.

Ale jak to działa?

Działa to następująco: dołączamy przez require bibliotekę i od tego momentu możemy korzystać z metod FirePHP. Można o nich poczytać o stronach projektu, ale wymienię tutaj, moim zdaniem, najważniejsze.

$firephp->log('Czysty tekst'); 
$firephp->info('Informacja');      
$firephp->warn('Ostrzeżenie');      
$firephp->error('Błąd');
$firephp->dump('Klucz', $zmienna);

Pierwsze cztery służą do przekazywania komunikatów, czwarta do przekazywania wartości zmiennych. Ale przekazywana gdzie – chciałoby się zapytać. Otóż wszystko, co przekażemy do FirePHP zostanie umieszczone w panelu Konsoli Firebuga, dzięki czemu mamy do nich dostęp kiedy tylko tego potrzebujemy, a użytkownik, który nie posiada FirePHP nie widzi nic poza właściwą stroną. A jeśli ma FirePHP? Możemy zawsze wyłączyć logowanie komunikatów dla nieuprawnionych userów za pomocą metody

$firephp->setEnabled(false);

Afiliacja?

Dlaczego Firefox jest najlepszy? Bo ma Firebuga i FirePHP. Jak przeczytałem na jednej ze stron dotyczących FirePHP – jeśli by nie istniał, to trzeba by go było wymyślić. Zgadzam się z tym w 100%. FirePHP jest niezastąpiony podczas śledzenia wywołań AJAX, których debugowanie zawsze powodowało problemy. A teraz jest to łatwe i przyjemne.

Udostępnij innym