Zeev Suraski – izraelski programista PHP, współzałożyciel Zend Technologies. Z pomocą Andiego Gutmans’a w 1997 napisał PHP3, po czym dwa lata później stworzył Zend Engine.

Derick Rethans – twórca mcrypt, input_filter, dbus i rozszerzeń typu date/time w PHP. Znany również z opieki nad projektem PHP’owego profilera Xdebug oraz z kilkuletniego zaangażowania w Apache Zeta Components.

Jouzas Kaziukenas – założyciel i prezes firmy Web Species Ltd, mówca na konferencjach dotyczących technologii informatycznych, blogger.

Joshua Thijssen - starszy inżynier oprogramowania w Enrise/4Worx oraz właściciel prywatnej firmy NoxLogic.

Pomimo tego, iż byłem w stanie uczestniczyć tylko na przemówieniach w języku angielskim, muszę przyznać, że poruszono w nich kilka ciekawych tematów takich jak:

- 15 porad dla użytkowników MySQL
-  Struktury danych SPL i ich złożoność
- Jak władać przestrzeniami nazw w PHP
- Nowa era frameworków w PHP
- Rozszerzenia w PHP, z czym i dlaczego ?

Oceniając je poprzez pryzmat programisty PHP, trzy pierwsze uważam za naprawdę wartościowe i godne uwagi.

Według mnie najciekawsze przemówienie wygłosił Joshua Thijssen, specjalista MySQL, który w zwięzły sposób pokazał kilkanaście sztuczek mogących znacznie przyspieszyć operacje na bazie danych. Uważam, że przejrzenie slajdów z jego przemowy na pewno nauczy Was czegoś nowego. Pamiętajcie by nie ufać varchar’om! :)

Kolejnym, wybitnym przemówieniem popisał się Jurriën Stutterheim, który po krótkiej dygresji na temat złożoności algorytmów przeszedł do ciekawszej części poświęconej strukturom danych w PHP. Było naprawdę miło słuchać wykładu w którym dowodził, że prócz typowych tablic, PHP oferuje tak zaawansowane struktury jak: SplDoublyLinkedList, SplStack, SplQueue, SplHeap, SplMaxHeap, SplMinHeap, SplPriorityQueue, SplFixedArray i SplObjectStorage. Szczerze zachęcam do obejrzenia jego prezentacji.

Chciałbym też wspomnieć o wystąpieniu Nicka Belhomme, który postanowił opowiedzieć o nowej funkcjonalności wprowadzonej do PHP dopiero w wersji 5.3. Jego tematem były oczywiście przestrzenie nazw (ang. namespaces), czyli abstrakcyjne kontenery stworzone do trzymania logicznie pogrupowanych unikatowych identyfikatorów. Jego prezentacja była szczególnie edukacyjna i istotna dla przyszłych projektów w PHP, obfitując przy tym dodatkowo w kilkanaście przykładów z kodami źródłowymi.

Na sam koniec chciałbym przytoczyć wypowiedź Jouzasa Kaziukenas’a. Starał się on ukazać zmiany jakie zaszły w świecie frameworków PHP’owych w przeciągu ostatnich sześciu lat. Muszę przyznać, że zrobił to wyjątkowo dobrze. Wymieniwszy kilka frameworków, w tym Symfony2, Zend Framework, Lithium, Alloy, Fuel, Fat-free oraz Flow3, jego uwagę na dłużej przykuło Symfony2. Przede wszystkim za sprawą innowacyjnych rozwiązań o których rozprawiał, takich jak: bundles, dependency injection oraz community driven development (GIT). Nie bez znaczenia okazały się również symfonowe interoperacyjność, szybkość i doskonała dokumentacja. Jouzas ponadto bardzo oczekiwał nowej, stabilnej wersji frameworka ZF2, którego premiery nie potrafił niestety określić. Jeśli w tym czasie chcielibyśmy czegoś z innej beczki, do wypróbowania zostają microframeworki. Pomimo tego, iż stworzone głównie dla małych projektów, z pewnością będą interesującą i godną uwagi alternatywą. Dla zainteresowanych, przytoczonym microframeworkiem został Silex.

