记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

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

2015-12-04 20:10

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)

知识来源: www.freebuf.com/articles/security-management/87522.html

阅读:98402 | 评论:0 | 标签:安全管理 API

想收藏或者和大家分享这篇好文章→复制链接地址

“为什么说你的API并不安全?”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云