Jakie są wektory ataku dla haseł wysyłanych przez http?


10

Usiłuję przekonać klienta do zapłaty za SSL dla strony internetowej wymagającej logowania. Chcę się upewnić, że poprawnie rozumiem główne scenariusze, w których ktoś może zobaczyć wysyłane hasła.

Rozumiem, że przy każdym przeskokach po drodze można użyć analizatora pakietów, aby zobaczyć, co jest wysyłane. Wydaje się, że wymaga to, aby haker (lub jego złośliwe oprogramowanie / botnet) znajdował się w tej samej podsieci, co jeden z przeskoków, których potrzebuje pakiet, aby dotrzeć do miejsca docelowego. Czy to prawda?

Zakładając, że pewien smak tego wymogu podsieci jest prawdziwy, czy muszę się martwić wszystkimi przeskokami, czy tylko pierwszym? Pierwszą, o którą oczywiście mogę się martwić, jeśli są w publicznej sieci Wi-Fi, ponieważ każdy może nasłuchiwać. Czy powinienem się martwić tym, co dzieje się w podsieciach, przez które pakiety będą podróżować poza tym? Nie wiem dużo o ruchu w sieci, ale zakładam, że przepływa on przez centra danych głównych operatorów i nie ma tam wielu soczystych wektorów ataku, ale proszę mnie poprawić, jeśli się mylę.

Czy istnieją inne wektory, o które należy się martwić poza osobą słuchającą z analizatorem pakietów?

Jestem sieciowym i bezpiecznym noobem, więc proszę o prostą postawę, jeśli używam niewłaściwej terminologii.


jeśli witryna zawiera dane bankowe lub finansowe, dane osobowe, wówczas warunkiem wstępnym logowania jest protokół SSL. Jeśli da się go łatwo zhakować, tak będzie.
Mitch Wheat

2
Nie widzę powodu, aby to zamykać. Jest to związane z programowaniem.

Każdy, kto odwiedzi tę stronę ze wspólnego punktu dostępu, otrzyma swoje kredyty, nawet jeśli AP używa samego szyfrowania (ponieważ każdy tam też ma klucz). Jeśli ludzie ponownie wykorzystają swoje kredyty na innych stronach, to jest problem.
Aaron

Odpowiedzi:


3

Należy zauważyć, że inni nie wspomnieli tutaj, że niektóre przeglądarki buforują dane formularza. Domyślnym zachowaniem w witrynach SSL jest zazwyczaj nie buforowanie niczego, chyba że wybrano opcję „zapisz moje hasło”. Zazwyczaj pola haseł i tak nie buforują, ale widziałem pewne dziwactwa (zwykle informacje o karcie kredytowej, które, jak wiem, tak naprawdę nie są tematem pytania).

Inną rzeczą do odnotowania jest to, że szyfrowanie SSL zaczyna się od uzgadniania TCP. W SSL nie można odróżnić HTTP przez SSL od FTP przez SSL (oprócz założeń dokonanych za pomocą numeru portu).

Nie można również odróżnić żądania logowania od żądania „Po prostu przeglądam”, to zaciemnia przepływ stron od potencjalnych hakerów, a także zapewnia bezpieczeństwo nie tylko danych hasła, ale historii przeglądania / danych cookie / i wszelkich dane osobowe, które pasują do twojego konta.

Podsumowując, jeśli wyeliminujesz ataki typu man-in-the-middle ze spektrum, ograniczysz wiele potencjalnych ataków, nie oznacza to jednak, że Twoja witryna jest „bezpieczna”. Również zasady podziału na strefy powinny chronić cię przed atakami XSS, ponieważ zmienisz strefę, jeśli użytkownik zostanie przekierowany z Twojej witryny.


„założenia przyjęte przez numer portu”? Czy port nie byłby zwykle 443 dla SSL (HTTP lub FTP)?
brickner

4

Dane są wrażliwe w dowolnym miejscu na trasie, nie tylko na pierwszym lub ostatnim etapie. Można sobie wyobrazić, że system zaangażowany w transfer wyszukuje nazwy użytkowników, hasła i inne poufne dane. Wynika z tego, że wrażliwe dane powinny być przesyłane tylko przez łącze, które jest zabezpieczone do końca i oczywiście do tego właśnie służy SSL. W zależności od tego, jakie dane są zaangażowane, mogą obowiązywać lokalne przepisy regulujące SSL.


Czy może przechodzić przez podsieci, do których mają dostęp konsumenci, czy może po prostu przechodzi przez kręgosłup głównych przewoźników, w którym to przypadku musielibyśmy założyć, że haker złamał, powiedzmy, że centrum operacyjne poziomu 3 (tylko na przykład)?
KevinM

