•  

    #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 kurwa 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 dupy? A może to normalne zachowanie serwera www, a ja się czepiam na siłę?

    źródło: apache.org

    +: Shizerq, K.........a +4 innych
    •  

      @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.

    •  

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

      Mam coś w tym stylu:
      194 <Location "/">
      195 AuthType Basic
      196 AuthName "LR"
      197 AuthUserFile /root/authfile
      198 Require valid-user
      199 </Location>

    •  

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

    •  

      @elirath:

      ServerName backoffice.******.com


      165
      166 DocumentRoot /web/backoffice
      167
      168 <Directory "/web/backoffice">
      169 Options -Indexes +FollowSymLinks
      170 AllowOverride None
      171
      172 Require all granted
      173 </Directory>
      174
      175 SSLEngine On
      176 SSLCertificateFile /etc/ssl/backoffice.crt
      177 SSLCertificateKeyFile /etc/ssl/backoffice.key
      178 SSLCACertificateFile /etc/ssl/ca.crt
      179
      180 SSLProtocol all -SSLv2 -SSLv3
      181 SSLCipherSuite HIGH:MEDIUM
      182 SSLVerifyClient require

      183 SSLOptions +StdEnvVars
      184
      185 SSLSessionCacheTimeout 300
      186
      187 # LogLevel warn
      188 # CustomLog /var/log/ssl_backoffice.warn combined
      189
      190 <FilesMatch .php$>
      191 SetHandler "proxy:unix:/var/run/phph-fpm.socket|fcgi://localhost"
      192 </FilesMatch>

      Dalej jest to co wkleiłem wcześniej i na tym koniec.

    •  

      @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.

    •  

      @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.

    •  

      @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 klienta i otrzymuje jakiś wynik z php.

      W wyniku ze strace mogą być prywatne dane, więc może nie będziesz chciał tego wklejać w jakieś publiczne miejsce (czy może w ogóle udostępniać w internecie - sprawdź).

Gorące dyskusje ostatnie 12h

Advertisement