Awaria magicznego łącza może nastąpić po pomyślnym dostarczeniu poczty. Wiadomość może dotrzeć po wygaśnięciu, aplikacja może unieważnić wcześniejszy link lub przekierowanie może wylądować w niewłaściwym środowisku. Zbadaj je jako odrębne hipotezy, zamiast traktować każde nieudane logowanie jako problem z rekordem uwierzytelniania.
Prześledź obie podróże
Podróż pocztowa przebiega od żądania, poprzez generowanie, kolejkowanie i akceptację serwera odbierającego. Podróż aplikacji przebiega od utworzenia tokena, poprzez żądanie połączenia, sprawdzenie poprawności i ustanowienie sesji. Dołącz do nich, korzystając z nietajnego identyfikatora korelacji. Nie rejestruj kompletnych linków do nośników ani nie wklejaj aktywnego linku do zewnętrznego skanera.
Zdarzenie akceptacji SMTP stanowi dowód odpowiedzialności za transfer, a nie zakończonej sesji użytkownika. Zachowaj dokładność etykiet pomocniczych. RFC 5321. Wyraźnie zarejestruj brakującą widoczność, gdy dostawca udostępnia jedynie status przesłania i statusu końcowego.
Wskazówki dotyczące rejestrowania OWASP obsługuje korelację bez ujawniania tajemnic dostępu.
Sprawdź osobno projekt łącza
Zasady bezpieczeństwa zawarte w wytycznych dotyczących resetowania hasła OWASP obejmują jednorazowe, wygasające tokeny, zaufane miejsca docelowe HTTPS i ochronę przed wyciekiem tokenów. Zasady te mają zastosowanie do przeglądania wrażliwych linków wysyłanych pocztą elektroniczną, ale źródło dotyczy resetowania hasła, a nie pełnej specyfikacji logowania bez hasła. Produkt magic-link potrzebuje własnego modelu zagrożeń i kontroli sesji. Wskazówki dotyczące tokena resetowania OWASP.
Sprawdź zamierzone zachowanie hosta, środowiska, ścieżki i przekierowania, korzystając z jednorazowych poświadczeń testowych w zatwierdzonym środowisku testowym. Potwierdź, czy nowsze żądanie unieważnia poprzednie linki i czy pomyślne użycie unieważnia token. Zapisz faktyczną politykę, zamiast zakładać, że wszystkie produkty zachowują się identycznie.
Porównaj awarię wygaśnięcia i awarię zużycia
Rozważmy dwa hipotetyczne tokeny utworzone o godzinie 09:00 UTC i wygasające o godzinie 09:10. Przypadek A zostaje zaakceptowany przez odbiorcę o godzinie 09:11, już minutę po upływie terminu ważności. Przypadek B osiąga ten etap o godzinie 09:01, ma pomyślną realizację wniosku zarejestrowaną o godzinie 09:02 i otrzymuje drugą próbę o godzinie 09:03. Zgodnie z polityką jednorazowego użytku druga próba B powinna zakończyć się niepowodzeniem, ponieważ została już wykorzystana, mimo że pozostało siedem minut.
Są to wymyślone założenia dotyczące zdarzeń, a nie wykonanie maszyny stanowej lub zweryfikowane incydenty. Przypadek A sugeruje przeprowadzenie dochodzenia w odpowiednim czasie; przypadek B wymaga dowodu wcześniejszego przejścia aplikacji. Krótsze opóźnienie poczty nie sprawi, że B będzie nadawał się do ponownego użycia. Nie przypisuj wcześniejszej akcji do skanera bezpieczeństwa lub osoby wyłącznie na podstawie ciągu agenta użytkownika. Koreluj autoryzowane, zredagowane rekordy żądań, zmiany stanu i zdarzenia sesji przed przypisaniem aktora.
Napraw bez konieczności ponownego użycia linków
W przypadku rzeczywistego opóźnienia zajmij się wolnym etapem i sprawdź pozostały budżet ważności. W przypadku przedwczesnego użycia sprawdź, czy aplikacja może oddzielić nieszkodliwe żądanie lądowania od jawnej, bezpiecznie zweryfikowanej akcji ustanawiającej sesję. To jest recenzja projektu, a nie łatka uniwersalna; zachować zapobieganie powtórkom, wygaśnięcie i inne wymagane kontrole.
Usuń niepotrzebne śledzenie marketingowe z wrażliwych linków do kont poprzez zatwierdzoną konfigurację szablonu i zweryfikuj ostateczną wiadomość. Wszelkie zachowania związane z przekierowaniami lub precyzyjnymi linkami mobilnymi nadal wymagają przetestowania. Nigdy nie rozwiązuj sporadycznych awarii, akceptując wygasłe tokeny na czas nieokreślony.
Przetestuj ponownie kontrolowane podróże pod kątem opóźnienia przybycia, powtarzających się żądań, powtórek i trasowania w niewłaściwym środowisku. Zamknij, podając dokładną klasę zniszczenia i pozostałe luki. Jasna klasyfikacja zapobiega wielokrotnej zmianie niewłaściwego systemu przez operatorów poczty i inżynierów aplikacji.
Wymagaj osobnego zamknięcia dla każdej klasy awarii
Szybszy przyjazd może zamknąć sprawę opóźnienia ważności dopiero wtedy, gdy kontrolowana podróż potwierdzi budżet ważności. Nie może zamknąć sprawy dotyczącej wcześniejszej konsumpcji lub złego środowiska. Nagraj zajęcia, wspierając przejście aplikacji i brakujące dowody przed przypisaniem przyczyny.