Podsumowując konferencję PFCongres muszę przyznać, że uczestnictwo w niej było dla mnie bardzo cennym doświadczeniem. Miałem bowiem okazję poznać wiele ciekawostek i wodotrysków jak również zaznajomić się z nowinkami i przyszłymi trendami języka PHP. Miałem też okazję na własne oczy zobaczyć Tych, którzy wkładają ogromny wysiłek w jego rozwój. Co więcej, bardzo zmotywowało mnie ich entuzjastyczne podejście do dalszego rozwoju i udoskonalania owego języka. Liczę, że i w przyszłym roku zdołam stawić się na PFCongres, a jeśli i Ty czujesz się podobnie „wkręcony” w PHP, to serdecznie polecam i zapraszam Cie na to wydarzenie!

Na rynku istnieje mnóstwo rozwiązań Open Source, rozwiązujące różne klasy zagadnień. Mowa tu o produktach e-commerce (Magento, Presta Shop), CMS (Drupal, Joomla, WordPress), systemach klasy CRM, ERP, czy DMS, a także „community builders”, czyli np. fora internetowe (PHP BB). W zdecydowanej większości powyższych przypadków nie potrzeba wiedzy programistycznej aby wdrożyć i rozwijać serwisy. Mają one obszerne zbiory rozszerzeń i wtyczek (plugins), które pozwalają dostosowywać systemy do potrzeb. Takie podejście pozwala na znaczne zmniejszenie kosztów wdrożenia aplikacji.

Pomimo tych zalet, często jest tak, że systemy te pasują do prostych modeli biznesowych, które w życiu codziennym występują nad wyraz rzadko. W starciu z rzeczywistością, wdrażanie takich systemów, a przede wszystkim utrzymanie i reakcje na rozwój rynku mają przełożenie na zasadę Pareto, która mówi o tym, że 80% funkcjonalności jesteśmy w stanie osiągnąć w 20% czasu, a 20% krytycznych funkcji systemu konsumuje 80% budżetu.

Głównymi problemami z jakimi spotykają się wdrożenia oparte o gotowe rozwiązania to przede wszystkim komplikacja logiki biznesowej systemu, której nie da się odwzorować na możliwości produktu. Często dochodzi do paradoksalnych sytuacji, w których model biznesowy trzeba dopasowywać do systemu, co nigdy nie powinno mieć miejsca. Inną kwestia jest rozwój aplikacji i zwiększenie ruchu, które powoduje, że dobrze działające oprogramowanie dla małej liczby użytkowników staje się bezużyteczne przy wielkim obciążeniu. Poza tym istnieje potencjalne ryzyko związane z atakami hakerskimi, gdyż kod jest otwarty i dostępny dla potencjalnych włamywaczy. Aby dostrzec skalę problemu, wystarczy przejrzeć serwisy z dostępnymi exploitami. Ostatnią kwestią, która przychodzi w tym momencie na myśl, jest to, że czasem społeczność rozwijająca dany produkt, w pewnym etapie może zaprzestać dalszych prac. Powodów może być kilka, raz jest to skłócenie zespołu, innym razem przejście na nową technologię, lub do innego projektu, pozostawiając dotychczasowych użytkowników samych sobie.

Zalety tworzenia oprogramowania dedykowanego

Wszystkie problemy opisane powyżej rozwiązuje oprogramowanie dedykowane, a nawet można się pokusić o stwierdzenie, że wnosi tutaj wiele wartości dodanych. Przede wszystkim klient dostaje dokładnie to czego potrzebuje i za co płaci. Oczywiście trzeba mieć na względzie, że nie każdy klient jest osobą techniczną i nie koniecznie musi mieć doświadczenie z systemami informatycznymi, więc doradztwo technologiczne jest tutaj nieocenioną wartością. Firma programistyczna na etapie przygotowania oferty doradza klientowi najlepsze rozwiązania, proponuje pewne opcje, tworząc przy tym najlepszą możliwą ofertę, budując relację i zaufanie z zamawiającym. Dzięki temu klient odzwierciedla swój model biznesowy w tworzonym systemie, nastawiając się na zysk z inwestycji w przyszłości. Poza tym oprogramowanie jest gotowe na rozwój, co jest bardzo ważnym czynnikiem, gwarantującym skuteczność przedsięwzięcia i reakcję na sygnały spływające od użytkowników lub na trendy rynkowe. Ważnym czynnikiem jest tutaj również samopoczucie programistów, którzy nie klikają w panelach administracyjnych Drupala czy Magento, ale programują i rozwiązują problemy, realizując się przy tym zawodowo.

