【Nginx】跨域请求以及实现跨域的方案


1.什么是跨域请求

A cross-domain solution (CDS) is a means of information assurance that provides the ability to manually or automatically access or transfer between two or more differing security domains.

解决两个安全域之间的信息传递,这个就叫做CDS——跨域解决方案.

在 HTML 中,<a>, <form>, <img>, <script>, <iframe>, <link>等标签以及 Ajax(异步 JavaScript 和 XML) 都可以指向一个资源地址,而所谓的跨域请求就是指:当前发起请求的域与该请求指向的资源所在的域不一样。 这里的域指的是这样的一个概念:我们认为若协议 + 域名 + 端口号均相同,那么就是同域.

2.跨域请求的安全问题

通常,浏览器会对上面提到的跨域请求作出限制。浏览器之所以要对跨域请求作出限制,是出于安全方面的考虑,因为跨域请求有可能被不法分子利用来发动 CSRF攻击。

CSRF攻击: CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。CSRF攻击者在用户已经登录目标网站之后,诱使用户访问一个攻击页面,利用目标网站对用户的信任,以用户身份在攻击页面对目标网站发起伪造用户操作的请求,达到攻击目的。

CSRF 攻击的原理大致描述如下:有两个网站,其中A网站是真实受信任的网站,而B网站是危险网站。在用户登陆了受信任的A网站是,本地会存储A网站相关的Cookie,并且浏览器也维护这一个Session会话。这时,如果用户在没有登出A网站的情况下访问危险网站B,那么危险网站B就可以模拟发出一个对A网站的请求(跨域请求)对A网站进行操作,而在A网站的角度来看是并不知道请求是由B网站发出来的(Session和Cookie均为A网站的),这时便成功发动一次CSRF 攻击。

因而 CSRF 攻击可以简单理解为:攻击者盗用了你的身份,以你的名义发送而已请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账……造成的问题包括:个人隐私泄露以及财产安全。

3.同源策略

在客户端编程语言中,如javascript和ActionScript,同源策略是一个很重要的安全理念,它在保证数据的安全性方面有着重要的意义。同源策略规定跨域之间的脚本是隔离的,一个域的脚本不能访问和操作另外一个域的绝大部分属性和方法

概述: 同源策略是 Netscape 提出的一个著名的安全策略 同源策略是浏览器最核心最基础的安全策略 现在所有的可支持 Javascript 的浏览器都会使用这个策略 web构建在同源策略基础之上,浏览器对非同源脚本的限制措施是对同源策略的具体实现

同源策略的含义: DOM 层面的同源策略:限制了来自不同源的”Document”对象或 JS 脚本,对当前“document”对象的读取或设置某些属性 Cookie和XMLHttprequest层面的同源策略:禁止 Ajax 直接发起跨域HTTP请求(其实可以发送请求,结果被浏览器拦截,不展示),同时 Ajax 请求不能携带与本网站不同源的 Cookie。 同源策略的非绝对性:<script><img><iframe><link><video><audio>等带有src属性的标签可以从不同的域加载和执行资源。 其他插件的同源策略:flash、java applet、silverlight、googlegears等浏览器加载的第三方插件也有各自的同源策略,只是这些同源策略不属于浏览器原生的同源策略,如果有漏洞则可能被黑客利用,从而留下XSS攻击的后患。

特例: Web页面上调用js文件时则不受是否跨域的影响,不仅如此,凡是拥有”src”这个属性的标签都拥有跨域的能力,比如<script>、<img>、<iframe>.

4.跨域解决方法

虽然在安全层面上同源限制是必要的,但有时同源策略会对我们的合理用途造成影响,为了避免开发的应用受到限制,有多种方式可以绕开同源策略,我们经常使用的 JSONP, CORS 方法

4.1 JSONP

原理:

  • JSONP 是一种非官方的跨域数据交互协议

  • JSONP 本质上是利用 <script><img><iframe>等标签不受同源策略限制,可以从不同域加载并执行资源的特性,来实现数据跨域传输。

  • JSONP由两部分组成:回调函数和数据。回调函数是当响应到来时应该在页面中调用的函数,而数据就是传入回调函数中的JSON数据。

  • JSONP 的理念就是,与服务端约定好一个回调函数名,服务端接收到请求后,将返回一段 Javascript,在这段 Javascript 代码中调用了约定好的回调函数,并且将数据作为参数进行传递。当网页接收到这段Javascript 代码后,就会执行这个回调函数,这时数据已经成功传输到客户端了。 示例: 定义两个域名分别为

  • a.test.com
  • b.test.coma.test.com/jsonp3.html页面定义一个函数,然后在远程b.test.com/remote3.js中传入数据进行调用a.test.com/jsonp3.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 <meta charset="UTF-8">
    <title></title>
    <script type="text/javascript">
    // 得到航班信息查询结果后的回调函数
    var flightHandler = function(data){
        alert('你查询的航班结果是:票价 ' + data.price + ' 元,' + '余票 ' + data.tickets + ' 张。');
    };
    // 提供jsonp服务的url地址(不管是什么类型的地址,最终生成的返回值都是一段javascript代码)
    var url = "http://b.test.com/remote3.js?callback=flightHandler";
    // 创建script标签,设置其属性
    var script = document.createElement('script');
    script.setAttribute('src', url);
    // 把script标签加入head,此时调用开始
    document.getElementsByTagName('head')[0].appendChild(script);
    </script>
