Heim >Web-Frontend >js-Tutorial >Eine eingehende Analyse der Same-Origin-Richtlinie und der domänenübergreifenden access_javascript-Fähigkeiten

Eine eingehende Analyse der Same-Origin-Richtlinie und der domänenübergreifenden access_javascript-Fähigkeiten

WBOY
WBOYOriginal
2016-05-16 15:29:421231Durchsuche

1. Was ist die gleiche Ursprungsrichtlinie

Um domänenübergreifend zu verstehen, müssen Sie zunächst die Same-Origin-Richtlinie verstehen. Die Same Origin Policy ist eine sehr wichtige Sicherheitsrichtlinie, die aus Sicherheitsgründen in Browsern implementiert wird.

Was ist der gleiche Ursprung:

URL besteht aus Protokoll, Domänenname, Port und Pfad. Wenn Protokoll, Domänenname und Port zweier URLs identisch sind, bedeutet dies, dass sie denselben Ursprung haben.

Gleiche Herkunftsrichtlinie:

Die Same-Origin-Richtlinie des Browsers verhindert, dass „Dokumente“ oder Skripte aus unterschiedlichen Quellen bestimmte Attribute für das aktuelle „Dokument“ lesen oder festlegen. (White Hat spricht über Websicherheit [1])

Von einer Domäne geladene Skripte dürfen nicht auf Dokumenteigenschaften einer anderen Domäne zugreifen.

Zum Beispiel:

Beispielsweise bettet eine bösartige Website die Anmeldeseite einer Bank über einen Iframe ein (die beiden Quellen sind unterschiedlich). Wenn es keine Herkunftseinschränkung gibt, kann das JavaScript-Skript auf der bösartigen Webseite den Benutzernamen und das Passwort abrufen Der Benutzer meldet sich bei der Bank an.

Im Browser können Tags wie 3f1c4e4b6b16bbbd69b2ee476dc4f83a, a1f02c36ba31691bcfe87b2722de723b, d5ba1642137c3f32f4f4493ae923989c, 2cdf5bf648cf2f33323966d7f58a7f3f domänenübergreifende Ressourcen laden, ohne durch denselben Ursprung eingeschränkt zu werden, der Browser verhindert jedoch JavaScript-Berechtigungen es vom Lesen oder Schreiben des geladenen Inhalts abhält.

Darüber hinaus beschränkt die Same-Origin-Richtlinie nur die HTML-Dokumente von Webseiten, und andere geladene statische Ressourcen wie Javascript, CSS, Bilder usw. gelten weiterhin als zum selben Ursprung gehörend.