Nie wynajdujemy koła od nowa, czyli o frameworkach słów kilka

Framework to z definicji zestaw uniwersalnych narzędzi na bazie których tworzy się aplikacje. Nie wyobrażalne jest, aby w tych czasach tworzyć systemy informatyczne bez wykorzystania takiego narzędzia. Aby lepiej zobrazować temat, możemy porównać do płyty podwoziowej samochodu. Daje nam ona wszelkie potrzebne mechanizmy, czyli ramę całego auta, łożyska, układ wydechowy, wiązki elektryczne. Na takiej ramie możemy stworzyć wiele rodzajów samochodów, np. pickup, miejski hatchback, średniej klasy sedan, lub ekskluzywny, drogi wóz. Podobnie jest z frameworkiem – zapewnia mechanizmy potrzebne w większości systemów. Mowa przede wszystkim o kontrolerze aplikacji, reagującym na żądania użytkownika, warstwie widoku, prezentującą dane w formie graficzne, warstwie dostępu do bazy danych, mechanizmie bezpieczeństwa, pozwalającą na autoryzowanie użytkowników i ograniczanie dostępu do poszczególnych części serwisu. To tylko niektóre z rozwiązań, nowoczesne frameworki dostarczają wiele więcej. Inną kwestią jest standaryzacja kodu tworzonego przy ich użyciu. Jest o wiele łatwiej nowej osobie wejść w projekt, jeśli framework narzuca standardy kodowania i rozwiązania umieszczane są w odpowiedniej strukturze kodu. Pozwala to na szybsze wdrażanie się nowych członków zespołu, a co za tym idzie na przyspieszenie całego rozwoju.

Jest jeszcze jedna ważna kwestia, która decyduje o sukcesie danego frameworka – liczba gotowych rozwiązań w postaci wtyczek lub komponentów. Jest to sytuacja analogiczna do gotowych rozwiązań Open Source, z tym, że tutaj łatwo rozszerzyć dany komponent oraz dostosować go do wymagań systemu. Mamy też zapewnione wsparcie społeczności w kwestii rozwiązywania problemów, tworzenia nowych funkcjonalności czy aktualizacji i wydawania poprawek.

Dlaczego Symfony2 pasuje tutaj jak ulał?

Symfony2 kontynuuje dobrą passę swojego poprzednika, który istnieje już 6 lat. Programiści wyciągnęli naukę z poprzedniej wersji, podpatrzyli rozwiązania z innych platform (Java, Ruby On Rails, Python i Django, czy Zend Framework) i przepisali całość od podstaw. Dzięki temu powstał najlepszy aktualnie framework PHP, który wygrywa przede wszystkim bardzo dobrą strukturą niezależnych modułów, które można rozwijać oddzielnie, a nawet wykorzystywać w innych projektach. Autorzy przewidzieli strukturę projektu tworząc tzw. Bundle, które są modułami, gotowymi do użycia w innych projektach (nawet wnętrze frameworka się z nich składa). W tym momencie warto wspomnieć o Bundlach dostarczanych przez programistów i firmy zewnętrzne (jest ich już prawie 600). Całość systemu jest oparta o nowoczesny kontener wstrzykiwania zależności (Dependency Injection Container), przez co podmiana kluczowych części systemu może być zrobiona w mgnieniu oka (to rozwiązanie bardzo szeroko stosuje się w Java EE oraz innych dojrzałych rozwiązaniach). Warto też zauważyć, że autorzy duży nacisk kładą na wydajność i szybkość działania, co jest zauważalne na pierwszy rzut oka, bez wnikliwych badań obciążeniowych.

