2014年10月1日水曜日

Same-Origin Policy Potential Issue of iOS UIWebView

I found same-origin policy potential issue on stringByEvaluatingJavaScriptFromString method of UIWebView. When you use this method at shouldStartLoadWithRequest with http redirect, javascript will be executed on wrong domain.
This is just potential issue. Practically, it is not security issue if developer doesn't made a mistake.

I tested about 100 browsers for iOS on AppStore. I found 3 browsers (and 2 branches of them) are vulnerable and I could bypass Same-Origin Policy. I think this is interesting but this is minor issue.

Vulnerable Sample WebView code:
- (BOOL)webView:(UIWebView *)webView
shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
  NSString *prefix = @"javascript:";
  //urlStr includes javascript like "javascript:alert('xss')"
  NSString *urlStr = request.URL.absoluteString;
  if ([urlStr hasPrefix:prefix]) {
    [webView stringByEvaluatingJavaScriptFromString:urlStr];
  }
  return YES;
}
Server side malicious sample code (perl):
#! /usr/local/bin/perl --
print "Location: javascript:alert(document.cookie)\n\n";
Steps to confirm this issue are below:
- Step. 1: Visit site A
- Step. 2: Visit site B
- Step. 3: Site B returns 302 redirect with 'javasctript:xxxx' in Location header
- Step. 4: Execute Javascript of site B

In this case, javascript must be executed on site B but iOS UIWebView execute site B's javascript on site A.
I tested this on google and JavaScript on my web site is executed on "www.google.co.jp" like below:
* This google page is redirect page for search result.

It looks wrong but is by design. :-/
Usually, developers use custom schemes in shouldStartLoadWithRequest. If you want to handle JavaScript in your code, please pay attention to this :-)

0 件のコメント:

コメントを投稿