[nadmuchane_jaja]

#informatyka #serwery #apache #httpd #unix #security @niebezpiecznik-pl

Mirki admini i programiciele, wpadłem na pewną ciekawą problemowość związaną z serwerem Apache 2.4 (testuję na wersji apache24-2.4.27_1). Otóż mam na vhoście autoryzację poprzez basic auth (czyli user/password) oraz ten sam vhost wymaga uwierzytelnienia przy pomocy certyfikatu SSL (SSLVerifyClient require). Wszystko fajnie działa, sprawnie i do tej pory myślałem, że nawet nieźle bezpiecznie. Dzisiaj potrzebowałem napisać sobie skrypt w bashu do crontabu, aby co kilka minut odpytywał mi serwer po adresie URL (pomyślałem o wget) i uruchamiał podfunkcję webserwisu (do rejestracji zamówień z obcego API, np. https://serwisxxx.pl/wczytajzapi, ale to nieistotne). Ku mojemu zdziwieniu, apache w w/w wersji zanim otrzyma user/password odpala mi stronę., tzn. oczywiście nie daje do niej dostępu i po stronie Klienta otrzymuję komunikat unauthorized:

HTTP request sent, awaiting response... 401 Unauthorized

Username/Password Authentication Failed.

Ale po stronie serwera skrypt wykonuje się i kończy działanie tak, jakby był wywołany przez zautoryzowanego usera. Widzę to po logach mojego systemu webserwisowego.

Dzisiaj jest za późno i nie chce mi się już grzebać, ale jutro sprawdzę czy przyjmuje też dane z POSTa, bo z GET jedzie wszystko. Wpisałem parametry argumentów i wszystko skrypt PHP przyjął na klatę i wykonał. To samo próbowałem zrobić na firefoxie, operze, chromie z windowsa i żaden z Klientów tego nie potrafi. W przypadku wget się udaje za każdym razem.

Już w/w scenariusz uważam za rewolucję i poważną awarię zabezpieczeń. Jeśli się okaże, że POSTa też chwyta to jest k---a ciekawie. Najnowsze wydanie Apache 2.4.

Komenda do sprawdzenia jak kogoś interesuje to:

wget --no-check-certificate --certificate=sslcert.crt --private-key=sslkey.key --user=username --password=PASSCODE https://adresserwera.pl/komenda?q=XXX

Po wywołaniu w/w w logach widzę dwukrotne (błędne, bo powinno tylko raz) przekręcenie pętli która pobiera dane z obcego API w moim systemie. Jak wyrzucę user/password z w/w polecenia wget to w logach widzę tylko jedno przekręcenie pętli, a wget zwraca:

HTTP request sent, awaiting response... 401 Unauthorized

Username/Password Authentication Failed.

Czujecie? Mieliście podobne problemy czy raczej zawsze chodzi tylko o d--y? A może to normalne zachowanie serwera www, a ja się czepiam na siłę?

[elirath]

@nadmuchane_jaja: pokaż konfiguracje apache z autoryzacją. Jak przekazujesz zapytania do backendu? Może być tak, że założyłeś basic autha na pliki serwowane przez apache ale nie wymagasz autoryzacji dla zapytań przekazywanych do backendu.

[nadmuchane_jaja]

@elirath: możesz coś więcej?

Mam coś w tym stylu:
194
195 AuthType Basic
196

[elirath]

@nadmuchane_jaja a pozostałe opcje? Możesz mieć gdzieś niżej np. które nadpisze Ci te ustawienia. Pokaż cały konfig.

[nadmuchane_jaja]

@elirath:

ServerName backoffice.******.com
165
166 DocumentRoot

[elirath]

@nadmuchane_jaja: masz gdzieś tam może SSLOptions +FakeBasicAuth? Coś się zmieni kiedy dodasz "SSLOptions -FakeBasicAuth"?

Czy nie masz przypadkiem ustawionego ErrorLog 401 na plik php?

Przenieś może autoryzacje z Location do Directory. Wydaje mi się, że Location jest przetwarzane dopiero po Files.

[nadmuchane_jaja]

@elirath: Przeniesienie autoryzacji na Directory nic nie dało. Error 401 mam statyczny. -FakeBasicAuth też nic nie dało. Cały czas mogę wykonać skrypt przez wget.

[elirath]

@nadmuchane_jaja: no, cóż, u mnie się ten apache inaczej zachowuje (testuje na 2.4.28). Potrzebuję od Ciebie, albo: minimalny konfig do przetestowania który mogę wkleić u siebie, albo: wynik ze strace -ffvvtt -s 60000 -o /tmp/strace -p pidapache -p pidapache -p pidapache kiedy wykonujesz jedno zapytanie. W tym strace powinieneś widzieć, że apache robi connect() do socketa z php. Powinieneś też widzieć, że apache wysyła zapytanie do php, odsyła 401 do