O powadze sytuacji świadczy też fakt, że Symfony2 zostało w całości przeniesione do gita i jego kod jest utrzymywany w serwisie Github.com. Dzięki temu każdy może go sklonować kod źródłowy, pracować na nim lokalnie wprowadzając poprawki czy tworząc nowe funkcjonalności, a później jednym kliknięciem wysłać prośbę o włączenie swoich zmian do głównego repozytorium. To powoduje, że na dzień dzisiejszy Symfony2 jest najczęściej rozgałęzianym i najchętniej oglądanym repozytorium PHP na Githubie, a liczba osób, które miały swój wkład w rozwój przekracza 250. Poza tym za frameworkiem stoi francuska firma Sensio Labs, wraz z założycielem i głównym programistą Fabienem Potencierem. Ten fakt zapewnia stabilność rozwoju, wysoką jakość dokumentacji oraz dostępność szkoleń i materiałów. Firma ta zorganizowała nawet zbiórkę pieniędzy wśród społeczności i zleciła audyt bezpieczeństwa organizacji zajmującej się tego typu działaniami .

Reasumując, trzeba przyznać, że Symfony2 zrewolucjonizowało świat frameworków PHP, a można się nawet pokusić o stwierdzenie, że programiści innych języków (Python, Ruby, Groovy) też z szacunkiem patrzą na to rozwiązanie. Symfony2 idealnie nadaje się do rozwoju aplikacji dedykowanych i na pewno można go polecić do większości projektów.

W wielu miastach na całym świecie odbywają się imprezy związane z premierą Symfony2. Także w Polsce programiści i osoby zainteresowane rozwojem tego frameworka będą mogły spotkać się i porozmawiać o jego możliwościach i zastosowaniach. W Gliwicach w siedzibie firm XSolve (branża software development) oraz Chilid (agencja New Marketing) w czwartek (28.07) odbędzie się XSolve Poland Symfony2 Launch Party! Impreza ma charakter otwarty i skierowana jest głównie do programistów pracujących we frameworku Symfony2 oraz osób działających w branży IT. Impreza organizowana jest przy promocyjnym wsparciu Wydawnictwa Helion, które zapewniło wartościowe nagrody dla gości, którzy wezmą udział w zaplanowanych konkursach.

Spotkanie rozpocznie się o godzinie 17.00, w trakcie jego trwania odbędzie się prezentacja Symfony2, będzie również możliwość wymiany doświadczeń z programistami XSolve, którzy na co dzień korzystają z tego frameworka.

Polub wydarzenie na Facebooku!

1. pobrania repozytorium na dysk
2. stworzenie konfiguracji vhost z jakąś nazwą serwera
3. stworzenie wpisu w /etc/hosts który będzie odzwierciedlał nazwę serwera użytego w vhoście na 127.0.0.1

Jestem pewny, że powyższa ścieżka jest używana przez wielu programistów. Możemy pominąć dwa ostatnie kroki, ograniczając przygotowanie środowiska do umieszczenia kodu źródłowego w specjalnym folderze na dysku. Aby to osiągnąć potrzebujemy moduł Apache’a mod_vhost_alias oraz prosty serwer DNS, który będzie rozwiązywał lokalne domeny dla nas.
Instalacja mod_vhost_alias jest dość prosta. Moduł jest prawdopodbnie dołączony do twojej instalacji Apache, pozostaje go tylko uruchomić następującą komendą:

sudo a2enmod vhost_alias

Dzięki mod vhost alias możemy dynamicznie wskazywać Document Root bazując na nazwie serwera. Wystarczy umieścić następującą konfigurację w pliku /etc/apache2/sites-enabled/000-default

Teraz wszystkie odwołania będą wskazywały na nasz /var/www/FIRST_PART_OF_DOMAIN/web, ponieważ użyliśmy modyfikatora %1. Możesz wprowadzić własną konwencję używając innych modyfikatorów w dyrektywie  VirtualDocumentRoot (patrz dokumentacja). Powyższa konfiguracja jest bardzo minimalistyczna, powinieneś dodać do niej jeszcze logowanie itp.

Ostatnią rzeczą, o jaką należy się zatroszczyć jest dynamiczne rozwiązywanie nazw domen. Najprostszym sposobem jest dodawanie nazwy serwera do pliku /etc/hosts, ale to wymaga dodawania wpisu dla każdego hosta. Na przykład wpis w /etc/hosts:

 127.0.0.1 myapp.local.dev

uruchomi aplikację zlokalizowaną w  /var/www/myapp/ (wskaże na katalog web/, według konwencji symfony). Jeśli chcesz to zautomatyzować, zainstaluj dnsmasq, prosty serwer DNS

sudo apt-get install dnsmasq

