Hej, tak się zastanawiam, czy wysłanie tokenu w url przekierowania jest bezpieczne? I czemu nie? Przykład:
window.location.replace("http://somewebsite.com/somepage?user=username;token=jffnjn34nmnsdwo59xc2dk;param=634");
0
1
Token jest jak hasło, zatem nie jest to raczej zalecane.
OWASP ma w swoich guidlinesach:
Sensitive information in HTTP requests
RESTful web services should be careful to prevent leaking credentials. Passwords, security tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.
- In POST/PUT requests sensitive data should be transferred in the request body or request headers.
- In GET requests sensitive data should be transferred in an HTTP Header.
OK:
https://example.com/resourceCollection/[ID]/action
https://twitter.com/vanderaj/lists
NOT OK:
https://example.com/controller/123/action?apiKey=a53f435643de32 because API Key is into the URL.
0
WeiXiao napisał(a):
Co w ogóle chcesz zrobić? "wlogować" użytkownika na innej stronie?
Chcę rozwiązać ten problem. Z braku innych rozwiązań wymyśliłem, że z widok HTML który odbiera wynik, parsuje z message i wysyła do otwartego okna mogę w JS otworzyć stronę z Angular, przekazując jej w URL załączone parametry (w tym tokenami), routing je ładnie przyjmie, i mieć właściwą domenę w oknie zanim wywołam postMessage.
Zastanawiam się jedynie, jaka jest szansa przechwycenia tokena z zewnątrz.
1
A gdyby wykonać redirect z postem np. poprzez formularz? wtedy będziemy mieli to w body.
<form action="http://someotherserver.com" method="post">
Jednak zaznaczam, że nie mam pewności co do poprawności takiego rozwiązania.
0
Próbowałem różnych podejść z localStorage, skończywszy na window.opener.localStorage.setItem(). Wszystko się rozbiło o błąd
Uncaught DOMException: Permission denied to access property "localStorage" on cross-origin object
Jak @WeiXiao sugerował, są też ciasteczka. Ale ostatecznie zdecydowałem się powrócić do mojego oryginalnego pomysłu z Wysłaniem tokenu w url przekierowania. Po chwili grzebania na Security Stackexchange trafiłem na to: https://security.stackexchange.com/q/120583
Wydaje mi się, że faktycznie, jeśli token się przedawnia szybko, a refresh token jest weryfikowany wraz z IP nadawcy żądania, oba są szyfrowane, to mogą one wisieć w historii przeglądarki i serwerach całego świata bez żadnych konsekwencji.