Codebeispiel (http://localhost:8080/ und http://localhost:8081 haben aufgrund unterschiedlicher Ports unterschiedliche Quellen):

http://localhost:8080/test.html 
    <html> 
      <head><title>test same origin policy</title></head> 
      <body> 
        <iframe id="test" src="http://localhost:8081/test2.html"></iframe> 
        <script type="text/javascript"> 
          document.getElementById("test").contentDocument.body.innerHTML = "write somthing"; 
        </script> 
      </body> 
    </html> 
http://localhost:8081/test2.html 
    <html> 
      <head><title>test same origin policy</title></head> 
      <body> 
        Testing. 
      </body> 
    </html> 

    在Firefox中会得到如下错误

        Error: Permission denied to access property 'body'

    Document对象的domain属性存放着装载文档的服务器的主机名,可以设置它。
    例如来自"blog.csdn.net"和来自"bbs.csdn.net"的页面,都将document.domain设置为"csdn.net",则来自两个子域名的脚本即可相互访问。
    出于安全的考虑,不能设置为其他主domain,比如http://www.csdn.net/不能设置为sina.com

2. Ajax跨域

    Ajax (XMLHttpRequest)请求受到同源策略的限制。

    Ajax通过XMLHttpRequest能够与远程的服务器进行信息交互,另外XMLHttpRequest是一个纯粹的Javascript对象,这样的交互过程,是在后台进行的,用户不易察觉。

    因此,XMLHTTP实际上已经突破了原有的Javascript的安全限制。

    举个例子:

        假设某网站引用了其它站点的javascript,这个站点被compromise并在javascript中加入获取用户输入并通过ajax提交给其他站点,这样就可以源源不断收集信息。

        或者某网站因为存在漏洞导致XSS注入了javascript脚本,这个脚本就可以通过ajax获取用户信息并通过ajax提交给其他站点,这样就可以源源不断收集信息。

   如果我们又想利用XMLHTTP的无刷新异步交互能力,又不愿意公然突破Javascript的安全策略,可以选择的方案就是给XMLHTTP加上严格的同源限制。

   这样的安全策略,很类似于Applet的安全策略。IFrame的限制还仅仅是不能访问跨域HTMLDOM中的数据,而XMLHTTP则根本上限制了跨域请求的提交。(实际上下面提到了CORS已经放宽了限制)

   随着Ajax技术和网络服务的发展,对跨域的要求也越来越强烈。下面介绍Ajax的跨域技术。   

2.1 JSONP

    JSONP技术实际和Ajax没有关系。我们知道3f1c4e4b6b16bbbd69b2ee476dc4f83a标签可以加载跨域的javascript脚本,并且被加载的脚本和当前文档属于同一个域。因此在文档中可以调用/访问脚本中的数据和函数。如果javascript脚本中的数据是动态生成的,那么只要在文档中动态创建3f1c4e4b6b16bbbd69b2ee476dc4f83a标签就可以实现和服务端的数据交互。

    JSONP就是利用3f1c4e4b6b16bbbd69b2ee476dc4f83a标签的跨域能力实现跨域数据的访问,请求动态生成的JavaScript脚本同时带一个callback函数名作为参数。其中callback函数本地文档的JavaScript函数,服务器端动态生成的脚本会产生数据,并在代码中以产生的数据为参数调用callback函数。当这段脚本加载到本地文档时,callback函数就被调用。

    第一个站点的测试页面(http://localhost:8080/test.html): 

<script src="http://localhost:8081/test_data.js"> 
  <script> 
    function test_handler(data) { 
      console.log(data); 
    } 
</script> 

    服务器端的Javascript脚本(http://localhost:8081/test_data.js):

test_handler('{"data": "something"}');

    为了动态实现JSONP请求,可以使用Javascript动态插入3f1c4e4b6b16bbbd69b2ee476dc4f83a标签:

<script type="text/javascript"> 
    // this shows dynamic script insertion 
    var script = document.createElement('script'); 
    script.setAttribute('src', url); 
    // load the script 
    document.getElementsByTagName('head')[0].appendChild(script);  
</script> 

        JSONP协议封装了上述步骤,jQuery中统一是现在AJAX中(其中data type为JSONP):
    http://localhost:8080/test?callback=test_handler

    为了支持JSONP协议,服务器端必须提供特别的支持[2],另外JSONP只支持GET请求。

2.2 Proxy

    使用代理方式跨域更加直接,因为SOP的限制是浏览器实现的。如果请求不是从浏览器发起的,就不存在跨域问题了。

    使用本方法跨域步骤如下:

    1. 把访问其它域的请求替换为本域的请求

    2. 本域的请求是服务器端的动态脚本负责转发实际的请求
    各种服务器的Reverse Proxy功能都可以非常方便的实现请求的转发,如Apache httpd + mod_proxy。

    Eg.

    为了通过Ajax从http://localhost:8080访问http://localhost:8081/api,可以将请求发往http://localhost:8080/api

    然后利用Apache Web服务器的Reverse Proxy功能做如下配置:

        ProxyPass /api http://localhost:8081/api

2.3 CORS

2.3.1 Cross origin resource sharing

       “Cross-origin resource sharing (CORS) is a mechanism that allows a web page to make XMLHttpRequests to another domain. Such "cross-domain" requests would otherwise be forbidden by web browsers, per the same origin security policy. CORS defines a way in which the browser and the server can interact to determine whether or not to allow the cross-origin request. It is more powerful than only allowing same-origin requests, but it is more secure than simply allowing all such cross-origin requests.” ----Wikipedia[3]

   通过在HTTP Header中加入扩展字段,服务器在相应网页头部加入字段表示允许访问的domain和HTTP method,客户端检查自己的域是否在允许列表中,决定是否处理响应。

   实现的基础是JavaScript不能够操作HTTP Header。某些浏览器插件实际上是具有这个能力的。

   服务器端在HTTP的响应头中加入(页面层次的控制模式):

   Access-Control-Allow-Origin: example.com
   Access-Control-Request-Method: GET, POST
   Access-Control-Allow-Headers: Content-Type, Authorization, Accept, Range, Origin
   Access-Control-Expose-Headers: Content-Range
   Access-Control-Max-Age: 3600

   多个域名之间用逗号分隔,表示对所示域名提供跨域访问权限。"*"表示允许所有域名的跨域访问。

   客户端可以有两种行为:

   1. 发送OPTIONS请求,请求Access-Control信息。如果自己的域名在允许的访问列表中,则发送真正的请求,否则放弃请求发送。

   2. 直接发送请求,然后检查response的Access-Control信息,如果自己的域名在允许的访问列表中,则读取response body,否则放弃。

   本质上服务端的response内容已经到达本地,JavaScript决定是否要去读取。

  Support: [Javascript Web Applications]
  * IE >= 8 (需要安装caveat)
  * Firefox >= 3
  * Safari 完全支持
  * Chrome 完全支持
  * Opera 不支持

 2.3.2 测试

   测试页面http://localhost:8080/test3.html使用jquery发送Ajax请求。

<html> 
    <head><title>testing cross sop</title></head> 
    <body> 
      Testing. 
      <script src="jquery-2.0.0.min.js"></script> 
      <script type='text/javascript'> 
        $.ajax({ 
          url: 'http://localhost:8000/hello', 
          success: function(data) { 
            alert(data); 
          }, 
          error: function() { 
            alert('error'); 
          } 
        }); 
      </script> 
    </body> 
</html> 

    测试Restful API(http://localhost:8000/hello/{name})使用bottle.py来host。

  from bottle import route, run, response
  @route('/hello')
  def index():
    return 'Hello World.'
  run(host='localhost', port=8000)

    测试1:

        测试正常的跨域请求的行为。

    测试结果:

        1. 跨域GET请求已经发出,请求header中带有
            Origin    http://localhost:8080
        2. 服务器端正确给出response
        3. Javascript拒绝读取数据,在firebug中发现reponse为空,并且触发error回调

    测试2:

        测试支持CORS的服务器的跨域请求行为。
        对Restful API做如下改动,在response中加入header:
             def index():
                #Add CORS header#
                response.set_header("Access-Control-Allow-Origin", "http://localhost:8080")
                return 'Hello World.'
  

  测试结果:

        1. 跨域GET请求已经发出,请求header中带有
            Origin    http://localhost:8080
        2. 服务器端正确给出response
        3. 客户端正常获取数据

    测试3:

        测试OPTIONS请求获取CORS信息。
        对客户端的Ajax请求增加header:       

$.ajax({ 
     url: 'http://localhost:8000/hello', 
     headers: {'Content-Type': 'text/html'}, 
     success: function(data) { 
       alert(data); 
     }, 
     error: function() { 
       alert('error'); 
     } 
   }); 

        对Restful API做如下改动:

   @route('/hello', method = ['OPTIONS', 'GET'])
      def index():
        if request.method == 'OPTIONS':
          return ''
        return 'Hello World.'

    测试结果:

    1. Ajax函数会首先发送OPTIONS请求
    2. 针对OPTIONS请求服务器
    3. 客户端发现没有CORS header后不会发送GET请求

    测试4:

        增加服务器端对OPTIONS方法的处理。
        对Restful API做如下改动:

 @route('/hello', method = ['OPTIONS', 'GET'])
      def index():
        response.headers['Access-Control-Allow-Origin'] = 'http://localhost:8080'
        response.headers['Access-Control-Allow-Methods'] = 'GET, OPTIONS'
        response.headers['Access-Control-Allow-Headers'] = 'Origin, Accept, Content-Type'
        if request.method == 'OPTIONS':
          return ''
        return 'Hello World.'

    测试结果:

        1. Ajax函数会首先发送OPTIONS请求
        2. 针对OPTIONS请求服务器
        3. 客户端匹配CORS header中的allow headers and orgin后会正确发送GET请求并获取结果

      测试发现,Access-Control-Allow-Headers是必须的。

   CORS协议提升了Ajax的跨域能力,但也增加了风险。一旦网站被注入脚本或XSS攻击,将非常方便的获取用户信息并悄悄传递出去。

4. Cookie 同源策略

    Cookie中的同源只关注域名,忽略协议和端口。所以https://localhost:8080/http://localhost:8081/的Cookie是共享的。

5. Flash/SilverLight跨域

    浏览器的各种插件也存在跨域需求。通常是通过在服务器配置crossdomain.xml[4],设置本服务允许哪些域名的跨域访问。
    客户端会首先请求此文件,如果发现自己的域名在访问列表里,就发起真正的请求,否则不发送请求。

 <&#63;xml version="1.0"&#63;>
      <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
      <cross-domain-policy>
      <allow-access-from domain="*"/>
      <allow-http-request-headers-from domain="*" headers="*"/>
    </cross-domain-policy>

    通常crossdomain.xml放置在网站根目录。

6. 总结 

    互联网的发展催生了跨域访问的需求,各种跨域方法和协议满足了需求但也增加了各种风险。尤其是XSS和CSRF等攻击的盛行也得益于此。

    了解这些技术背景有助于在实际项目中熟练应用并规避各种安全风险。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn