如果我用在 co子里的会期身份证打造了一架SSL型号的短信,添加一个非像样的参数,并且总是对JSON目标(而不是用警示作答的JSONP型反应)作出反应,那么,它是否总体上是安全的,特别是针对XSRF?

仅凭这种软件设计的用意是,它只可在我自己的领域上页,并且通过本份标书(但不能由其他领域消耗)免费披露私人数据(例如用户名称和电子邮件),并且为小组内的开发商保留合理的简化标准。

Let me at least share what I understand about this approach, and why I think it s secure. Please enlight me if wrong!:

• A <script> tag dropped on a 3rd-party domain to our site would send my cookies, but would not be able to parse the JSON object response (and the response would always deliberately be a JSON object at the top level). Also, I need to make sure that API calls that affect state on the server are all protected by non-GET method access, because <script> tags must use GET and so can not cause havok by attempt to call state-changing calls (in other words, the API would be adherent to REST in so far as HTTP methods go). Also, I deliberately do not support JSONP because it would be a security hole.
• Man-in-the-middle used to hijack cookies (the session) is not a concern because I m using SSL with valid certificates.
• Replay attacks are a temporally limited concern because of the use of a nonce will limit how long one could send in a replay of an HTTPS request, because the server will make sure that the API call is only valid for a small amount of time in a typical nonce-validating way.
• XMLHttpRequest can not make cross-domain calls, so it can t request anything from my site.
• CORS (Cross ORigin Resource Sharing) is not of concern because I don t have a crossdomain.xml file or any other advertisement of cross-domain support associated with HTML 5.
• An iframe in a 3rd-party site doesn t matter because even though it can load my page graphically, the host site can t access any data within that iframe, and because I ve made no attempt to support cross-domain iframe communication (so they can attempt to set # on the iframe URL like folks do to enable communication between cross-domain iframes, but my page won t be responsive to it).

EDIT: A nonce would also protect against even cross-domain GET requests (i.e., <script> tags) as russau says. In thinking on that specifically, I like the idea of asking for a nonce in a POST API call that is not itself nonce protected; it should be the case that only XmlHTTPRequest s on the same domain can then generate a nonce to begin with. This seems to be a simple way of making the generation of nonce s developer-friendly. (i.e., nothing server-side for the website/javascript developers--just ask for your nonce from the same API you are using to develop against, and make requests with that nonce until you get a bad nonce response--then ask for a new one, and repeat.