Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Kuriozalna podatność w Symfony, można nagłówkiem HTTP nadpisać prawdziwy URL
Zerknijcie tylko na ten opis podatności:
Support for a (legacy) IIS header that lets users override the path in the request URL via the
X-Original-URLorX-Rewrite-URLHTTP request header allows a user to access one URL but have Symfony return a different one which can bypass restrictions on higher level caches and web servers.
Czyli z jednej strony ograniczacie dostęp np. do admina na webserwerze, a ktoś robi request typu:
GET / HTTP/1.0
X-Original-URL: /admin
I bum, jest w adminie :)
Podatność załatano w Symfony w wersjach: 2.7.49, 2.8.44, 3.3.18, 3.4.14, 4.0.14, and 4.1.3.
Ale warto zwrócić uwagę na fakt, że podatna biblioteka może być również wykorzystywana w innych, popularnych rozwiązaniach. Przykładem jest tu choćby Drupal.
–ms
Warto dodać 2 rzeczy:
– framework nazywa się Symfony a nie Symphony
– zapewne dużo większą popularność ma kombinacja Apache|Nginx + PHP/Symfony niż IIS + PHP/Symfony, co warto podkreślić i uspokoić Linuksiarzy
1. Poprawione
2. Trzeba by się bardziej zagłębić w patcha. Ale stawiamy raczej na to, że nagłówek oryginalnie jest rzeczywiście używany przez IIS, ale z racji że jest to REQUEST nagłówek – to każdy może go użyć + powinno zadziałać niezależnie czy całość siedzi na Linuksie czy Windowsie.
Stosowny fragment z patcha wygląda tak (tj usunięto m.in. ten fragment):
if ($this->headers->has(’X_ORIGINAL_URL’)) {
// IIS with Microsoft Rewrite Module
$requestUri = $this->headers->get(’X_ORIGINAL_URL’);
Najprościej to potwierdzić na jakiejś konkretnej instalacji Symfony
Bez patcha:
Sf 2.8 + nginx – nie działa
sf 2.8 + apache – nie działa
Z całym szacunkiem, ale sugerowanie, że tak można się dostać do admina jest niepoważne dla takiego portalu.
No dobrze, wytłumacz dlaczego niby nie?
(jeśli decyzja o ograniczeniu dostępu do danego zasobu (np. /admin) jest robiona na webserwerze. Np. ograniczenie na źródłowe IP-ki, czy wymaganie Basic Auth, czy skierowanie do modułu uwierzytelnienia).
Jeszcze inaczej – dokładnie o tym jest mowa w opisie buga:
„HTTP request header allows a user to access one URL but have Symfony return a different one which can bypass restrictions on higher level caches and web servers.”
Zwracam uwagę na „which can bypass restrictions on higher level caches and web servers.”
Po prostu artykuł brzmi jakby w każdej aplikacji Symfony można było wejść do admina po podmianie requesta, a to zdecydowana przesada, bo nie wyobrażam sobie, żeby ktoś robił autoryzację do admina w sposób jaki przedstawiacie. W dodatku problemu nie ma ani na Apache, ani na nginxie, więc ciekawe czy jest choć jedna taka strona, która się na ten błąd załapie?
Oczywiście to głupi oraz wielki błąd i nie mam zamiaru bronić Symfony, ani tym bardziej PHP, bo swoje zdanie o nim mam i nie jest najlepsze, ale chodzi mi o przekaz artykułu.
Bez tego fragmentu w tekście „Czyli z jednej strony ograniczacie dostęp np. do admina na webserwerze, a ktoś robi request typu:”
to pewnie można by to tak zrozumieć.
„W dodatku problemu nie ma ani na Apache, ani na nginxie,”
Kto tak napisał? Przynajmniej wg naszego rozumienia (patrz poprzednie komentarze) – to kiedyś dołożyli coś takiego (obsługę X-Original-URL) żeby być kompatybilnym z konkretnym nagłówkiem IIS. Ale nagłówek jako klient to możesz sobie wysłać dowolny (szczególnie ten „podatny”) i to niezależnie jaki jest webserwer po drugiej stronie.
Chyba że przed tym if-em który cytujemy w komentarzu (z patcha) jest jeszcze jakieś magiczne sprawdzenie czy akurat działamy na IIS (choć tak na szybko nie widać tego).
Jak potrzebujesz jeszcze innych kejsów do tego, to zerknij np. tutaj: https://hackerone.com/reports/59665
Sprawdzone na nginx, PoC działa. Udało się obejść basic auth, który jest na poziomie nginx wymuszony na wszystkich URL-ach, oprócz paru wyjątków. Odpytując URL, który ma wyłączony basic auth można w nagłówku X-Original-URL podać dowolny inny URL z aplikacji, który normalnie byłby chroniony przez basic auth.
Z tego co kojarzę, a postawiłem trochę aplikacji na symfony od 1.4 do latest w każdej z tych wersji możesz ustawić swój listener ze swoimi regułami security. Jeżeli cały system autoryzacji użytkowników opierasz o framework, to musisz mieć z tyłu głowy że jest na pewno jakaś luka w zabezpieczeniach, obojętnie z czego korzystasz.
Poza tym nawet jak ktoś w http wymusi przejście na /admin, a system autoryzacji jest zrobiony porządnie, np. ma votery i wewnętrzną implementacje to od razu dostanie user odmowę, więc nie rozumiem czemu niby wymuszenie odwiedzenia zasobu przy odpowiednim security miałoby jakiekolwiek znaczenie