Następnie wyedytuj /etc/dnsmasq.conf file (może być położony gdzie indziej, tutaj na przykładzie Ubuntu):

listen-address=127.0.0.1
address=/.local.dev/127.0.0.1

Ostatnią rzeczą jest aktualizacja pliku /etc/resolv.conf przez dodanie adresu naszego DNSa na początek:

nameserver 127.0.0.1

Następnie restartujemy dnsmasq i Apache2:

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/dnsmasq restart

Od teraz możesz się cieszyć nową konfiguracją środowiska LAMP. Każdy nowy projekt potrzebuje być tylko umieszczony w katalogu  /var/www/PROJECT_NAME i będzie od razu dostępny z poziomu przeglądarki pod adresem  PROJECT_NAME.local.dev

Konfiguracja

Podstawowa konfiguracja polega na ustawieniu odpowiedniej klasy sterownika oraz strategii keszowania. Doctrine dostarcza klasy sterowników dla większości powszechnie używanych mechanizmów keszujących (APC, XCache, memcache) oraz dwie strategie keszowania (keszowanie wyników procesu parsowania zapytań DQL oraz keszowanie wyników zapytań SQL). W zależności od potrzeb konfigurację możemy przeprowadzić globalnie (do wyboru mamy konfigurację managera lub połączeń) lub lokalnie z poziomu konkretnego zapytania.

Pracując z symfony ustawienia globalne najlepiej zdefiniować poprzez dodanie metody configureDoctrine() klasy ProjectConfiguration. W zależności od wybranej strategii rejestrujemy sterownik poprzez ustawienie odpowiedniego atrybutu (Doctrine_Core::ATTR_QUERY_CACHE lub Doctrine_Core::ATTR_RESULT_CACHE). Dodatkowo poprzez ustawienie atrybutu Doctrine_Core::ATTR_*_CACHE_LIFESPAN możemy ustawić czas ważności rekordów.

Powyższa konfiguracja obejmuje wszystkie połączenia nawiązywane przez Doctrine. Czasem może zaistnieć potrzeba ograniczenia konfiguracji do konkretnego połączenia (na przykład jedno z dwóch połączeń jest nawiązywane do bazy danych modyfikowanej przez inną aplikacje). W takiej sytuacji możemy użyć metody configureDoctrineConnectionName() zastępując człon Name nazwą naszego połączenia.

W razie potrzeby konfigurację możemy przeprowadzić z poziomu konkretnego zapytania. Służą do tego metody useQueryCache() oraz useResultCache() (w dalszej części artykułu poznamy szersze zastosowanie tych metod). Konfiguracja lokalna nadpisuje konfigurację globalną.

Keszowanie w praktyce

Mając poprawnie skonfigurowany sterownik jesteśmy gotowi, aby zastosować mechanizm keszujący do naszych zapytań. Kolejne kroki zależą od poziomu konfiguracji oraz wybranej strategii keszownia. Dla przykładu, jeśli wybraliśmy konfigurację globalną oraz keszowanie wyników zapytań, należy powiadomić Doctrine, które zapytania mają być keszowane (keszowanie wyników procesu parsowania DQL jest automatycznie zastosowane do wszystkich zapytań). Służy do tego wczesniej poznana metoda useResultCache(). Metoda ta jako pierwszy parametr przyjmuje instancję sterownika lub wartość logiczną, który informuje czy dane zapytanie ma być objęte mechanizmem keszowania. Drugi parametr określa czas ważności rekordu dla naszego zapytania, natomiast trzeci jest identyfikatorem tego rekordu.

W ten sposób wynik zapytania po pierwszym wykonaniu zostanie umieszczony w mechanizmie keszującym pod nazwą sample_query na okres jednej godziny. W ciągu tej godziny każde kolejne wykonanie zapytania będzie oddelegowane do mechanizmu keszującego.

Przekazując do zapytania dodatkowe parametry, musimy zadbać, aby każdemu ich zestawowi odpowiadał inny ciąg identyfikujacy wynik zapytania. Doctrine automatycznie wygeneruje odpowiedni identyfikator jeśli nie podamy go jawnie. Takie rozwiązanie jest niewygodne jeśli mamy w perspektywie zarządzanie zawartością mechanizmu keszującego (musimy znać idnentyfikator). Więcej o zarządzaniu wynikami operacji keszowania można przeczytać w poniższym paragrafie.

