登录/会话 cookie、Ajax 和安全 [英] Login/session cookies, Ajax and security
问题描述
我正在尝试为基于 ajax 的登录表单确定最安全的方法来验证和设置客户端 cookie.我见过这样的 XSS 攻击:
I'm trying to determine the most secure method for an ajax based login form to authenticate and set a client side cookie. I've seen things about XSS attacks such as this:
和
http://www.codinghorror.com/blog/archives/001167.html
所以，我想我的核心问题是...
So, I guess my core questions are...
1) 是否使用纯 ajax 设置 cookie 安全，如果是，最安全的方法是什么(httpOnly + SSL + 加密值等)?
1) Is using pure ajax to set cookies secure, if so, what is the most secure method (httpOnly + SSL + encrypted values, etc.)?
2) 纯 ajax 方法是否涉及设置 cookie 客户端?这完全安全吗?
2) Does a pure ajax method involve setting the cookie client side? Is this at all secure?
3) 以这种方式设置 cookie 是否在所有主要浏览器/操作系统上都可靠?
3) Is setting cookies this way reliable across all major browsers/OSs?
4) 使用隐藏的 IFrame 会更安全吗(调用网页来设置 cookie)?
4) Would using a hidden IFrame be any more secure (calling a web page to set the cookies)?
5) 如果可能的话，有人有这方面的代码吗(PHP 是我的后端)?
5) If possible, does anybody have code for this (PHP is my backend)?
我的目标是设置 cookie 并让它们在下次调用服务器时可用，而无需离开页面.
My goal is to set the cookies and have them available for the next call to the server without navigating away from the page.
我真的很想确定共识，这是最安全的方式.最终，此代码计划开源，因此请不要使用商业代码(或任何经不起公众审查的代码)
I really want to nail down the consensus, most secure way to do this. Eventually, this code is planned to be made Open Source, so please no commercial code (or nothing that wouldn't stand up to public scrutiny)
谢谢，-托德
推荐答案
cookie 需要在服务器端生成，因为会话将客户端绑定到服务器，因此令牌交换必须在某个阶段从服务器到客户端.在客户端生成 cookie 并没有什么用，因为客户端是不受信任的远程机器.
可以在 AJAX 调用期间设置 cookie.对于服务器(和网络)，AJAX 调用只是一个 HTTP 调用，服务器的任何 HTTP 响应都可以设置 cookie.所以是的，可以发起一个会话来响应 AJAX 调用，并且 cookie 将被客户端照常存储.
It is possible to have the cookie set during an AJAX call. To the server (and the network) an AJAX call is simply an HTTP call, and any HTTP response by the server can set a cookie. So yes, it is possible to initiate a session in response to an AJAX call, and the cookie will be stored by the client as normal.
因此，您可以使用 AJAX 来执行登录过程，就像您可以依赖页面上表单中的 POST 一样.服务器会以同样的方式查看它们，如果服务器设置了 cookie，浏览器就会存储它.
So, you can use AJAX to do the logging in process in the same was as you could have just relied on a POST from a form on the page. The server will see them the same way, and if the server sets a cookie the browser will store it.
基本上，客户端 Javascript 永远不需要知道 cookie 的值(如果不知道，安全性更好，这可以使用最近浏览器支持的httponly"cookie 扩展来实现).请注意，从客户端到服务器的进一步 HTTP 调用，无论它们是普通页面请求还是 AJAX 请求，都会自动包含该 cookie，即使它被标记为 httponly 并且浏览器支持该扩展名.您的脚本不需要知道"cookie.
Basically, client-side Javascript never needs to be able to know the value of the cookie (and it is better for security if it doesn't, which can be achieved using the "httponly" cookie extension honored by recent browsers). Note that further HTTP calls from the client to the server, whether they are normal page requests or they are AJAX requests, will include that cookie automatically, even if it's marked httponly and the browser honors that extension. Your script does not need to be 'aware' of the cookie.
您提到使用 HTTPS(基于 SSL 的 HTTP) - 可以防止其他人读取传输中的信息或冒充服务器，因此对于防止密码或其他重要信息的纯文本传输非常方便.它还可以帮助防御基于网络的攻击，尽管它不会让您免受 CSRF 可能抛出的所有问题，而且它根本不能保护您免受会话固定或 XSS 之类的攻击.因此，如果您使用 HTTPS，我会避免将其视为万能的:您仍然需要警惕跨站点脚本和跨站点请求伪造.
You mentioned using HTTPS (HTTP over SSL) - that prevents others from being able to read information in transit or impersonate the server, so it's very handy for preventing plain text transmission of the password or other important information. It can also help guard against network based attacks, though it does not make you immune to everything that CSRF can throw you, and it does not at all protect you against the likes of session fixation or XSS. So I would avoid thinking of HTTPS as a fix-all if you use it: you still need to be vigilant about cross-site scripting and cross-site request forgery.
(见 1.我把它们组合起来)
(see 1. I sort of combined them)
鉴于 cookie 是由服务器在其 HTTP 响应标头中设置的，是的，它是可靠的.但是，为了使其跨浏览器兼容，您仍然需要确保在 AJAX 不可用时可以登录.这可能需要实现仅在没有 Javascript 或 AJAX 不可用时才能看到的替代方案.(注意:现在是 2014 年，您无需再担心浏览器对 AJAX 的支持.
Given that the cookie is set by the server in its HTTP response headers, yes it is reliable. However, to make it cross-browser compatible you still need to ensure logging in is possible when AJAX is unavailable. This may require implementing an alternative that is seen only when there is no Javascript or if AJAX isn't available. (Note: now in 2014, you don't need to worry about browser support for AJAX anymore).
它不会改变安全性.不需要它，除了我已经看到隐藏的 iframe 之前用于模拟"AJAX - 即对服务器进行异步调用.基本上，不管你怎么做都没有关系，这是服务器设置 cookie，客户端将接受并返回 cookie，无论它是否通过 AJAX 执行.
It would not change the security. There would be no need for it, except that I have seen hidden iframes used before to 'simulate' AJAX before - ie make asyncronous calls to the server. Basically, however you do it doesn't matter, it's the server setting the cookie, and the client will accept and return the cookie whether it does it by AJAX or not.
在大多数情况下，无论您是否使用 AJAX 都不会影响安全性，因为所有真正的安全性都发生在服务器端，而对服务器而言，AJAX 调用就像非 AJAX 调用:不值得信赖.因此，您需要注意诸如 会话固定 和 登录 CSRF 以及影响整个会话的问题，例如 CSRF 和 XSS 就像不使用 AJAX 一样.使用 AJAX 时，这些问题并没有真正改变，除了我猜，如果您对某项技术不太熟悉或更复杂，可能会犯更多错误.
For the most part, whether you use AJAX or not does not affect the security all that much as all the real security happens on the server side, and to the server an AJAX call is just like a non-AJAX call: not to be trusted. Therefore you'll need to be aware of issues such as session fixation and login CSRF as well as issues affecting the session as a whole like CSRF and XSS just as much as you would if you were using no AJAX. The issues don't really change when using AJAX except, except, I guess, that you may make more mistakes with a technology if you're less familiar with it or it's more complicated.
答案于 2014 年 9 月更新
这篇关于登录/会话 cookie、Ajax 和安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