</head>
<body>
</body>
</html>

b.test.com/remote3.js里面的内容

flightHandler({
    "price": 1780,
    "tickets": 5
},
);

访问http://a.test.com/jsonp3.html

JSONP优缺点: JSONP 的优点是:它不像XMLHttpRequest对象实现的Ajax请求那样受到同源策略的限制;它的兼容性更好,在更加古老的浏览器中都可以运行。

JSONP 的缺点是:它只支持 GET 请求,而不支持 POST 请求等其他类型的 HTTP 请求

4.2 CORS

介绍 跨源资源共享 Cross-Origin Resource Sharing(CORS) 是一个新的 W3C 标准,它新增的一组HTTP首部字段,允许服务端其声明哪些源站有权限访问哪些资源。换言之,它允许浏览器向声明了 CORS 的跨域服务器,发出 XMLHttpReuest 请求,从而克服 Ajax 只能同源使用的限制。

另外,规范也要求对于非简单请求,浏览器必须首先使用 OPTION 方法发起一个预检请求(preflight request),从而获知服务端是否允许该跨域请求,在服务器确定允许后,才发起实际的HTTP请求。对于简单请求、非简单请求以及预检请求的详细资料可以阅读HTTP访问控制(CORS) 。

HTTP 协议 Header 简析 下面对 CORS 中新增的 HTTP 首部字段进行简析:

Access-Control-Allow-Origin

响应首部中可以携带这个头部表示服务器允许哪些域可以访问该资源,其语法如下:

Access-Control-Allow-Origin: <origin> | * 其中,origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求,服务器可以指定该字段的值为通配符,表示允许来自所有域的请求。

Access-Control-Allow-Methods

该首部字段用于预检请求的响应,指明实际请求所允许使用的HTTP方法。其语法如下:

Access-Control-Allow-Methods: <method>[, <method>]* Access-Control-Allow-Headers

该首部字段用于预检请求的响应。指明了实际请求中允许携带的首部字段。其语法如下:

Access-Control-Allow-Headers: <field-name>[, <field-name>]* Access-Control-Max-Age

该首部字段用于预检请求的响应,指定了预检请求能够被缓存多久,其语法如下:

Access-Control-Max-Age: <delta-seconds>

Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值,表示是否允许发送Cookie。默认情况下,Cookie不包括在CORS请求之中。设为true,即表示服务器明确许可,Cookie可以包含在请求中,一起发给服务器。其语法如下:

Access-Control-Allow-Credentials: true 另外,如果要把 Cookie 发送到服务器,除了服务端要带上Access-Control-Allow-Credentials首部字段外,另一方面请求中也要带上withCredentials属性。

但是需要注意的是:如果需要在 Ajax 中设置和获取 Cookie,那么Access-Control-Allow-Origin首部字段不能设置为* ,必须设置为具体的 origin 源站。详细可阅读文章CORS 跨域 Cookie 的设置与获取

示例 在a.test.com/test.html页面配置获取b.test.com/test2.html页面的内容,下图 <img src=”http://b.test.com/test.png" /> 是为了证明html带有src标签都不受同源策略的限制 http://a.test.com/test.html

<html> 
<head> 
<script> 
var http = new XMLHttpRequest(); 
http.open("get", "http://b.test.com/test2.html", true);
if (http)
{ 
    http.onload = function() 
    {  
        alert(http.responseText); 
    } 
    http.send(); 
} 
</script> 
<img src="http://b.test.com/test.png" />
</head>
<body>  
</body>
</html>

http://b.test.com/test2.html

<html> 
   <head> 
   </head> 
     <body>  
     hello
     </body> 
</html>

在b.test.com的服务端未配置跨域配置访问http://a.test.com/test.html结果. 在b.test.com的nginx服务端配置跨域配置访问http://a.test.com/test.html

server {
listen 80 ;
server_name b.test.com;
index index.jsp;
req_status server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass_header User-Agent;
proxy_set_header X-Forwarded-Proto $scheme;
access_log logs/access.log main_1;

add_header Access-Control-Allow-Origin http://a.test.com;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
add_header Access-Control-Allow-Credentials true;
add_header Access-Control-Allow-Headers DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type;
add_header Access-Control-Max-Age 1728000;
location / {
root html;
}
}

访问效果,可以正常访问 与 JSONP 的比较

  • JSONP 只能实现 GET 请求,而 CORS 支持所有类型的 HTTP 请求
  • 使用 CORS ,开发者可以是使用普通的 XMLHttpRequest 发起请求和获取数据,比起 JSONP 有更好的错误处理虽然绝大多数现代的浏览器都已经支持 CORS,但是 CORS 的兼容性比不上 JSONP,一些比较老的浏览器只支持 JSONP