Wygłaszałem dzisiaj prezentacje na KrakSpot Tech#5. Jeżeli ktoś nie był to niech żałuje. Na otarcie łez moja prezentacja o MongoDb:

Alternatywne podejście do baz danych – MongoDb

View more presentations from Wojciech Soczyński.

Chciałbym też pogratulować wszystkim pozostałym prelegentom ciekawych prezentacji oraz podziękować Zyxowi i Adamowi za inspirującą rozmowę . Dziękuję też organizatorom za pizzę i czekam na więcej takich eventów

Jakiś czas temu natknąłem się na Agile Toolkit – interesujący framework, pozwalający skupić się tylko i wyłącznie na programowaniu. Podłubałem nieco w tym frameworku, zrobiłem kilka prostych stronek “do szuflady” i na chwilę obecną nie mam do niego większych zastrzeżeń. Jakiś czas temu na blogu projektu pojawił się wpis, w którym autor frameworka prosi o pomoc w tłumaczeniu dokumentacji na inne języki. Znalazłem chwilę, zrobiłem forka na githubie i zacząłem powoli tłumaczyć. Póki co teksty przeze mnie napisane są surowym tłumaczeniem, nienadającym się na wysłanie do macierzystego repozytorium. Wymagają one przede wszystkim korekty edytorskiej lub co najmniej świeżego oka, które wyłapie moje potknięcia (również te w tłumaczeniu). Jeśli macie ochotę i odrobinę wolnego czasu, zróbcie forka z mojego (lub głównego) repozytorium, znajdźcie błędy i/lub przetłumaczcie to, co jeszcze nie jest przetłumaczone. Kto wie, może Agile Toolkit wyrośnie na godnego konkurenta ZF lub Symfony?

Mój fork na githubie – https://github.com/wilgucki/atk4-web Repozytorium projektu – https://github.com/atk4/atk4-web

Każdy używający Zend Frameworka wcześniej czy później natknie się na klasę służącą do tworzenia formularzy – Zend Form. Jest to całkiem przydatna klasa i znakomicie się sprawdza. Sprawdza się świetnie do momentu, kiedy nasz webmaster stwierdzi, że jednak ubranie formularza w dl/dt/dd jest już passe i przydało by się np. ubrać go w tagi ul/li. Mnie właśnie dzisiaj przydarzyła się taka sytuacja, a więc ku pamięci wrzucam rozwiązanie:

class Form extends Zend_Form
public function init() {

        $email = new Zend_Form_Element_Text('email');
        $email->setLabel('Email:');
        $email->addValidator(new Zend_Validate_EmailAddress());
        $email->setRequired();

        $firstName = new Zend_Form_Element_Text('first_name');
        $firstName->setLabel('First name:');
        $firstName->setRequired();

        $lastName = new Zend_Form_Element_Text('last_name');
        $lastName->setLabel('Last name');
        $lastName->setRequired();

        $this->addElements(array($email, $firstName, $lastName));
}

 public function loadDefaultDecorators() {
        parent::loadDefaultDecorators();

        $this->_decorators['HtmlTag']['options']['tag'] = 'ul';

        foreach ($this->_elements as $el) {
            if ($el instanceof Zend_Form_Element_Text) {
                $el->removeDecorator('HtmlTag');
                $el->removeDecorator('Label');

                $el->addDecorator('Label', array('tag' => null));
                $el->addDecorator('HtmlTag', array('tag' => 'li'));
            }

            if ($el instanceof Zend_Form_Element_Submit) {
                $el->removeDecorator('Label');
                $el->removeDecorator('DtDdWrapper');
                $el->addDecorator('HtmlTag', array('tag' => 'li'));
            }
        }
    }

}

Co jak i dlaczego ?

Pierwsze na co należy zwrócić uwagę to miejsce modyfikacji dekoratorów – robimy to w metodzie loadDefaultDecorators(). Jest ona wywoływana jako ostatnia metoda w konstruktorze klasy Zend_Form i dzięki temu mamy już dostęp do wszystkich koniecznych obiektów i pól.

Kolejna kwestia na która trzeba zwrócić uwagę to rozróżnienie pomiędzy różnymi rodzajami elementów formularza. Różne klasy mają różne dekoratory w standardzie.

Najbardziej zastanawiający fragment tego kodu to:

                $el->removeDecorator('HtmlTag');
                $el->removeDecorator('Label');

                $el->addDecorator('Label', array('tag' => null));
                $el->addDecorator('HtmlTag', array('tag' => 'li'));

Po co najpierw usuwać a następnie ponownie dodawać te same dekoratory ? Ano po to by zamienić je miejscami . Flow dekoratorów jest taki, że każdy dekorator dodany później dostaje cały kontent wygenerowany przez te, które były dodane wcześniej. Dzięki temu możemy hierarchicznie budować strukturę HTML-a.

Btw. Powyższy kod jest z takiej niezbyt świeżej wersji frameworka. Także, jeżeli coś się zmieniło to z góry przepraszam i chętnie przyjmę kod na nowszej wersji

Przy okazji różnych dziwnych spraw, Ferenc Kovacs wrzucił fajną prezentację odnośnie historii Unikodu w PHP i problemach z jego implementacją dla PHP 6. Ciekawa rzecz do obejrzenia:

http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6

Ci, którzy śledzą działania ludzi związanych z językiem PHP na pewno są świadomi tego, jak dynamiczne zmiany zachodzą zarówno w interpreterze, jak i w samej społeczności skupionej wokół technologii z nim związanych. Zapraszam do lektury kolejnego zestawu ciekawych materiałów na ten temat.     Linkdump: PeHaPe. 1. Scaling PHP Up, Out, and Around. Kilka słów [...]

Dziś bardzo krótko, bez zbędnych dywagacji, czyli tylko i wyłącznie o tablicy $_SERVER. Dbając o bezpieczeństwo aplikacji webowych zwraca się uwagę na wiele czynników, jakimi są SQL injections, przechwytywanie nieprawidłowych parametrów, uogólniające zapytania przepuszczające maskę % w LIKE zapytaniu do baz, XSS‘y w $_POST, $_GET.

I finalnie… wiele osób zapomina (a jeszcze więcej nie jest tego świadom) o możliwości wstrzyknięcia szkodliwych danych w $_SERVER['HTTP_X_FORWARDED_FOR'];. Konsekwencje są oczywiście katastrofalne.

O ile sama walidacja jest rzeczą wtórną, diabeł tkwi w trzech szczegółach:

1. Rzecz trywialna, ale pamiętajmy, że w naturalnym procesie użytkowania przeglądarki, w nagłówku może zostać zwrócony nie tylko jeden adres IP, a kilka oddzielonych przecinkiem, w tym localhost‘y (standard nagłówka X-Forwarded-For).
2. Wstrzyknięcie Javascriptów jest możliwe, ale notabene najmniej szkodliwe, bo do spreparowania nagłówka potrzebny jest bardziej zaawansowany proces (dajmy na to Data Tamping, który przedstawię poniżej), np. niż wklejenie syfu w linku/obrazku i przesłanie go komuś przez komunikator, żeby wykraść jego ciasteczka sesyjne document.cookie i przesłać je sobie na serwer w dowolny sposób, zatem atakowi nie ulegną osoby trzecie.
3. Niepoprawność danych, które można zmanipulować, jest chyba rzeczą oczywistą: nieprzepuszczenie takich danych przez filtry może skutkować złymi wartościami zwracanymi np. przez ip2long() i zapis w zupełności nieprzydatnych nam później danych do bazy.
4. … ale największe nieprzyjemności możemy mieć przez spreparowanie lewych zapytań do baz danych, o ile nie używamy sprawdzonych ORM lub czegokolwiek, co pomaga nam filtrować wartości do niej przekazywane i używane w warunkach zapytań (data binding).

Przykład tampingu danych, żeby spreparować niepożądane efekty.

Mamy bardzo prosty, niebezpieczny kod funkcji, która pobiera pierwszy adres na liście adresów oddzielonych przecinkami z $_SERVER['HTTP_X_FORWARDED_FOR'] o ile istnieje, natomiast w przeciwnym wypadku $_SERVER['REMOTE_ADDR']:

< ?php
 
function getUserIp()
{
  if(isset($_SERVER['HTTP_X_FORWARDED_FOR']))
    return trim(current(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])));
 
  return $_SERVER['REMOTE_ADDR'];
}
 
$sUserIP = getUserIp();
 
echo 'Hi "' . $sUserIP . '"!'; // first bug while display.
var_dump(ip2long($sUserIP)); // second bug while transforming data.
 
?>

Pora na przykład manipulacji takich danych.

• Będziemy używać Tamper Data dla Firefox’a.Dość popularny wśród developerów addon do Firefox’a, pozwala zmodyfikować dane $_POST, $_GET, $_COOKIE, nagłówki, “w locie żądania” etc.
• Po instalacji w menu Narzędzia pojawi się pozycja Dane Tamper, która uruchamia okienko do podsłuchiwania żądań. Po kliknięciu Rozpocznij podsłuchujemy wszystkie wychodzące żądania z naszej przeglądarki. Każde żądanie nie zostanie przepuszczone, dopóki go nie zmanipulujemy klikając Tamper, lub przepuścimy dalej klikając Wyślij.
• Jeżeli zdecydujemy się Tamper’ować żądanie, naszym oczom ukaże się okno z parametrami. Klikamy prawym przyciskiem myszy na listę parametrów, wybieramy Dodaj i wpisujemy nasz przykładowy, brzydki dla aplikacji nagłówek: X_FORWARDED_FOR=<script>alert('Test.')</script>

