Amirreza Nasiri
2017-01-04 08:44:27 UTC
Pracuję nad aplikacjami internetowymi i jak wiesz, posiadanie panelu administratora jest w większości przypadków koniecznością. Widzimy, że wiele aplikacji internetowych ma określoną stronę logowania dla administratorów, w której znajduje się formularz (zwykle metoda POST ), którego administratorzy mogą używać do logowania się do panelu.
Ale ponieważ nazwy pól są znane, haker może próbować złamać hasła, nawet jeśli zaimplementowano pewne metody bezpieczeństwa.
Więc jaki jest problem z prostym kluczem GET (jak nazwa użytkownika) i jego wartość (jako hasło)? Dlaczego nie jest używany często lub przynajmniej nie jest zalecany w wielu artykułach?
Dla administratorów przyjazne dla użytkownika strony logowania nie są tak naprawdę potrzebne! Dane zostaną zarejestrowane w obu przypadkach ( GET / POST ), jeśli istnieje atakujący MiTM.
Ale używając tej metody, pola będą nieznane. dla samych administratorów. Oto przykładowy kod PHP:
"category.php": (bezsensowna nazwa strony)
<? Phpif (isset ($ _ GET ['sensless_user']) && $ _GET ['sensless_word'] == "coś") {session_start (); $ _SESSION ["user"] = "test"; nagłówek („Lokalizacja: category.php”); // Przekieruj na tę samą lub inną stronę, aby parametry GET zniknęły z adresu URL} else {die (); // Więc to będzie jak pusta strona}? >
Powinieneś używać HTTPS, wtedy nie musisz się martwić o MITM.Dodatkowo, jeśli nie zależy Ci na łatwości obsługi, możesz zaimplementować uwierzytelnianie HTTP Basic lub za pomocą certyfikatu klienta, wtedy nie musisz implementować uwierzytelniania w samej aplikacji internetowej.
Dzienniki serwera internetowego i dzienniki proxy, kropka, główne powody, aby POST te informacje, a nie ich POBIERZ.Wszystko, co mówią jdow i tlng05, jest również prawdą, ale dzienniki są najważniejszym elementem „ojej jest” z HTTP (S) GET.
Twój administrator na jakimś forum: „Hej, mam problem z panelem administracyjnym mojej witryny. Możesz go zobaczyć tutaj: http://example.com/category.php?catID=admin&pageNumber=hunter2
„* pola będą nieznane dla samych administratorów *” - nie jestem pewien, co przez to rozumiesz.Czy są generowane dynamicznie?A może sugerujesz „? Moja nazwa_użytkownika = moje hasło”?Dlaczego nie mogłeś zrobić tego samego z POST?
„POST” w porównaniu z „GET” nie jest *** główną *** przeszkodą dla hakerów, ale pomaga.Każda odrobina ... pomaga
Twoim większym problemem jest to, czy używasz HTTPS czy HTTP.Jeśli używasz tylko protokołu HTTP;POST lub GET są równie otwarte dla MITM.Jeśli zabezpieczasz kanał (którym powinieneś być), [GET jest nieco mniej bezpieczny.] (Http://stackoverflow.com/questions/4143196/is-get-data-also-encrypted-in-https)
_Ale ze względu na znane nazwy pól haker może próbować złamać hasła, nawet jeśli zaimplementowano pewne metody zabezpieczeń_ - To samo dotyczy konwencjonalnego żądania GET.Ale nie ma powodu, dla którego nie możesz używać dynamicznie generowanych nazw pól.przechowywanie wyszukiwania, które jest tym na serwerze.Nie zwiększa znacząco bezpieczeństwa, ale utrudni hakerom życie.
Żądania GET są również przechowywane w HISTORII w przeglądarce internetowej - to łatwy cel dla prawie każdego, kto zdoła uzyskać dostęp do komputera nawet na 15-20 sekund.
A umieszczenie nazwy użytkownika i hasła w żądaniu GET może sprawić, że będą one widoczne na pasku adresu przeglądarki, w zależności od długości adresu URL, co może stanowić problem, jeśli ktoś był wystarczająco blisko, aby zobaczyć Twój ekran.
Dlaczego nie skorzystać z metody autoryzacji, którą już mamy w adresach URL?`https: // użytkownik: pass@example.com /`.W ten sposób możesz utworzyć link do czegoś, co wymaga uwierzytelnienia, ale w rzeczywistości proces uwierzytelniania odbywa się za pośrednictwem nagłówków żądań i zazwyczaj nie pojawia się w dzienniku.
`nazwy pól są znane`: nie ma to znaczenia, chyba że używasz słabych haseł.`Administratorzy nie potrzebują łatwego logowania`: Następnie wystarczy ustawić uwierzytelnianie przez serwer WWW (np. apache).Możesz użyć uwierzytelniania podstawowego i przechowywać hasła w przeglądarce (przy użyciu klucza głównego) lub zainstalować certyfikaty klienta w przeglądarkach (hasła nie są potrzebne).Tak czy inaczej, jest to znacznie bezpieczniejsze niż użycie GET.
Jeśli zależy Ci na specyfikacjach, specyfikacja http zdecydowanie zaleca, aby zmienne GET były używane tylko do pobierania, a nie do modyfikowania stanu aplikacji.Oprócz względów bezpieczeństwa, które za tym stoją, _ może_ być czynnikiem, jeśli twój kod musi być certyfikowany zgodnie z jakąś rzeczą ISO lub tym podobną, która wymaga zgodności z normami.
GET jest wysoce podatny na [fałszerstwo żądań między witrynami] (https://en.wikipedia.org/wiki/Cross-site_request_forgery), np.za pomocą obrazów.Chociaż nie jest dla mnie oczywiste, w jaki sposób ktoś może to wykorzystać, najlepiej unikać wszelkich działań, które powodują wynik na serwerze (w tym przypadku logowanie) za pośrednictwem GET.Brak wiedzy, w jaki sposób coś może być wektorem ataku, nie oznacza, że nim nie jest.Unikaj problematycznych podejść, które są sprzeczne ze specyfikacją RFC.