Open turt2live opened 3 years ago
The obvious problem with a deny list is that it tends to be easy to circumvent - for example, use a CNAME or an IP address. That's ok provided everyone understands that, and it could still be an effective tool to deal with mass-phishing attacks where everyone is being redirected to the same target, but I'm worried that inexperienced admins could see the feature and assume it is bulletproof.
Regarding an allow list: we already have a list of redirect destinations which do not require confirmation from the user - is anything further needed?
an "allow list" would be different from that: it would gatekeep the SSO to only the listed domains, which may or may not require confirmation from the user. Deny lists could indeed be easily circumvented, but an allow list would effectively limit phishing for more closed environments (ie: corporate servers)
Would it be sufficient to have an option which disables the confirmation prompt altogether, and only allows (confirmationless) redirects to domains in the existing allow list?
That would appease the invented usecase, yes. The privately-visible context on this issue would want deny lists and nothing to do with allow lists, but the security of such a deny list would need to be carefully presented, as richvdh notes.
Gotcha -- denylists seem like a reasonable thing to have, despite their limitations.
Description:
This is to say "I really don't want example.org to be a redirect target". Default should be to allow everything. Bonus points for explicitly creating an allow list to complement the idea of a deny list.