Naszym oczom ukazują się co najmniej dwa błędy. Pierwszy to błąd prezentacji danych, który wykorzystuje <script>. O ile nie musimy się tym przejmować, bo naturalnie takie żądania nie są tak łatwo wysyłane, użytkownik nie może paść ofiarą ataku przez kliknięcie w link, który np. ukradnie mu ciasteczka. Dane nagłówkowe nie są w stanie być zmodyfikowane poprzez kliknięcie w link, podobnie jak z danymi $_POST (oczywiście mówimy o przypadkach trywialnych, bez javascript’owych wymuszanych submitów targetowanych do np. ramek).

Znacznie poważniejszym błędem jest konsekwencja wadliwego formatu danych, które nasza funkcja bagatelizuje. Po pierwsze mamy fałszywe dane zwracane przez ip2long(), po drugie kto powiedział, że właśnie z tej funkcji korzystamy, a nie zapisujemy danych plain’em i nie bindujemy pofiltrowanych danych lub instrukcji warunkowych zapytania przez np. sprawdzony ORM.

Rozwiązanie problemu.

Edit: Jak słusznie zauważył Zyx, zapomniałem o tym wspomnieć, że skoro mogą znaleźć się tam dowolne dane przesłane od użytkownika, nie należy tego pola traktować jako wyznacznik, że jest to numer jego IP, jest ono bezużyteczne i powoduje potencjalną lukę. Poza zabezpieczeniami to podstawowy argument, żeby o polu zapomnieć i używać $_SERVER['REMOTE_ADDR'].

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Ostatnimi czasy uczestniczyłem głównie w spotkaniach o JavaScript (Falsy Values, zaawansowany js), Front-Endowych (Front-Trends), konferencjach dotyczących bezpieczeństwa (ConFidence). Dla równowagi front-endu z back-endem wypadałoby wybrać się wreszcie na coś związanego z PHP. Na przeciw moim potrzebom wyszli organizatorzy PHPCon.

PHPCon Poland

PHPCon Poland to ogólnopolskie spotkanie konferencyjne programistów i entuzjastów języka PHP, organizowane siłami wolontariuszy internetowych z całego kraju pod egidą zarządu stowarzyszenia Polska Grupa Użytkowników Linuxa (PLUG). Jej celem jest integracja środowisk osób związanych z PHP oraz środowiska biznesowego zainteresowanego praktycznym wykorzystaniem tego języka w projektach komercyjnych.

PHPCon PL to świetna okazja, by nawiązać nowe kontakty, wymienić doświadczenia i pomysły na przyszłość. Impreza ta jest skierowana zarówno dla profesjonalistów, jak i osób, które dopiero od jakiegoś czasu zajmują się PHP. Dzięki zróżnicowanej agendzie, konferencja daje możliwość ugruntowania lub poszerzenia swojej wiedzy w wybranych tematach.

PHPCon PL ma tak jak co roku charakter niekomercyjnego spotkania sympatyków PLUG. Dla osób, które z różnych przyczyn potrzebują faktury, odbywa się – już zupełnie komercyjnie – spotkanie o tej samej nazwie, w tym samym miejscu i czasie, ale organizowane i fakturowane przez firmę obsługującą klientów biznesowych.

PHPCon Poland 2011

Przygotowania do PHPCon ruszyły pełną parą. To już druga edycja konferencji PHPCon PL. Na blogu Mateusza Kamińskiego oraz u Przemka „eRiza” Pawliczuka oraz u Tomka „ZyXa” Jędrzejewskiego możecie poczytać jak było w roku 2010.

Co nam przyniesie tegoroczna edycja? Przede wszystkim warto wspomnieć o gościu specjalnym, którym w tym roku jest Lorna ‘LornaJane’ Mitchell. LornaJane jest znaną konsultantką PHP, webdeveloperką, publikatorką i prelegentką z Leeds w UK.

Czas i miejsce

PHPCon 2011 odbędzie się w dniach 21 – 23 października w miejscowości Mąchocice Kapitulne (rejon Gór Świętokrzyskich). Miejscem wystąpień będzie położony niedaleko Kielc Hotel Przedwiośnie ***. Zapisy uczestników zostaną otwarte po 15 lipca.

Call For Papers

Do 15 lipca zbierane są propozycje wystąpień. W związku z tym, organizatorzy zachęcają wszystkich, którzy mają ciekawy temat do zaprezentowania, do zgłoszenia swojej propozycji. Najciekawsze są oczywiście tematy nietuzinkowe, trudne do znalezienia w podręcznikach czy internecie. Są już pierwsze zgłoszenia z zagranicy, zatem można się spodziewać, że w tym roku poziom merytoryczny będzie na pewno wyższy, niż w roku ubiegłym. CFP można nadsyłać korzystając z formularza propozycji prelekcji na stronie http://www.phpcon.pl/2011/pl/aglista

Do tych co wybierają się na PHP Con 2011 – do zobaczenia w październiku!