为什么说你的API并不安全？
2015-12-04 开发者
开发者（KaiFaX）
面向开发者、程序员的专业平台！
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）
原文：http://www.freebuf.com/articles/security-management/87522.html
转载文章，向原作者致敬！如有侵权或不周之处，敬请劳烦联系若飞（微信：13511421494）马上删除，谢谢！
1. 回复“m”可以查看历史记录；
2. 回复“h”或者“帮助”，查看帮助；
开发者已开通多个微信群交流学习，请加若飞微信：13511421494 进群
开发者：KaiFaX面向开发者、程序员的专业平台！
微信扫一扫
关注该公众号