为什么说你的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请求，增加了潜在风险。
尽管很多人使用这样的方法但我并不推荐。
二. 通过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路径都有请求伪造的风险。 2.JSONP通过跨站泄露GET响应。 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）