w nawiązaniu do: http://goo.gl/6E5Ul

nie sądzę, żeby wszędzie był możliwy natychmiastowy upgrade php.
zastanawiam się więc jak programowo można zabezpieczyć strony na tę podatność?

Doczytałeś do końca ten artykuł? Przecież tam są podane rozwiązania problemu.

czyli jakie? zmniejszenie wielkości pliku i limitu czasu zmniejsza podatność a nie go eliminuje.

Uaktualnij php na serwerze do rewizji przynajmniej 321040 i po sprawie. Po co linkujesz artykuł, którego nawet uważnie nie przeczytałeś?

co żeś się uparł. primo po pierwsze napisałem we wstępie, że pewnie nie wszędzie natychmiastowy upgrade php jest możliwy. myślę, że ze zrozumiałych przyczyn.
primo po drugie, sam artykuł, do którego mnie tak uparcie nawracasz, mówi, cytuję:

Rozwiązań problemu jest kilka. (...) obniżenie paczki POST (...) Jednak nie zawsze jest to możliwe. (...) Póki co niektórzy wdrażają obejścia problemu.

i o to "obejścia" mi chodzi. Mnie to interesuje i być może kilka innych osób też. Może więc skończymy OT, ok?

edit: właśnie zobaczyłem - ktoś dopisał pod artukułem, że Suhosin zabezpiecza php na tę podatność. Poszukałem potwierdzenia i wg info z forum arstechnica:
serwer zabezpiecza ustawienie suhosin.request.max_vars i suhosin.post.max_vars (najlepiej oba, chociaż w niektórych konfiguracjach wystarcza jeden parametr)

Jeśli już tak uparcie wolisz szukać "obejścia" problemu to czy faktycznie nie lepiej skompilować phpa ze źródeł z tej rewizji? Jeśli nie będzie to rozwiązanie łatwiejsze to przynajmniej rozwiązujące problem trwale. Po co na siłę komplikować sobie życie? O Sushoshinie też przeczytałem komentarz i jest to pewne rozwiązanie (suhosin.post.max_vars i suhosin.request.max_vars) , ale nie obejście na szybko, bo pewnie o to pytasz. Jedyne, co mi przychodzi w tym momencie na myśli to użycie mod_security dla apacha i ustawienie w .htaccesie:

SecFilterEngine on
SecFilterScanPOST on

Można jeszcze próbować ograniczać ilość przesyłanych danych za pomocą metody POST, ale nie zawsze można ograniczyć poniżej wartości umożliwiającej skuteczne przeprowadzenie ataku na słabą maszynę, a czasami w ogóle jest to niemożliwe. W sumie jest też kolejny sposób, opisany w załączonym oryginalnym dokumencie. Pod koniec tych matematyczno-algorytmicznych wywodów jest sekcja "How to fix it?" I pokazano tam, w jaki sposób można bronić się prze atakami złożoności algorytmicznej (? "algorithmic complexity attacks").

W php ini:
zmniejszamy wartości
max_input_time oraz
max_input_vars
post_max_size
max_input_time

Dopiero te wszystkie czynności razem wykonane dają alternatywę dla kompilacji źródeł z rewizji od 321040 wzwyż. I tylko tyle Ci chciałem przekazać poprzednim postem.
// edit
Jeszcze się odniosę do tego:


Optymalne ustawienia w/w wartości dla Twojego sprzętu powinny dać Ci tyle, że powyższy atak w opisanej w załączniku formie będzie niemożliwy do przeprowadzenia z prostego powodu- Twoja maszyn po prostu sobie poradzi z odpowiednio małą ilością przesyłanych (obciętych tudzież w ogóle odrzuconych) danych zakładając, że atak pozostanie w niezmienionej formie, tzn. nie zrobi się z tego rozproszony dos.

Kurcze, i dopiero teraz na to wpadli? Kim są Ci hakerzy z CCC, wiecie może? Jeśli ktoś wiedziałby na jakiej zasadzie działa Apache albo chociaż jak sa przetwarzane dane POST to by od razu to zauważył - nie sądzicie? Wg mnie błahy bug i błahe rozwiązanie.

Chciałbym zastrzec, że nie znam się na tym i prosze nie lecieć po mnie - po prostu wyraziłem swoje zdanie z nadzieją, że jeśli ktoś uzna, że jest złe - poprawi mnie.

Sądzisz że przeciętny 'klepacz kodu' zagłębia się w sposób obsługi requestów w silniku Apache'a ? Wątpie. Ale tak po prawdzie nie nazwał bym tego atakiem, zwykły DDOS przed którym w dodatku łatwo się zabezpieczyć.

Przed tym atakiem zapobiegają też dobre serwery ... apache nigdy nie należał chyba do tej grupy bez modyfikacji
Z tego co wiem nginx oraz litespeed nie są podatne bo wprowadzają same limit. Dodatkowo litespeed nie pozwoli przekorcyzć 30 sekund wykonywania (limiter w php nie działa w tym przypadku, zewnetrzny serwera owszem).

Dobrymi serwerami są również Oracle Glassfish i Jetty a jednak i tu problem wystąpił. To nie jest tak, że "dopiero teraz na to wpadli", problem był prawdopodobnie znany wcześniej. Już w 2008 roku w CRubym wypuszczono odpowiedni fix. Więcej info w podlinkowanym pdfie