Skaner niebezpiecznych metod HTTP

Jak działa ta kontrola

Scanaris wysyła żądanie OPTIONS na skanowany adres, nie podążając za przekierowaniami, i odczytuje dwa nagłówki odpowiedzi: Allow, którym serwer deklaruje, jakie metody akceptuje na tej ścieżce, oraz Access-Control-Allow-Methods, ten od CORS. Jeśli w którymkolwiek pojawia się TRACE, TRACK, PUT, DELETE lub CONNECT, otwiera ustalenie o niskiej wadze z listą. To ostrożna kontrola: oznacza tylko to, co serwer jawnie ogłasza. Nigdy nie wysyła testowego PUT ani DELETE, a jeśli serwer nie odpowiada na OPTIONS albo nie zwraca tych nagłówków, nie ma ustalenia.

Dlaczego to ważne

Zwykła strona potrzebuje GET, HEAD, POST i, na potrzeby CORS, OPTIONS. Reszta to metody z historią. TRACE odsyła żądanie dokładnie tak, jak je otrzymał, z nagłówkami; w połączeniu z inną luką pozwala odczytać ciasteczka oznaczone HttpOnly (atak nazywa się Cross-Site Tracing). PUT i DELETE tworzą, zastępują lub usuwają zasoby: na źle skonfigurowanym serwerze plików PUT wgrywa plik do publicznego katalogu. CONNECT zamienia serwer w proxy. To, że są włączone, nie znaczy, że działają bez uwierzytelniania, stąd niska waga; ale ogłaszanie ich bez używania to darmowa powierzchnia ataku.

Jak to naprawić

• Apache: TraceEnable Off w głównej konfiguracji (TRACE jest domyślnie włączony w starych wersjach). Dla reszty, wewnątrz Directory lub Location Twojej strony: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: nie implementuje TRACE. Żeby ograniczyć resztę w bloku location: limit_except GET POST HEAD OPTIONS { deny all; }. Jeśli używasz if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, umieść to na poziomie server.
• IIS: moduł WebDAV to typowa przyczyna ogłaszanych PUT i DELETE. Odinstaluj go, jeśli go nie używasz, a w web.config ogranicz czasowniki przez requestFiltering/verbs.
• Express i API: jeśli Twoje API używa PUT lub DELETE z uwierzytelnianiem, to uzasadnione, że Access-Control-Allow-Methods je wymienia; nie powinno natomiast wymieniać ich dla całej strony ani używać *. W middleware CORS ustaw methods: ['GET', 'POST'] na publicznych ścieżkach i rozszerzaj tylko tam, gdzie trzeba.
• Vercel, Netlify, Cloudflare Pages: domyślnie nie ogłaszają tych metod. Jeśli ustalenie się pojawia, zwykle pochodzi z nagłówka CORS, który sam skonfigurowałeś z pełną listą.

Sprawdź, czy naprawione

curl -si -X OPTIONS https://twojadomena.pl | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://twojadomena.pl | head -1

W pierwszym ani Allow, ani Access-Control-Allow-Methods nie powinny zawierać TRACE, TRACK, PUT, DELETE ani CONNECT na publicznych ścieżkach. Drugie musi zwrócić 405 lub 403, nigdy 200 z Twoim żądaniem odbitym w treści.

Często zadawane pytania

Moje API REST używa PUT i DELETE. Czy muszę je usunąć?

Nie. Liczy się to, żeby te ścieżki wymagały uwierzytelniania i żeby nagłówek CORS nie ogłaszał ich dla całej domeny ani dla dowolnego źródła. Jeśli skan celuje w root Twojego API, możesz oznaczyć ustalenie o niskiej wadze jako zaakceptowane po sprawdzeniu tego. Konfigurację źródeł sprawdza zbyt liberalny CORS.

Access-Control-Allow-Methods wymienia metody, ale nie ma Allow. Czy to to samo?

Nie do końca. Allow opisuje, co serwer akceptuje; nagłówek CORS opisuje, na co pozwala stronom z innych źródeł. Oba są czytane, bo oba to informacja, którą zdradzasz. Co oznacza każda część odpowiedzi CORS, wyjaśnia źle skonfigurowany CORS.

Dlaczego OPTIONS nie jest uznawany za niebezpieczny?

Bo to metoda, którą przeglądarka pyta o CORS przed niektórymi żądaniami. Zablokowanie jej psuje wywołania między domenami. Jest nieszkodliwa i konieczna.