You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal: prevent redirect.html from being used as an "open redirect", which is generally thought to be a bad idea from a security perspective.
The attack vector is generally to (1) produce a link through digitru.st which routes to malware or some other naughty business; then (2) traffic this link on some high volume UGC site and sucker users into clicking on it. DT suffers a reputation hit as a result.
To protect against this, we want redirect links which are
limited to a single device
time limited
only produced "legitimately"
Here's one way in which we might solve this, however this relies on working storage (cookies, LS or other) within a third party context. Which kind of sucks, so...
within dt.html, when an identity is first generated, also generate a secret and save in a cookie only accessible to .digitru.st
push a time-limited code to the parent iframe (using a hash with the secret)
the redirect links created by js should include the code
redirect.html would check this code against the secret
This redirect link could be at least device- and time-limited. However it relies on working third party cookies before the redirect occurs at all.
Here's another way to solve, however this relies on a dynamic server. So, more deal breakers...
within dt.html host a public key
dt.html uses the public key to encrypt destination url + timestamp + (some attribute of the device)
redirect service uses a private key to decrypt
redirect service denies the redirect if timestamp is stale or the device attributes do not match
The text was updated successfully, but these errors were encountered:
Goal: prevent redirect.html from being used as an "open redirect", which is generally thought to be a bad idea from a security perspective.
The attack vector is generally to (1) produce a link through digitru.st which routes to malware or some other naughty business; then (2) traffic this link on some high volume UGC site and sucker users into clicking on it. DT suffers a reputation hit as a result.
http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html
https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
To protect against this, we want redirect links which are
Here's one way in which we might solve this, however this relies on working storage (cookies, LS or other) within a third party context. Which kind of sucks, so...
This redirect link could be at least device- and time-limited. However it relies on working third party cookies before the redirect occurs at all.
Here's another way to solve, however this relies on a dynamic server. So, more deal breakers...
The text was updated successfully, but these errors were encountered: