2016-06-01 15 views
10

Co dowiedziałem się od Foregenix:Jak sprawdzić, czy rzeczywiście jest to strona 404?

HTTP 404 Not Found Błąd oznacza, że ​​strona starasz się dotrzeć nie można znaleźć na serwerze. Jest to błąd po stronie klienta, który oznacza, że ​​strona została usunięta lub przeniesiona, a adres URL nie został odpowiednio zmieniony lub nieprawidłowo wpisany adres URL:

Ale robię też pentesty aplikacji internetowych w Pythonie i zastanawiam się, że jeśli sprawdzę tylko ciąg 404 na stronie, może to nie być błąd w postaci 404. Może się zdarzyć, że strona istnieje, ale nagłówek to 404 tylko po to, aby nas oszukać.

Więc jak dokładnie się dowiem?

+40

Kody stanu HTTP, takie jak 404, można uzyskać w bardziej wiarygodny sposób, patrząc na odpowiedź HTTP. Na przykład, zobacz http://www.tcpipguide.com/free/t_HTTPResponseMessageFormat.htm –

+8

@ A.Darwin Chciałbym przepisać nieco komentarz i opublikować jako odpowiedź – Purefan

+0

Cytując niektóre strony, proszę podać bezpośredni link do masz cytat z. Dziękuję Ci! – Anders

Odpowiedz

55

Można sprawdzić kod stanu HTTP i sprawdzić, czy jest to 404, czy nie. Kod stanu znajduje się na pierwszej linii odpowiedzi:

HTTP/1.1 404 Not Found 

Jeśli używasz HTTPlib można tylko odczytać właściwość obiektu HTTPResponsestatus.

Jednak to serwer decyduje, jaki kod statusu HTTP wysłać. To, że 404 definiuje się jako "strona nie znaleziona", nie oznacza, że ​​serwer nie może cię okłamać. Często zdarza się tak:

  • Wyślij 404 zamiast 403, aby ukryć zasób wymagający uwierzytelnienia.
  • Wyślij 404 zamiast 500, aby ukryć fakt, że coś nie działa.
  • Wyślij 404, gdy Twój adres IP jest zablokowany z jakiegoś powodu.

Bez dostępu do serwera nie można dowiedzieć się, co naprawdę dzieje się za zasłonami.

+9

Niektóre witryny zupełnie zmieniają kod statusu. Mogą wyświetlać 404, ale zwracają 200 (jak podano). Jeśli znajdziesz stronę, do której należysz, powinieneś się z nią skontaktować i powiadomić o tym, szczególnie jeśli używasz punktu końcowego interfejsu API. – coteyr

+1

czasami aplikacje używają statusu innego niż 404, więc wywołania ajax nadal prowadzą przez 'success' handler, zwykle gdy nie kodują handler'a' catch/onerror'. – dandavis

+0

@coteyr I spotkałem wiele witryn, które biorą 404 i albo po prostu zwracają stronę główną lub biorą segmenty adresów URL jako wyszukiwania na swojej stronie i zwracają stronę wyników wyszukiwania. (W rzeczywistości rozsądny tok postępowania, jeśli używają opisowych adresów URL - takie wyszukiwanie czasami znajdzie nowy dom brakującej strony.) –

9

Masz rację: ktoś może napisać "Nie znaleziono strony 404" na stronie HTML i sprawi, że myślisz, że strona nie istnieje.

Aby poprawnie rozpoznać kody statusu HTTP, takie jak 404, należy przechwycić odpowiedź HTTP za pomocą Pythona i przeanalizować. Standardy HTTP 1 i HTTP 2 określają, że odpowiedź HTTP, zapisana w ogólnym formacie komunikatów HTTP, musi zawierać kod statusu.

Przykład odpowiedzi HTTP (od Tutorials Point):

HTTP/1.1 404 Not Found 
Date: Sun, 18 Oct 2012 10:36:20 GMT 
Server: Apache/2.2.14 (Win32) 
Content-Length: 230 
Connection: Closed 
Content-Type: text/html; charset=iso-8859-1 

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> 
<html> 
<head> 
<title>404 Not Found</title> 
</head> 
<body> 
    <h1>Not Found</h1> 
    <p>The requested URL /t.html was not found on this server.</p> 
