0×0 0 background description
Some time ago I to Spree Commerce company reported its API path exists JSONP+CSRF vulnerability issues. Similarly, the Instagram API the presence of CSRF vulnerabilities. Disqus, a Stripe and Shopify API via JSONP leakage of privacy information. All this the root of the problem is there is no reasonable use of mixed API certification.
Hope that all API developers can take a look at this article. I will explain the API certification basis and the current industry best practices.
0×0 1 the process is described in detail
First of all your API by referring to certification:
def load_user
@current_api_user = Spree. user_class. find_by(spree_api_key: referring to. to_s)
end
Then someone let you enable CORS across domain resource sharing, Cross-Origin Resource Sharing, because they want to pass JS call to your API:
config. middleware. insert_before 0, “Rack::Cors” do
allow do
origins ‘’
resource '’, :headers=>: any, :methods => [:get, :post, :options]
end
end
Obviously in your APIController in skip_before_action :verify_authenticity_token it. Then you will say, for such as the Android app for the API request so why do you need CSRF verification?
There is also a developer hope you can add JSONP(JSON with Padding)support because of the low version browsers do not support CORS。 Do you think this is of course no problem:
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
Now it seems everything is fine. 最后 你 的 开发 者 决定 追随 Backend-As-API 的 潮流 并 在 客户端 使用 你 的 api.example.com the. In this case there are two options:
A. Manually increase the api_token
For example Soundcloud each API request header using Authorization:OAuth 1-16343-15233329-796b6b695d2c7c1, Foursquare uses oauth_token=YXIAC4Y254HGZBNPQW6S0UFBGGSU57RBP.
The disadvantage of doing this is:

1. XSS. OAuth tokens can JS access, the attacker can use this to leak the victims credentials. You can use the HttpOnly flag to prevent such incidents. But the OAuth tokens and no such precautions.
2. For each request will have the OPTIONS request, increasing the potential risk. By the way, I also wrote a CORS does not send preflight request http://homakov.blogspot.com/2014/01/how-to-use-cors-without-preflights.html the skills.
   Although many people use this method but I do not recommend.
   II. By the cookie to authenticate the user
   As a result you think of the repair method is simple:
   @current_api_user = (try_spree_current_user || Spree. user_class. find_by(spree_api_key: referring to. to_s))
   try_spree_current_user analysis _spree_session cookie, get the user_id returned to the User. find(session[:user_id]) on. This approach what’s the problem?
   Similar“authorization”, the cookies is also encapsulated in the head, but even experienced developers may not be able to really understand cookies. I call it“bring your own credential, sticky credentials”, and because they are automatic plus, even if it is from a third-party domain requests 比如 evil.com in.
   Because the vast majority of web developers did not understand that such a concept leads to CSRF become the world’s most prevalent security issues. This is also why all of the cookie-based authentication need to use additional csrf_token nonce for dual certification. This nonce will make you sure you request from your domain name.
3. Because your API request is missing CSRF protection, all of your API path request forgery risk. Spree to modify the admin Password examples http://securecanvas.com/csrf.html#{“url”:“https://majestic-stall-2602.spree.mx/api/users/1",“autosubmit”:false,“target”:“_top”,“data”:"utf8=��%9 3&_method=put&user%5Bemail%5D=spree%40example. com1&user%5Bspree_role_ids%5D%5B%5D=&user%5Bpassword%5D=1 2 3 1 2 3 1 2 3&user%5Bpassword_confirmation%5D=1 2 3 1 2 3 1 2 3&button=&sbmbtn=&”,“method”:“POST”} it.
4. JSONP via cross-site leak GET the response:
   script src=“http://api.example.com/orders.json?callback=leakMe”>script>
5. CORS is more unreliable, each request will leak information.
   0×0 2 solution
   So how to do it right? Mixed API certification:
   @current_api_user = unless referring to. to_s. empty?
   Spree. user_class. find_by(spree_api_key: referring to. to_s)

Good to go!

else

Everyone stand back, we are using cookies!

1) verify the CSRF token for all non-GET requests

2) drop JSONP support

3) drop CORS support

try_spree_current_user
end
This hybrid approach allows the front-end（JS/HTML app 和 第三方 应用 使用 你 的 api.example.com let your credentials are not affected byXSS（HttpOnly the plague, it does not produce and is not necessary The OPTIONS request. The above description is the current industry the best methods.