当前位置浏览文章
什么是跨域？跨域是指一个域下的文档或脚本试图去请求另一个域下的资源，这里跨域是广义的。广义的跨域：1.) 资源跳转： A链接、重定向、表单提交2.) 资源嵌入： &link&、&script&、&img&、&frame&等dom标签，还有样式中background:url()、@font-face()等文件外链3.) 脚本请求： js发起的ajax请求、dom和js对象的跨域操作等其实我们通常所说的跨域是狭义的，是由浏览器同源策略限制的一类请求场景。什么是同源策略？同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。同源策略限制以下几种行为：1.) Cookie、LocalStorage 和 IndexDB 无法读取2.) DOM 和 Js对象无法获得3.) AJAX 请求不能发送常见跨域场景URL
是否允许通信http://www.domain.com/a.jshttp://www.domain.com/b.js
同一域名，不同文件或路径
允许http://www.domain.com/lab/c.jshttp://www.domain.com:8000/a.jshttp://www.domain.com/b.js
同一域名，不同端口
不允许http://www.domain.com/a.jshttps://www.domain.com/b.js
同一域名，不同协议
不允许http://www.domain.com/a.jshttp://192.168.4.12/b.js
域名和域名对应相同ip
不允许http://www.domain.com/a.jshttp://x.domain.com/b.js
主域相同，子域不同
不允许http://domain.com/c.jshttp://www.domain1.com/a.jshttp://www.domain2.com/b.js
不允许跨域解决方案1、 通过jsonp跨域2、 document.domain + iframe跨域3、 location.hash + iframe4、 window.name + iframe跨域5、 postMessage跨域6、 跨域资源共享（CORS）7、 nginx代理跨域8、 nodejs中间件代理跨域9、 WebSocket协议跨域一、 通过jsonp跨域通常为了减轻web服务器的负载，我们把js、css，img等静态资源分离到另一台独立域名的服务器上，在html页面中再通过相应的标签从不同域名下加载静态资源，而被浏览器允许，基于此原理，我们可以通过动态创建script，再请求一个带参网址实现跨域通信。1.）原生实现： &script&
var script = document.createElement(script);
script.type = text/
// 传参并指定回调执行函数为onBack
script.src = http://www.domain2.com:8080/login?user=admin&callback=onB
document.head.appendChild(script);
// 回调执行函数
function onBack(res) {
alert(JSON.stringify(res));
} &/script&服务端返回如下（返回时即执行全局函数）：onBack({"status": true, "user": "admin"})2.）jquery ajax：$.ajax({
url: http://www.domain2.com:8080/login,
type: get,
dataType: jsonp,
// 请求方式为jsonp
jsonpCallback: "onBack",
// 自定义回调函数名
data: {}});3.）vue.js：this.$http.jsonp(http://www.domain2.com:8080/login, {
params: {},
jsonp: onBack}).then((res) =& {
console.log(res); })后端node.js代码示例：var querystring = require(querystring);var http = require(http);var server = http.createServer();server.on(request, function(req, res) {
var params = qs.parse(req.url.split(?)[1]);
var fn = params.
// jsonp返回设置
res.writeHead(200, { Content-Type: text/javascript });
res.write(fn + ( + JSON.stringify(params) + ));
res.end();});server.listen(8080);console.log(Server is running at port 8080...);jsonp缺点：只能实现get一种请求。二、 document.domain + iframe跨域此方案仅限主域相同，子域不同的跨域应用场景。实现原理：两个页面都通过js强制设置document.domain为基础主域，就实现了同域。1.）父窗口：(http://www.domain.com/a.html))&iframe id="iframe" src="http://child.domain.com/b.html"&&/iframe&&script&
document.domain = domain.
var user =&/script&2.）子窗口：(http://child.domain.com/b.html))&script&
document.domain = domain.
// 获取父窗口中变量
alert(get js data from parent ---&
+ window.parent.user);&/script&三、 location.hash + iframe跨域实现原理： a欲与b跨域相互通信，通过中间页c来实现。 三个页面，不同域之间利用iframe的location.hash传值，相同域之间直接js访问来通信。具体实现：A域：a.html -& B域：b.html -& A域：c.html，a与b不同域只能通过hash值单向通信，b与c也不同域也只能单向通信，但c与a同域，所以c可通过parent.parent访问a页面所有对象。1.）a.html：(http://www.domain1.com/a.html))&iframe id="iframe" src="http://www.domain2.com/b.html" style="display:"&&/iframe&&script&
var iframe = document.getElementById(iframe);
// 向b.html传hash值
setTimeout(function() {
iframe.src = iframe.src + #user=
// 开放给同域c.html的回调方法
function onCallback(res) {
alert(data from c.html ---&
}&/script&2.）b.html：(http://www.domain2.com/b.html))&iframe id="iframe" src="http://www.domain1.com/c.html" style="display:"&&/iframe&&script&
var iframe = document.getElementById(iframe);
// 监听a.html传来的hash值，再传给c.html
window.onhashchange = function () {
iframe.src = iframe.src + location.
};&/script&3.）c.html：(http://www.domain1.com/c.html))&script&
// 监听b.html传来的hash值
window.onhashchange = function () {
// 再通过操作同域a.html的js回调，将结果传回
window.parent.parent.onCallback(hello:
+ location.hash.replace(#user=, ));
};&/script&四、 window.name + iframe跨域window.name属性的独特之处：name值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值（2MB）。1.）a.html：(http://www.domain1.com/a.html))var proxy = function(url, callback) {
var state = 0;
var iframe = document.createElement(iframe);
// 加载跨域页面
iframe.src =
// onload事件会触发2次，第1次加载跨域页，并留存数据于window.name
iframe.onload = function() {
if (state === 1) {
// 第2次onload(同域proxy页)成功后，读取同域window.name中数据
callback(iframe.contentWindow.name);
destoryFrame();
} else if (state === 0) {
// 第1次onload(跨域页)成功后，切换到同域代理页面
iframe.contentWindow.location = http://www.domain1.com/proxy.
state = 1;
document.body.appendChild(iframe);
// 获取数据以后销毁这个iframe，释放内存；这也保证了安全（不被其他域frame js访问）
function destoryFrame() {
iframe.contentWindow.document.write();
iframe.contentWindow.close();
document.body.removeChild(iframe);
}};// 请求跨域b页面数据proxy(http://www.domain2.com/b.html, function(data){
alert(data);});2.）proxy.html：(http://www.domain1.com/proxy....)中间代理页，与a.html同域，内容为空即可。3.）b.html：(http://www.domain2.com/b.html))&script&
window.name = This is domain2 data!;&/script&总结：通过iframe的src属性由外域转向本地域，跨域数据即由iframe的window.name从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制，但同时它又是安全操作。五、 postMessage跨域postMessage是HTML5 XMLHttpRequest Level 2中的API，且是为数不多可以跨域操作的window属性之一，它可用于解决以下方面的问题：a.） 页面和其打开的新窗口的数据传递b.） 多窗口之间消息传递c.） 页面与嵌套的iframe消息传递d.） 上面三个场景的跨域数据传递用法：postMessage(data,origin)方法接受两个参数data： html5规范支持任意基本类型或可复制的对象，但部分浏览器只支持字符串，所以传参时最好用JSON.stringify()序列化。origin： 协议+主机+端口号，也可以设置为""，表示可以传递给任意窗口，如果要指定和当前窗口同源的话设置为"/"。1.）a.html：(http://www.domain1.com/a.html))&iframe id="iframe" src="http://www.domain2.com/b.html" style="display:"&&/iframe&&script&
var iframe = document.getElementById(iframe);
iframe.onload = function() {
var data = {
// 向domain2传送跨域数据
iframe.contentWindow.postMessage(JSON.stringify(data), http://www.domain2.com);
// 接受domain2返回数据
window.addEventListener(message, function(e) {
alert(data from domain2 ---&
+ e.data);
}, false);&/script&2.）b.html：(http://www.domain2.com/b.html))&script&
// 接收domain1的数据
window.addEventListener(message, function(e) {
alert(data from domain1 ---&
+ e.data);
var data = JSON.parse(e.data);
if (data) {
data.number = 16;
// 处理后再发回domain1
window.parent.postMessage(JSON.stringify(data), http://www.domain1.com);
}, false);&/script&六、 跨域资源共享（CORS）普通跨域请求：只服务端设置Access-Control-Allow-Origin即可，前端无须设置，若要带cookie请求：前后端都需要设置。需注意的是：由于同源策略的限制，所读取的cookie为跨域请求接口所在域的cookie，而非当前页。如果想实现当前页cookie的写入，可参考下文：七、nginx反向代理中设置proxy_cookie_domain 和 八、NodeJs中间件代理中cookieDomainRewrite参数的设置。目前，所有浏览器都支持该功能(IE8+：IE8/9需要使用XDomainRequest对象来支持CORS）)，CORS也已经成为主流的跨域解决方案。1、 前端设置：1.）原生ajax// 前端设置是否带cookiexhr.withCredentials =示例代码：var xhr = new XMLHttpRequest(); // IE8/9需用window.XDomainRequest兼容// 前端设置是否带cookiexhr.withCredentials =xhr.open(post, http://www.domain2.com:8080/login, true);xhr.setRequestHeader(Content-Type, application/x-www-form-urlencoded);xhr.send(user=admin);xhr.onreadystatechange = function() {
if (xhr.readyState == 4 && xhr.status == 200) {
alert(xhr.responseText);
}};2.）jQuery ajax$.ajax({
xhrFields: {
withCredentials: true
// 前端设置是否带cookie
crossDomain: true,
// 会让请求头中包含跨域的额外信息，但不会含cookie
...});3.）vue框架在vue-resource封装的ajax组件中加入以下代码：Vue.http.options.credentials = true2、 服务端设置：若后端设置成功，前端浏览器控制台则不会出现跨域报错信息，反之，说明没设成功。1.）Java后台：/
导入包：import javax.servlet.http.HttpServletR
接口参数中定义：HttpServletResponse response /response.setHeader("Access-Control-Allow-Origin", "http://www.domain1.com");
// 若有端口需写全（协议+域名+端口）response.setHeader("Access-Control-Allow-Credentials", "true");2.）Nodejs后台示例：var http = require(http);var server = http.createServer();var qs = require(querystring);server.on(request, function(req, res) {
var postData = ;
// 数据块接收中
req.addListener(data, function(chunk) {
postData +=
// 数据接收完毕
req.addListener(end, function() {
postData = qs.parse(postData);
// 跨域后台设置
res.writeHead(200, {
Access-Control-Allow-Credentials: true,
// 后端允许发送Cookie
Access-Control-Allow-Origin: http://www.domain1.com,
// 允许访问的域（协议+域名+端口）
Set-Cookie: l=a123456;Path=/;Domain=www.domain2.HttpOnly
// HttpOnly:脚本无法读取cookie
res.write(JSON.stringify(postData));
res.end();
});});server.listen(8080);console.log(Server is running at port 8080...);七、 nginx代理跨域1、 nginx配置解决iconfont跨域浏览器跨域访问js、css、img等常规静态资源被同源策略许可，但iconfont字体文件(eot|otf|ttf|woff|svg)例外，此时可在nginx的静态资源服务器中加入以下配置。location / {
add_header Access-Control-Allow-O}2、 nginx反向代理接口跨域跨域原理： 同源策略是浏览器的安全策略，不是HTTP协议的一部分。服务器端调用HTTP接口只是使用HTTP协议，不会执行JS脚本，不需要同源策略，也就不存在跨越问题。实现思路：通过nginx配置一个代理服务器（域名与domain1相同，端口不同）做跳板机，反向代理访问domain2接口，并且可以顺便修改cookie中domain信息，方便当前域cookie写入，实现跨域登录。nginx具体配置：#proxy服务器server {
server_name
www.domain1.
location / {
proxy_pass
http://www.domain2.com:8080;
proxy_cookie_domain www.domain2.com www.domain1. #修改cookie里域名
index.html index.
# 当用webpack-dev-server等中间件代理接口访问nignx时，此时无浏览器参与，故没有同源限制，下面的跨域配置可不启用
add_header Access-Control-Allow-Origin http://www.domain1.
#当前端只跨域不带cookie时，可为
add_header Access-Control-Allow-C
}}1.) 前端代码示例：var xhr = new XMLHttpRequest();// 前端开关：浏览器是否读写cookiexhr.withCredentials =// 访问nginx中的代理服务器xhr.open(get, http://www.domain1.com:81/?user=admin, true);xhr.send();2.) Nodejs后台示例：var http = require(http);var server = http.createServer();var qs = require(querystring);server.on(request, function(req, res) {
var params = qs.parse(req.url.substring(2));
// 向前台写cookie
res.writeHead(200, {
Set-Cookie: l=a123456;Path=/;Domain=www.domain2.HttpOnly
// HttpOnly:脚本无法读取
res.write(JSON.stringify(params));
res.end();});server.listen(8080);console.log(Server is running at port 8080...);八、 Nodejs中间件代理跨域node中间件实现跨域代理，原理大致与nginx相同，都是通过启一个代理服务器，实现数据的转发，也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名，实现当前域的cookie写入，方便接口登录认证。1、 非vue框架的跨域（2次跨域）利用node + express + http-proxy-middleware搭建一个proxy服务器。1.）前端代码示例：var xhr = new XMLHttpRequest();// 前端开关：浏览器是否读写cookiexhr.withCredentials =// 访问http-proxy-middleware代理服务器xhr.open(get, http://www.domain1.com:3000/login?user=admin, true);xhr.send();2.）中间件服务器：var express = require(express);var proxy = require(http-proxy-middleware);var app = express();app.use(/, proxy({
// 代理跨域目标接口
target: http://www.domain2.com:8080,
changeOrigin: true,
// 修改响应头信息，实现跨域并允许带cookie
onProxyRes: function(proxyRes, req, res) {
res.header(Access-Control-Allow-Origin, http://www.domain1.com);
res.header(Access-Control-Allow-Credentials, true);
// 修改响应信息中的cookie域名
cookieDomainRewrite: www.domain1.com
// 可以为false，表示不修改}));app.listen(3000);console.log(Proxy server is listen at port 3000...);3.）Nodejs后台同（六：nginx）2、 vue框架的跨域（1次跨域）利用node + webpack + webpack-dev-server代理接口跨域。在开发环境下，由于vue渲染服务和接口代理服务都是webpack-dev-server同一个，所以页面与代理接口之间不再跨域，无须设置headers跨域信息了。webpack.config.js部分配置：module.exports = {
entry: {},
module: {},
devServer: {
historyApiFallback: true,
context: /login,
target: http://www.domain2.com:8080,
// 代理跨域目标接口
changeOrigin: true,
secure: false,
// 当代理某些https服务报错时用
cookieDomainRewrite: www.domain1.com
// 可以为false，表示不修改
noInfo: true
}}九、 WebSocket协议跨域WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，是server push技术的一种很好的实现。原生WebSocket API使用起来不太方便，我们使用Socket.io，它很好地封装了webSocket接口，提供了更简单、灵活的接口，也对不支持webSocket的浏览器提供了向下兼容。1.）前端代码：&div&user input：&input type="text"&&/div&&script src="./socket.io.js"&&/script&&script&var socket = io(http://www.domain2.com:8080);// 连接成功处理socket.on(connect, function() {
// 监听服务端消息
socket.on(message, function(msg) {
console.log(data from server: ---&
// 监听服务端关闭
socket.on(disconnect, function() {
console.log(Server socket has closed.);
});});document.getElementsByTagName(input)[0].onblur = function() {
socket.send(this.value);};&/script&2.）Nodejs socket后台：var http = require(http);var socket = require(socket.io);// 启http服务var server = http.createServer(function(req, res) {
res.writeHead(200, {
Content-type: text/html
res.end();});server.listen(8080);console.log(Server is running at port 8080...);// 监听socket连接socket.listen(server).on(connection, function(client) {
// 接收信息
client.on(message, function(msg) {
client.send(hello： + msg);
console.log(data from client: ---&
// 断开处理
client.on(disconnect, function() {
console.log(Client socket has closed.);
});});原文：https://segmentfault.com/a/5364Cookies 的跨域脚本攻击 - Github 迁移域名的安全详解 - 技术翻译 - 开源中国社区
Cookies 的跨域脚本攻击 - Github 迁移域名的安全详解
【已翻译100%】
英文原文：
推荐于 5年前 (共 15 段, 翻译完成于 04-14)
参与翻译&(2人)&: ,
上周五我们宣布并完成了把所有的GitHub页面迁移到新域名github.io。&这是个计划已久的行动，此举是为了防止恶意网站攻击和跨域cookie的漏洞，这些漏洞是通过在我们主站的子域名下控制客户内容产生的。
关于这些跨域攻击漏洞的可怕影响，大家可能会有一些困惑。我们希望这篇技术博客可以消除这些困惑。
&翻译得不错哦！
一个二级域名传过来的Cookie
当你登陆GitHub.com时，我们通过响应的HTTP头部来设置session的cookie。这个cookie包含着唯一标识你的session数据：
Set-Cookie: _session=THIS_IS_A_SESSION_TOKEN; path=/; expires=Sun, 01-Jan-:00 GMT; HttpOnly 这些GitHub发送给浏览器的session的cookie是设定在默认的域名上（github.com）,这就意味着这些cookie是不能从二级域名*.github.com访问到的。而且我们也指定了HttpOnly属性，这意味着cookie也不能通过JavaScript
的API：document.cookie来读取。最后，我们指定了Secure属性，这意味着这些cookie只能通过HTTPS来传输。
&翻译得不错哦！
因此，从GitHub托管网站读取或"窃取"session的cookie是不太可能的。通过在GitHub网站托管的用户代码是不容易获取到session的cookie，但由于浏览器通过HTTP请求来发送cookie，这种方式有可能把cookie从GitHub网站抛到GitHub父域名上。
当浏览器执行一个HTTP请求时，它通过header里单独的cookie发送一些和URL匹配的cookie，这些发送的cookie是以键-值对存在的。只有和请求的URL匹配的cookie才会发送出去，比如，当执行一个对github.com的请求时，设置在域名github.io上的cookie是不会发送的，但在github.com上的cookie将会发送。
GET / HTTP/1.1
Host: github.com
Cookie: logged_in= _session=THIS_IS_A_SESSION_TOKEN; Cookie抛出的问题是因为header中的cookie只包含了一系列键值对的cookie，并没有一些其他信息，
通过这些额外信息可以知道cookie设置在哪个域名上，比如路径或者域名。
&翻译得不错哦！
最直接的跨域攻击涉及到：在GitHub托管网站页面，通过document.cookie这个JavaScript API设置一个_session的cookie。假设这个网站托管在*.github.com，那么这个cookie将会被设置到父域名的所有请求里，尽管事实是它只设置在了二级域名里。
/* set a cookie in the .github.com subdomain */ document.cookie = "_session=EVIL_SESSION_TOKEN; Path=/; Domain=.github.com"
GET / HTTP/1.1
Cookie: logged_in= _session=EVIL_SESSION_TOKEN; _session=THIS_IS_A_SESSION_TOKEN;
Host: github.com 在这个示例中，通过JavaScript在二级域名上设置的cookie被发送旁边合法的cookie字段中，并设置到父域名里。如果域名，路径，Secure和HttpOnly属性未设置的话，根本
没有方法去判断哪个cookie来自哪里。
&翻译得不错哦！
这对大部分web服务器来说是一个大问题，因为在一个域及其子域中的cookies的顺序并不是有RFC6265指定的，并且web浏览器可以选择以任何顺序发送它们。
对于Rack--为Rails和Sinatra提供动力的web服务器界面，包括其他的，cookis解析如下：
def cookies hash = {} cookies = Utils.parse_query(cookie_header, ';,') cookies.each { |k,v| hash[k] = Array === v ? v.first : v } hash end
如果在Cookie:header里有不止一个有着相同名字的cookie时，第一个cookie将会被假定成任意值。
&翻译得不错哦！
这是一个很显而易见的攻击:几周之前,安全专家Egor Homakov在博客中就用这个方法证明了该攻击确实存在.这个漏洞的影响是不严重的(每次登录后,跨站点伪造请求的令牌会被重置,所以它们不会一直固定不变),但这是个非常实际的例子,人们可以很容易伪造注销用户,令人很郁闷.这使得我们必须尽快完成把GitHub页面迁移的他们自己的域名,但只留给我们几周的时间(到迁移完成之前),在这期间我们必须减轻已知的攻击数量.
幸运的是,已知的攻击在服务端很容易减轻.我们预想到会有一些其他的攻击,这些攻击或者很难处理,或者根本不可能存在.那么让我们一起看看这些它们.
&翻译得不错哦！
免受cookie抛出的伤害
第一步是减轻cookie抛出造成的攻击.这个攻击暴露出浏览器将会发送2个相同名字的cookie令牌,不让我们知道它们是设置在哪个域名上的.
我们没法判断每个cookie是来自哪里的,但如果我们跳过cookie的解析,我们就能看出每个请求是否包含2个相同的_session的cookie.这个极有可能是由于有些人从二级尝试域名抛出这些cookie,所以我们不是猜测哪个cookie是合法的,哪个是被抛过来的,而是简单地通知浏览器在继续执行之前放弃二级域名上设置的cookie.
&翻译得不错哦！
为了完成这个示例,我们创造了一个特殊的响应:我们让浏览器跳转到刚刚请求的URL,但带着一个Set-Cookie的header,这个header放弃了二级域名上的cookie.
GET /libgit2/libgit2 HTTP/1.1
Host: github.com
Cookie: logged_in= _session=EVIL_SESSION_TOKEN; _session=THIS_IS_A_SESSION_TOKEN;
HTTP/1.1 302 Found
Location: /libgit2/libgit2
Content-Type: text/html
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/; Domain=.github. 我们决定按照Rack中间件来实现这个功能.这种方式在
应用运行之前可以执行检查cookie和顺序重定向的工作.
当触发Rack的中间件时,在用户不会意识到的情况下,这个重定向会自动发生,并且第二个请求将只会包含一个_session的cookie:合法的那一个.
这个"破解"足够减缓大部分人所遇到的直接抛出cookie的攻击,但还有一些更复杂的攻击也需要我们思考一下.
&翻译得不错哦！
Cookie路径方案
如果一个恶意的cookie设置到一个具体的路径,这个路径不是根路径(例如,/notifications),当用户访问github.com/notifications时,浏览器会发送那个cookie,当我们在根路径上清除这个cookie时,我们的header不会起作用.
document.cookie = "_session=EVIL_SESSION_TOKEN; Path=/ Domain=.github.com"
GET /notifications HTTP/1.1
Host: github.com
Cookie: logged_in= _session=EVIL_SESSION_TOKEN; _session=THIS_IS_A_SESSION_TOKEN;
HTTP/1.1 302 Found
Location: /notifications
Content-Type: text/html
the _session cookie was set
# with `Path=/notifications` and won't be cleared by this,
# causing an infinite redirect loop
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/; Domain=.github. 这个方案非常直截了当,虽然不太雅:对于任何指定的请求URL,如果其路径部分匹配请求的URL,浏览器将只会发送一个恶意的JavaScript cookie.所以我们只需要在每个路径的元素上放弃这个cookie就可以了.
HTTP/1.1 302 Found
Location: /libgit2/libgit2/pull/1457
Content-Type: text/html
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/; Domain=.github.
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/libgit2; Domain=.github.
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/libgit2/libgit2; Domain=.github.
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/libgit2/libgit2/ Domain=.github.
Set-Cookie: _session=; Expires=Thu, 01-Jan-:01 GMT; Path=/libgit2/libgit2/pull/1457; Domain=.github. 当谈到cookie时,我们需要在服务端做关联.我们唯一目的是用这个强力方式清楚那些cookie,这种方式虽然暴力,但完成github.io的迁移后,效果非常好.
&翻译得不错哦！
Cookie溢出
让我们加强我们的游戏:另一种攻击将会执行,它利用RFC 6265没有明确指明一种cookie的溢出行为.大部分web服务器/接口,包括Rack,假定cookie的名字可以加密(如果他们包含不是ASCII的字符时,这就是个疯狂的假设),所以当生成cookie列表时不会溢出:
cookies = Utils.parse_query(string, ';,') { |s| Rack::Utils.unescape(s) rescue s }
这就允许一个恶意用户去设置一个cookie,这个cookie能被web框架理解成_session,尽管在浏览器里这个cookie的名字并不是_session.这个攻击会把没必要溢出的cookie字符溢出掉:
GET / HTTP/1.1
Host: github.com
Cookie: logged_in= _session=chocolate- _%73ession=bad-
{ "_session" : ["chocolate-cookie", "bad-cookie"] }
&翻译得不错哦！
我们的翻译工作遵照 ，如果我们的工作有侵犯到您的权益，请及时联系我们
由于水平有限，所以有很多地方不准确，多谢指摘。但现在好像没法编辑译文了，不知道怎么修改啊
难怪每次看到这里都懵了，看了英文有优点迷糊，谢谢。}