</body> 
</html> 

Należy zdecydowanie nie ufa część HTML, który może pokazać błąd 404 (lub nawet 418 I'm a teapot), gdy strona może w rzeczywistości być znalezione .

+2

Zgadzam się, nie powinieneś ufać HTML, ale czy powinieneś ufać kodowi statusu HTTP? – Anders

+7

@Anders Jeśli strona wysyła ci odpowiedź HTTP zawierającą fałszywy kod statusu, nie wiem, co jeszcze można zrobić, aby sprawdzić, czy strony nie można znaleźć, na krótko sprawdzając ją za pomocą innego adresu IP lub klienta użytkownika jeśli jest to wiadomość ad-hoc. –

+2

@Anders: Powinieneś ufać kodowi statusu. Jeśli witryna jest zepsuta lub umyślnie gra z tobą, nic nie możesz zrobić. Jeśli strona mówi "strona nie ma", to jeśli o nią chodzi, to jej nie ma. – gnasher729

4

Oprócz odpowiedzi Andersa, znalazłem sposób na wykrycie niektórych przypadków, w których 404 jest niewłaściwie używane z atakiem Czas. Jest jednak mało wiarygodny.

  • Wyślij 404 zamiast 403, aby ukryć zasób wymagający uwierzytelnienia.

Często serwery potrzebują więcej czasu, aby określić, że „nie masz pozwolenie, aby uzyskać ten zasób”, ponieważ potrzebują więcej roundtrips do zasobów zewnętrznych, takich jak bazy danych, a następnie muszą ustalić, „to nie jest tam”, dość często nawet cacheable i szybko określić.

Typowym przykładem w aplikacji MVC z RDBS jako backendem jest różnica między prostym SELECT COUNT(id) FROM articles WHERE id=123 LIMIT 1 a znacznie bardziej złożonym SELECT access FROM accesses JOIN articles ON articles.id = accesses.foreign_id WHERE articles.id = 123 AND accesses.type='articles' AND accesses.user_id = (SELECT id FROM users WHERE token='t0k3n' LIMIT 1). A to oznacza, że ​​aplikacja może w pierwszej kolejności tworzyć takie zapytania o pojedynczą linię: częściej jest to dużo "pobierz użytkownika, wyodrębnij dane, teraz pobierz rzecz, zapytaj teraz, jeśli użytkownik może uzyskać do niego dostęp za pośrednictwem autoryzacji" api ".

ile twórcy lub ramy miejscu zadbał aby pokryć tę sprawę dość często zobaczysz zauważalną różnicą w czasie, aby służyć zarówno przypadki 404.

  • Wyślij 404 zamiast 500, aby ukryć fakt, że coś nie działa.

Zazwyczaj awarie lub nieoczekiwane błędy występują tylko po uruchomieniu kodu. Wykrywanie 404 często przychodzi wcześnie: w końcu taniej jest stwierdzić, że czegoś tam nie ma (patrz wyżej). Błąd wystąpiłby później. Oznacza to, że taki błąd 500-ukryty-jak-404, często zajmuje o wiele więcej czasu, niż normalny 404.

  • Wysyłaj 404, gdy Twój adres IP jest zablokowany z jakiegoś powodu.

W tym przypadku czas jest często odwrotny, w zależności od implementacji. Takie blokowanie adresów IP często jest utrzymywane poza aplikacją internetową (CMS itp.), Ponieważ jest znacznie prostsze i wydajniejsze, aby obsługiwać wyżej w stosie: serwer WWW, serwer proxy itp. Jednak, gdy sama aplikacja zajmuje się to, generowanie faktycznego 404 jest często rozsądnie tanie, podczas gdy szukanie adresu IP w bazie danych, stosowanie masek itd. zajmuje trochę czasu. Podobnie jak w przypadku ukrycia 403 jako 404.

+0

To takie niesamowite dzięki koleś –

Powiązane problemy