FixVibe
Covered by FixVibehigh

CORS Błędna konfiguracja: ryzyko stosowania zbyt liberalnych zasad

Udostępnianie zasobów między źródłami (CORS) to mechanizm przeglądarki zaprojektowany w celu złagodzenia zasad tego samego pochodzenia (SOP). Choć jest to konieczne w przypadku nowoczesnych aplikacji internetowych, niewłaściwa implementacja — na przykład wyświetlanie echa nagłówka Origin osoby żądającej lub umieszczanie na białej liście źródła „null” — może umożliwić złośliwym witrynom wydobywanie prywatnych danych użytkowników.

CWE-942

Wpływ

Osoba atakująca może ukraść wrażliwe, uwierzytelnione dane od użytkowników podatnej aplikacji [S2]. Jeśli użytkownik odwiedzi złośliwą witrynę internetową po zalogowaniu się do podatnej na ataki aplikacji, złośliwa witryna może wysyłać żądania pochodzące z różnych źródeł do API aplikacji i czytać odpowiedzi [S1][S2]. Może to prowadzić do kradzieży prywatnych informacji, w tym profili użytkowników, tokenów CSRF lub prywatnych wiadomości [S2].

Główna przyczyna

CORS to mechanizm oparty na nagłówku HTTP, który pozwala serwerom określić, które źródła (domena, schemat lub port) mogą ładować zasoby [S1]. Luki zwykle pojawiają się, gdy polityka CORS serwera jest zbyt elastyczna lub źle zaimplementowana. [S2]:

  • Odzwierciedlony nagłówek pochodzenia: Niektóre serwery odczytują nagłówek Origin z żądania klienta i wyświetlają go ponownie w nagłówku odpowiedzi Access-Control-Allow-Origin (ACAO) [S2]. Dzięki temu każda witryna internetowa może uzyskać dostęp do zasobu [S2].
  • Źle skonfigurowane symbole wieloznaczne: Chociaż symbol wieloznaczny * umożliwia dowolnemu urządzeniu źródłowemu dostęp do zasobu, nie można go używać w przypadku żądań wymagających poświadczeń (takich jak pliki cookie lub nagłówki autoryzacji) [S3]. Programiści często próbują to ominąć, dynamicznie generując nagłówek ACAO na podstawie żądania [S2].
  • Dodawanie „null” do białej listy: Niektóre aplikacje umieszczają na białej liście źródło null, co może zostać wywołane przez przekierowane żądania lub pliki lokalne, umożliwiając złośliwym witrynom udawanie źródła null w celu uzyskania dostępu [S2][S3].
  • Błędy analizy: Błędy w dopasowywaniu wyrażeń regularnych lub ciągów podczas sprawdzania poprawności nagłówka Origin mogą umożliwić atakującym użycie domen takich jak trusted-domain.com.attacker.com [S2].

Należy pamiętać, że CORS nie chroni przed fałszowaniem żądań między witrynami (CSRF) [S2].

Poprawki betonu

  • Użyj statycznej białej listy: Unikaj dynamicznego generowania nagłówka Access-Control-Allow-Origin z nagłówka Origin żądania [S2]. Zamiast tego porównaj pochodzenie żądania z zakodowaną na stałe listą zaufanych domen [S3].
  • Unikaj „zerowego” pochodzenia: Nigdy nie umieszczaj null na białej liście dozwolonych źródeł [S2].
  • Ogranicz poświadczenia: Ustawiaj Access-Control-Allow-Credentials: true tylko wtedy, gdy jest to absolutnie konieczne dla konkretnej interakcji między źródłami [S3].
  • Użyj prawidłowej walidacji: Jeśli musisz obsługiwać wiele źródeł, upewnij się, że logika sprawdzania poprawności nagłówka Origin jest solidna i nie może zostać ominięta przez subdomeny lub podobnie wyglądające domeny [S2].

Jak FixVibe to testuje

FixVibe uwzględnia to teraz jako aktywną kontrolę bramkową. Po weryfikacji domeny active.cors wysyła żądania API tego samego pochodzenia z syntetycznym pochodzeniem atakującego i przegląda nagłówki odpowiedzi CORS. Raporty odzwierciedlają dowolne pochodzenie, poświadczenie symboli wieloznacznych CORS i szeroko otwarte CORS na niepublicznych punktach końcowych API, unikając jednocześnie szumu dotyczącego zasobów publicznych.