Zwykle nie spodziewałbym się, że będzie podróżował przez sieci konsumenckie, ale należy pamiętać, że każdy system może być zagrożony. Chociaż powinniśmy być w stanie oczekiwać, że dostawcy usług internetowych i systemy operatorów będą bardziej bezpieczne, wiemy również, że wielu z nich zostało w przeszłości zagrożonych. Żaden system ani sieć nie jest odporna na ataki hakerskie, stąd potrzeba takich rzeczy jak SSL. Może to być nawet pracownik ISP, który zbiera informacje podróżujące przez sieć. Wystarczy pasywne dotknięcie.
John Gardeniers

1
Może to być również twoja ulubiona agencja rządowa, która instaluje kurki z pomocą twojego dostawcy usług internetowych ... Jeśli uważasz, że atak zależy od ciebie.
pehrs

2

Istnieją serwery proxy, które mogą przechowywać dane.

Ale istnieje również obowiązek zapewnienia bezpieczeństwa haseł użytkowników. Wielu użytkowników używa ograniczonego zestawu haseł, więc niebezpieczna witryna może na przykład naruszyć hasło do banku domowego.


1
Tak, twój drugi punkt jest ważny. Uważam, że strony internetowe nie powinny zachowywać się tak, jakby stanowiły centrum świata użytkowników.

1

Twoja analiza jest rozsądna, IMHO.

Przypuszczam, że należy zauważyć, że na twojej drodze mogą znajdować się skrzynki. Może się zdarzyć, że żądanie zostanie gdzieś zarejestrowane (zwłaszcza jeśli logowanie zakończyło się GET, co byłoby straszne).

Prawdopodobnie należy wziąć pod uwagę, że większość dostępu do sieci ma miejsce w obszarze, w którym wiele innych osób jest w tej samej sieci. Praca / Uni / Szkoła są głównymi przykładami. W domu można argumentować, że jest to mniej ryzykowne, ponieważ trzeba się martwić tylko o ścieżki w górę.

Ale tak naprawdę nie ma tutaj pytania. Podczas logowania używasz protokołu SSL. Prawdopodobnie najbardziej przekonującym argumentem dla faceta będzie to, że sprawia, że ​​twoja strona wydaje się bardziej godna zaufania, ponieważ - idealnie - ogół społeczeństwa nigdy nie zaloguje się na stronie, która nie ma ekranu logowania opartego na SSL .

Ale bądźmy realistami. Niemal na pewno ten wektor ataku nie stanowi zagrożenia dla jego systemu lub użytkowników.

HTH.


1

Mogę zgodzić się z przemyśleniami KevinM dotyczącymi odpowiedzi na jego własne pytania, a John Gardeniers wskazuje właściwy kierunek. Muszę także zgodzić się z tym, co powiedział jedwabiście, „idealnie - ogół społeczeństwa nigdy nie zaloguje się na stronie, która nie ma ekranu logowania opartego na SSL”, i zwróci uwagę, że nie jest to jednak współczesny przypadek w ogóle.

Nie zgadzam się z jedwabistym tonem (prawdopodobnie niezamierzonym), który prowadzi do wszechobecnego postrzegania, że ​​„ogół społeczeństwa” jest głupi. Klient KevinM najwyraźniej nie ma pojęcia o potrzebie SSL, a to jest Twoja przeciętna osoba w pigułce. Nie są głupi, po prostu nie wiedzą. Powiedzieć „potrzebujesz tego”, niedozwolona jest odpowiedź: „Przeżyłem x lat bez tego, a ja będę żył x bardziej dobrze”, a może nawet gorzej, „Nienawidzę, gdy mówiono mi, czego potrzebuję . ” Więc uważaj!

Twoje obawy są uzasadnione, Kevin. Twój klient potrzebuje certyfikatu SSL. Myślę, że twoją prawdziwą troską powinno być to, jak je sprzedać. Należy się martwić nie tylko logowaniem użytkownika, ale logowaniem administratora i operatora, który również skorzysta na ochronie przez SSL.

Tak, w tym względzie należy martwić się o wiele bardziej niż podsłuchiwanie pakietów, takie jak XSS . Są liczne i dobrze udokumentowane .


Dzięki Daniel. Uważam, że ważne jest nie tylko stosowanie arbitralnych reguł, ale także zrozumienie, co stanowi podstawę naszych zasad. Chciałem więc upewnić się, że mogę to wyartykułować. Na szczęście udało mi się przekonać klienta do uzyskania protokołu SSL!
KevinM

0

w całej trasie, po której następuje pakiet, jeśli można go obwąchać przez HTTP, a dane można zobaczyć ... nawet jeśli używasz HTTP w Proxy, takich jak TOR ... używając ataku przechwytującego itp. można oszukać Proxy, aby wyciekł z pakietów danych ... więc jeśli jest coś wrażliwego (hasła, dane osobowe, prywatne obrazy itp.) ... nadaje się tylko do przesyłania ich przez HTTPS.

To także, nawet HTTPS jest podatny na błędną implementację, a do tego stosuje się kilka ataków SSL ... wciąż można ich uniknąć dzięki starannej implementacji.

Ale używanie HTTP do zwykłego tekstu jest jak zapraszanie nawet nowicjuszy, dzieciaki, do węszenia haseł.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.