转载

为什么说你的API并不安全？

0×00 背景介绍

前段时间我向Spree Commerce公司报告了其所有API路径存在 JSONP+CSRF漏洞 的问题。同样，Instagram的API存在 CSRF漏洞 。Disqus、Stripe和Shopify的API通过 JSONP泄露隐私信息 。这一切问题的根源都是没有合理使用混合API认证。

希望所有API开发者都能看一看这篇文章。我将解释API认证的基础和目前业内最好的做法。

0×01 过程详述

首先你的API通过api_key来进行认证：

def load_user   @current_api_user = Spree.user_class.find_by(spree_api_key: api_key.to_s) end

这时有人让你启用CORS（跨域资源共享，Cross-Origin Resource Sharing），因为他们想通过JS调用你的API：

config.middleware.insert_before 0, "Rack::Cors" do       allow do             origins '*'             resource '*', :headers => :any, :methods => [:get, :post, :options]       end end

显然在你的APIController中有skip_before_action :verify_authenticity_token 。那么你会说对于来自比如Android app的API请求为什么还需要CSRF验证呢？

还有一位开发者希望你能加上JSONP(JSON with Padding)的支持因为低版本浏览器不支持CORS。你觉得这当然没问题：

after_filter  :set_jsonp_format def set_jsonp_format      if params[:callback] && request.get?            self.response_body = "#{params[:callback]}(#{response.body})"            headers["Content-Type"] = 'application/javascript'      end end

目前看来一切都没什么问题。最后你的开发者决定追随Backend-As-API的潮流并在客户端使用你的api.example.com。这时有两种选择：

一. 手动增加api_token

比如说Soundcloud的每个API请求头部使用Authorization:OAuth 1-16343-15233329-796b6b695d2c7c1，Foursquare使用oauth_token=YXIAC4Y254HGZBNPQW6S0UFBGGSU57RBP.

这样做的缺点：

1.XSS。OAuth tokens可通过JS访问，攻击者可借此泄露受害者凭证。可以使用HttpOnly flag来防止此类事件发生。但OAuth tokens并没有此类预防措施。

2.对于每个请求都会有OPTIONS请求，增加了潜在风险。对了我还写了一篇 CORS不发送预检请求（http://homakov.blogspot.com/2014/01/how-to-use-cors-without-preflights.html）的技巧。

尽管很多人使用这样的方法但我并不推荐。

二. 通过cookie认证用户

这样一来你想到修复方法很简单：

@current_api_user = (try_spree_current_user || Spree.user_class.find_by(spree_api_key: api_key.to_s))

try_spree_current_user 解析 _spree_session cookie, 得到user_id返回User.find(session[:user_id])。那么这种做法有什么问题呢？

类似“授权（Authorization）”，cookie也是封装在头部，但即使是经验丰富的开发也不一定能真正理解cookie。我称其为“自带凭证（sticky credentials）”，因为它们是自动加上的，即使是来自第三方域的请求（比如evil.com）。

因为绝大多数web开发者并没有理解到这样的概念导致CSRF成为全球最普遍的安全问题。这也是为什么所有基于cookie的认证都需要用额外的csrf_token nonce进行双重认证。这个nonce能使你确定请求来自你的域名。

1.因为你的API请求漏掉了CSRF保护，所有你的API路径都有请求伪造的风险。Spree的修改admin密码的例子（http://securecanvas.com/csrf.html#{"url":"https://majestic-stall-2602.spree.mx/api/users/1","autosubmit":false,"target":"_top","data":"utf8=%E2%9C%93&_method=put&user%5Bemail%5D=spree%40example.com1&user%5Bspree_role_ids%5D%5B%5D=&user%5Bpassword%5D=123123123&user%5Bpassword_confirmation%5D=123123123&button=&sbmbtn=&","method":"POST"}）。

2.JSONP通过跨站泄露GET响应：

<script src="http://api.example.com/orders.json?callback=leakMe"></script>

3.CORS就更不可靠了，每种请求都会泄露信息。

0×02 解决方案

那么怎么做才对？混合API认证：

@current_api_user = unless api_key.to_s.empty?   Spree.user_class.find_by(spree_api_key: api_key.to_s)   # Good to go! else   # Everyone stand back, we are using cookies!   # 1) verify CSRF token for all non-GET requests   # 2) drop JSONP support   # 3) drop CORS support   try_spree_current_user end

这种混合的方法允许前端（JS/HTML app）和第三方应用使用你的api.example.com，让你的凭证不受XSS（HttpOnly）的困扰，也不会产生并无必要的OPTIONS请求。上述介绍的就是目前业内的最好方法。

*原文地址； sakurity ，编译/florence，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）

正文到此结束