Metoda useQueryCache() poza tym, że nie przyjmuje trzeciego parametru (identyfikatora) działa analogicznie do useResultCache(). Szczegółowe informacje można znaleźć w dokumentacji API.

Co dalej?

Keszowanie wyników zapytań niesie ze sobą pewne niebezpieczeństwo – dane mogą szybko stać się nieaktualne. Wraz ze sterownikami otrzymujemy zestaw metod umożliwiających zarządzanie zawartością mechanizmu keszującego. W połączeniu z mechanizmem zdarzeń możemy automatycznie usuwać skeszowane wyniki, zapewniając sobie w ten sposób aktualność danych.

Wolne od takich problemów jest keszowanie wyników parsowania DQL, które zarządzane jest przez Doctrine automatycznie.

Podsumowanie

Pomimo oczywistych zalet, stosowanie mechanizmu keszującego powinno być dobrze przemyślane. O ile keszowanie sparsowanych zapytań DQL jest bezpieczne (jeśli stosujemy prepared statements) i zaleca się jego użycie w większości projektów, to wykorzystanie skeszowanych wyników zapytań powinno dotyczyć tylko wybranych przypadków, w których ma sens i faktycznie przyniesie nam korzyści. Nie należy zapominać tutaj o zasadzie, że nie wszystko co zostało opisane jako dobra metoda na polepszenie wydajności aplikacji, będzie dawało taki rezultat we wszystkich sytuacjach.

]]> http://xlab.pl/doctrine-cache/feed/ 0 http://xlab.pl/atak-session-fixation-czym-jest-i-jak-sie-przed-nim-bronic/ http://xlab.pl/atak-session-fixation-czym-jest-i-jak-sie-przed-nim-bronic/#comments Fri, 19 Nov 2010 21:32:09 +0000 Wojtek Sznapka http://xlab.pl/?p=1606 Sesje w aplikacjach internetowych

Ze względu na fakt, że protokół HTTP jest bezstanowy, wyszła potrzeba, aby identyfikować wywołania tego samego użytkownika i przechowywać zmienne pomiędzy nimi. Tym mechanizmem są sesje. Każda sesja jest identyfikowana ciągiem znaków (domyślnie jest to losowy, 32 znakowy łańcuch), który jest przechowywany w ciasteczku (cookies) lub przekazywany przez URL. Identyfikator sesji jest unikalny dla użytkownika, a więc osoba, która w nieładny sposób wejdzie w jego posiadanie, praktycznie wykrada tożsamość danego użytkownika w danej aplikacji (portalu, sklepie internetowym, blogu, portalu społecznościowym).

Zagrożenia

Jako że, ciasteczka, czyli mechanizm zapisu informacji w przeglądarce użytkownika przez aplikację internetową, są mechanizmem względnie bezpiecznym, projektanci aplikacji zawsze powinni wybierać ten sposób przechowywania identyfikatora sesji. Przekazywanie SESSID (session id) w url’u wystawia aplikację na zagrożenie atakiem session fixation.

Szkodnik, który przejmie naszą sesje, może poczynić spore spustoszenie w naszej przestrzeni systemu, od publikacji kompromitujących treści, poprzez dostęp do prywatnych danych, historii naszej działalności (np. zakupów), poprzez nawet wykonanie jakiś transakcji na nasze konto. Zagrożenia jakie za tym idą, są różne, ze względu na różne specyfiki aplikacji webowych.

Co to jest session fixation?

Session fixation polega na podsunięciu użytkownikowi linku do atakowanej aplikacji z spreparowanym identyfikatorem sesji, który jest znany atakującemu. Jak to działa w praktyce? Przygotowujemy url w postaci http://moja.aplikacja?sekcja=profil&SESSID=1234abcd1234abcd1234abcd1234abcd i sugerujemy użytkownikowi jego kliknięcie, posyłając np. emailem lub linkując go pod jakieś zdjęcie. Użytkownik wchodzi do atakowanej aplikacji. Jako, że korzysta z nowej sesji, loguje się do systemu i wykonuje jakieś operacje. Atakujący wchodzi do aplikacji z tego samego linka i ma do dyspozycji zalogowane konto, dzięki czemu może wykonać dowolne operacje w imieniu skompromitowanego użytkownika.

Ze względu na specyfikę tego ataku, często w sieci stosuje się inne określenie: session riding, ponieważ „jeździmy” na czyjejś sesji, gdzie uzyskano odpowiedni dostęp do systemu.

Jak się bronić przed tym atakiem z punktu widzenia programisty?

Metoda jest prosta i domyślnie włączona w nowych wersjach PHP. Nigdy nie powinno się  używać identyfikatora sesji przekazywanego przez URL! Aby to osiągnąć, można użyć następujących ustawień PHP (w pliku php.ini):

Poza tym, powinniśmy regenerować id sesji przed logowaniami (metodą session_regenerate_id). Ostatnią rzeczą, która ochroni nas też przed innymi atakami, polegającymi na wyłudzeniu tożsamości, jest ponowne sprawdzenie hasła przed krytycznymi operacjami, takimi jak zmiana hasła, zmiana danych profilowych, usunięcie konta, czy dokonanie jakiejś sporej płatności. Tą metodę stosuje m.in. znany portal LinkedIn.

Jak się bronić przed tym atakiem z punktu widzenia użytkownika aplikacji?

Jako, że nie wiemy, czy aplikacja z której korzystamy jest podatna na tego typu ataki, powinniśmy zawsze ostrożnie korzystać z linków, które dostajemy z nieznanych źródeł. Jeśli jesteśmy zalogowani do portalu X, a za chwilę dostaniemy podejrzanie długi link, po wejściu na który znowu jesteśmy proszeni o hasło, to znaczy, że coś nie gra i należy się dwa razy zastanowić na dalszymi krokami.

Jak widać, Foo::modifyProperty zmienił prywatną właściwość innego obiektu. Właściwie type-hinting nie jest tu wymagane, ale jego brak może wprowadzić wiele zamieszania :-)
Pomimo, że PHP oferuje takie rozwiązanie, szczerze odradzam stosowanie go w codziennej praktyce…

    $conn = new PDO('dblib:host=127.0.0.1;dbname=database', 'user', 'pass');
    $stmt = $conn->prepare("EXEC sp_SaveMagicNumber ?");
    $stmt->bindValue(1, 5, PDO::PARAM_INT);
    $stmt->execute();

Kod z powyższego listingu wywoła procedurę sp_SaveMagicNumber z parameterem 5. Jeśli używamy symfony wraz z Doctrine, możemy (a nawet powinniśmy) zamienić pierwszą linijkę na:

    $conn = Doctrine_Manager::getInstance()->getConnection();

Można też przekazywać parametry jako „placeholdery”, jak na listingu poniżej:

    $conn = Doctrine_Manager::getInstance()->getConnection();
    $stmt = $conn->prepare("EXEC sp_IntroduceYourself :name, :surname");
    $stmt->bindValue(':surname', 'Sznapka', PDO::PARAM_STR);
    $stmt->bindValue(':name', 'Wojtek', PDO::PARAM_STR);
    $stmt->execute();

Ostatnim punktem programu są parametry typu OUTPUT, czyli zwracające wartości z procedury składowanej (podobnie jak parametry funkcji PHP przekazywanych przez referencję). Niestety biblioteka PDO posiada błąd, który uniemożliwia poprawne działanie metod z takimi parametrami. W idealnym przypadku, jeśli parametr w MSSQL jest zdefiniowany jako OUTPUT powinniśmy go dostać następujący sposób:

    $conn = Doctrine_Manager::getInstance()->getConnection();
    $stmt = $conn->prepare("EXEC sp_GetCountry :city, :country OUTPUT");
    $stmt->bindValue(':city', 'Gliwice', PDO::PARAM_STR);
    $country = NULL;
    $stmt->bindParam(':country', $country, PDO::PARAM_STR | PDO::PARAM_INPUT_OUTPUT);
    $stmt->execute();
    printf("Dla miasta %s procedura zwraca kraj %s", $city, country);

Niestety pomimo wielu prób, nie udało się obejść tego błędu i na chwilę obecną wygląda na to, że nie ma sposobu na pozyskiwanie parametrów typu OUTPUT z procedur składowanych MSSQL. Podobne problemy można spotkać na bugtrackerze PHP: http://bugs.php.net/bug.php?id=50555