文章整理自《华为防火墙技术漫谈》
 
   
 
   
 
   
安全策略初体验
 
   
规则是实施安全控制的“安检员”，它在防火墙转发报文的过程中扮演着重要角色，只有规则允许通过，报文才能在安全区域之间流动，否则报文将被丢弃。规则在防火墙上的具体体现就是“安全策略”。
 
   
这里还要特意说明一下安全策略中的条件，可分为多个字段，如源地址、目的地址、源端口、目的端口等，这些字段之间是“与”的关系，也就是说，只有报文中的信息和所有字段都匹配上，才算是命中了这条策略。如果同一个字段中有多个匹配项，同时有两个源地址或三个目的地址，那么这些匹配项之间是“或”的关系，只要报文匹配了其中的一项，就算匹配了该条件。
 
   
 
   
 
   
匹配顺序
 
   
安全策略之间是存在顺序的，防火墙在两个安全区域之间转发报文时，会按照从上到下的顺序逐条查找域间存在的安全策略。如果报文命中了某一条安全策略，就会执行该安全策略中的动作，或允许通过或拒绝通过，不会再继续向下查找；如果报文没有命中某条安全策略，则会向下继续查找。
 
   
基于上述实现方式，我们在配置安全策略时要遵循“先精细，后粗犷”的原则。具体来说，就是先配置匹配范围小、条件精确的安全策略，然后再配置匹配范围大、条件宽泛的安全策略。相信大家都配置过ACL规则，安全策略的配置和ACL规则是一个道理。
 
   
 
   
 
   
缺省包过滤
 
   
缺省包过滤的条件最宽泛，所有的报文都可以匹配上，所以防火墙把缺省包过滤作为处理报文的最后手段。如下图所示，报文如果没有命中任何一条安全策略，最后将会命中缺省包过滤，防火墙将会对报文执行缺省包过滤中配置的动作。
 
   
 
   
默认情况下，缺省包过滤的动作是拒绝通过，也就是说，如果没有配置任何安全策略，防火墙是不允许报文在安全区域之间流动的。有时候为了简化配置，大家会把两个安全区域之间缺省包过滤的动作设置成允许通过。这样操作确实省时省事，但是会带来极大的安全风险，允许所有报文通过，网络隔离和访问控制都无法实现，防火墙也就失去了存在的意义。所以我们建议不要轻易将缺省包过滤的动作设置成允许通过，而是通过配置条件精确的安全策略来控制报文的转发。
 
   
另外还有一点需要特别说明，当防火墙的接口工作在二层模式（透明模式）时，经过防火墙的报文也会受到安全策略的控制，所以这种情况下也需要配置相应的安全策略对报文进行管控。
 
   
 
   
2.2安全策略发展历程
 
   
 
   
华为防火墙安全策略的发展主要经历了三个阶段：基于ACL的包过滤阶段、融合UTM的安全策略阶段、一体化安全策略阶段。
 
   
 
   
华为防火墙安全策略的发展历程有以下几个特点。
 
   
匹配条件越来越精细，从传统防火墙的基于IP、端口来识别报文到下一代防火墙基于用户、应用、内容来识别报文，识别能力越来越强。
动作越来越多，从简单的允许/拒绝报文通过到对报文进行多种内容安全检查，处理手段越来越丰富。
配置方式也在不断改进，从配置ACL到配置一体化安全策略，易于理解，简单便捷。
   
 
   
第一阶段：基于ACL的包过滤
 
   
包过滤的处理过程是先获取需要转发数据包的报文头信息，然后和设定的ACL规则进行比较，根据比较的结果对数据包进行转发或者丢弃。实现包过滤的核心技术是访问控制列表ACL
 
   
因此包过滤只能基于IP地址、端口号等控制流量是否可以通过防火墙，无法准确识别应用。
 
   
 
   
 
   
[FW] acl 3000
 
   
[FW-acl-adv-3000] rule deny ip source 192.168.0.100 0
 
   
[FW-acl-adv-3000] rule permit ip source 192.168.0.0 0.0.0.255 destination 172.16.0.0 0.0.0.255
 
   
[FW] firewall interzone trust untrust
 
   
[FW-interzone-trust-untrust] packet-filter 3000 outbound
 
   
 
   
第二阶段：融合UTM的安全策略
 
   
融合UTM的安全策略由条件、动作和UTM策略组成。有一点需要注意，在安全策略的条件中出现了服务集（Service-set）的概念，代替了协议和端口。安全策略中已经内置了一些服务集，包含常见的协议，直接配置成条件即可；对于不在此范围之内的协议或端口，我们可以自定义新的服务集，然后在安全策略中引用。
 
   
 
   
对于融合UTM的安全策略来说，多条安全策略之间也是存在顺序的，防火墙在两个安全区域之间转发报文时，会按照从上到下的顺序逐条查找域间存在的安全策略。如果报文命中了某一条安全策略，就会执行该安全策略中的动作，不会再继续向下查找；如果报文没有命中某条安全策略，则会向下继续查找。如果所有的策略都没有命中，则执行缺省包过滤中的动作。
 
   
 
   
 
   
第三阶段：一体化安全策略
 
   
所谓的一体化，主要包括两个方面的内容：其一是配置上的一体化，像反病毒、入侵防御、URL过滤、邮件过滤等安全功能都可以在安全策略中引用安全配置文件来实现，降低了配置难度；其二是业务处理上的一体化，安全策略对报文进行一次检测，多业务并行处理，大幅度提升了系统性能。
 
   
一体化安全策略除了基于传统的五元组信息之外，还能够基于Application
 
   
（应用）、Content（内容）、Time（时间）、User（用户）、Attack（威胁）、Location（位置）6个维度将模糊的网络环境识别为实际的业务环境，实现精准的访问控制和安全检测。
 
   
 
   
 
   
 
   
[USG6600]security-policy

[USG6600-policy-security]rule name abc

[USG6600-policy-security-rule-abc]source-zone trust

[USG6600-policy-security-rule-abc]destination-zone untrust

[USG6600-policy-security-rule-abc]source-address 10.1.1.0 24

[USG6600-policy-security-rule-abc]application app QQLive

[USG6600-policy-sec:urity-rule-abc]profile ips default

[USG6600-policy-security-rule-abc]action permit
 
   
 
   
 
   
Local区域的安全策略
 
   
网络中的一些业务需要经过防火墙转发，还有一些业务是需要防火墙自身参与处理。例如，管理员会登录到防火墙上进行管理、Internet上的设备或用户会与防火墙建立VPN、防火墙和路由器之间会运行OSPF路由协议、防火墙会与认证服务器对接等。
 
   
这些业务如果想要正常运行，就必须在防火墙上配置相应的安全策略，允许防火墙接收各个业务的报文。具体来说，就是要在防火墙的Local安全区域与业务使用的接口所在的安全区域之间配置安全策略。
 
   
 
   
针对OSPF协议配置Local区域的安全策略
 
   
缺省包过滤将报文丢弃，因为我们没有配置安全策略允许DD报文通过，所以该报文命中缺省包过滤后被丢弃。同时被丢弃报文的个数还在不断增长，说明OSPF模块在不断地尝试发送DD报文，但都被缺省包过滤丢弃了。
 
   
接下来我们在防火墙上开启Local区域和Untrust区域之间的安全策略，允许OSPF报文通过。需要注意的是，因为防火墙既要发送DD报文又要接收DD报文，所以Inbound和Outbound方向上的安全策略都要开启。
 
   
为了精确匹配OSPF协议，我们使用了安全策略提供的ospf服务集，如果防火墙中没有提供这个服务集，我们可以自己创建一个服务集，协议号设置为89即可。
 
   
[FW] policy interzone local untrust inbound

[FW-policy-interzone-local-untrust-inbound] policy 1

[FW-policy-interzone-local-untrust-inbound-1] policy service service-set ospf

[FW-policy-interzone-local-untrust-inbound-1] action permit

[FW] policy interzone local untrust outbound

[FW-policy-interzone-local-untrust-outbound] policy 1

[FW-policy-interzone-local-untrust-outbound-1] policy service service-set ospf

[FW-policy-interzone-local-untrust-outbound-1] action permit
 
   
 
   
实际上，我们还可以从单播报文和组播报文的角度来考虑这个问题。对于防火墙来说，一般情况下，单播报文是受安全策略控制，所以需要配置安全策略允许报文通过；而组播报文不受安全策略控制，也就不需要配置相应的安全策略。
 
   
 
   
 
   
 
   
从表中可以看出，网络类型是Broadcast类型时，OSPF报文中的DD报文和LSR报文是单播报文，需要配置安全策略；网络类型是P2P时，OSPF报文都是组播报文，因此无需配置安全策略。NBMA和P2MP类型也是同理。在实际网络环境中，如果防火墙上的OSPF运行状态不正常，大家也可以从安全策略这个角度入手，检查是不是由于没有配置安全策略允许报文通过所导致的。
 
   
 
   
哪些协议需要在防火墙上配置Local区域的安全策略
 
   
下面给出对应的匹配条件，方便大家在实际网络环境中根据业务类型来配置安全策略
 
   
 
   
 
   
 
   
ASPF
 
   
这就要从FTP协议的特殊之处讲起，FTP协议是一个典型的多通道协议，在其工作过程中，FTP客户端和FTP服务器之间将会建立两条连接：控制连接和数据连接。控制连接用来传输FTP指令和参数，其中就包括建立数据连接所需要的信息；数据连接用来获取目录及传输数据。
 
   
根据数据连接的发起方式，FTP协议分为两种工作模式：主动模式（PORT模式）
 
   
和被动模式（PASV模式）。主动模式中，FTP服务器主动向FTP客户端发起数据连接；被动模式中，FTP服务器被动接收FTP客户端发起的数据连接。
 
   
 
   
下图为被动模式的数据传输过程
 
   
 
   
 
   
 
   
FTP协议工作在主动模式下的交互流程
 
   
 
   
下图为数据包的通信过程
 
   
 
   
 
   
首先FTP客户端使用随机端口xxxx向FTP服务器的21端口发起连接请求建立控制连接，然后使用PORT命令协商两者进行数据连接的端口号，协商出来的端口是yyyy。然后FTP服务器主动向FTP客户端的yyyy端口发起连接请求，建立数据连接。数据连接建立成功后，才能进行数据传输。
 
   
我们只配置了允许FTP客户端访问FTP服务器的安全策略，即控制连接能成功建立。但是当FTP服务器访问FTP客户端yy端口的报文到达防火墙后，对于防火墙来说，这个报文不是前一条连接的后续报文，而是代表着一条新的连接。要想使这个报文顺利到达FTP客户端，防火墙上就必须配置了安全策略允许其通过，但是我们没有配置FTP服务器到FTP客户端这个方向上的安全策略，所以该报文无法通过防火墙，导致FTP访问失败。
 
   
在FTP服务器到FTP客户端这个方向上也配置一条安全策略就行了吧？对，这是一种方法，但是数据连接使用的端口是在控制连接中临时协商出来的，具有随机性，我们无法精确预知，所以只能开放客户端的所有端口，这样就会给FTP客户端带来安全隐患。要是防火墙能记录这个端口，然后自动开启FTP服务器到FTP客户端的安全策略就好了！
 
   
这个时候就要有请安全策略的神秘助手ASPF（Application Specific Packet Filter，针对应用层的包过滤）出场亮相了。单从名字来看，ASPF主要是盯着报文的应用层信息来做文章，其原理是检测报文的应用层信息，记录应用层信息中携带的关键数据，使得某些在安全策略中没有明确定义要放行的报文也能够得到正常转发。
 
   
 
   
 
   
 
   
 
   
记录应用层信息中关键数据的表项称为Server-map表，报文命中该表后，不再受安全策略的控制，这相当于在防火墙上开启了一条“隐形通道"。当然这个通道不是随意开启的，是防火墙分析了报文的应用层信息之后，提前预测到后面报文的行为方式，所以才打开了这样的一个通道。
 
   
 
   
从处理流程看，防火墙收到报文后，先检查报文是否命中会话表，如果命中，说明该报文是后续包，直接转发。如果报文没有命中会话表，说明该报文是首包，接下来检查报文是否命中Server-map表，如本节介绍的ASPF生成的Server-map表，报文命中后就不再受安全策略的控制。当然，防火墙最后还是会为该报文生成会话表。
 
   
 
   
Server-map表和会话表作为防火墙上的重要表项，两者作用不同，也不能相互替代。
 
   
 
   
 
   
 
   
 
   
 
   
 
   
配置注意事项和故障排除指导
 
   
安全策略
 
   
实际网络环境中，安全策略是一个常见的故障点，很多时候都是由于安全策略拒绝报文通过导致业务不通。常用的手段是通过display firewall statistic system discard命令查看防火墙的丢包统计信息，根据显示信息来判断是否涉及安全策略，如下所示。
 
   
 
   
 
   
首先是检查安全策略的匹配条件，如果匹配条件配置有误，将会导致报文无法命中该安全策略，防火墙就无法对报文实施预先设置的动作。安全策略配置完成后，发现防火墙没有按照我们预期的方式来处理报文，此时应检查安全策略的配置情况。重点检查报文有没有命中安全策略。
 
   
 
   
 
   
这里为大家介绍一种通用的配置思路：首先配置缺省包过滤的动作为允许通过，对业务进行调测，保证业务正常运行；然后查看会话表，以会话表中记录的信息为匹配条件配置安全策略；最后恢复缺省包过滤的配置，再次对业务进行调测，验证安全策略是否正确。
 
   
 
  
 
 
 

今天继续给大家介绍华为USG6000系列防火墙。本文从安全策略的内容和配置入手，向大家说明华为系列下一代防火墙的安全策略技术。
 
一、安全策略概述
 
防火墙的基本作用时保护特定网络免受“不信任”网络的攻击，同时还必须允许两个网络之间进行合法的通信。而安全策略是控制设备对流量转发以及对流量进行内容安全一体化检测的策略。安全策略是防火墙实现流量管理和过滤的基本功能。
 最初始的防火墙采用了包过滤技术，包过滤技术是指对需要转发的数据包，先获取包头信息，然后和设定的规则进行比较，根据比较的结果对数据包进行转发或丢弃。随着网络业务的逐步扩大，包过滤技术已经无法满足防火墙的安全配置需求。目前广泛使用的下一代防火墙，配置的是安全策略技术。安全策略技术和包过滤技术的区别如下表所示：
 
比较内容
安全策略
包过滤
匹配条件
五元组、用户组、时间段、UTM策略等
五元组（源目IP、源目Port、协议）
应用场景
域内、域间、外部与设备本身
外部与设备本身
公共对象
可引用
不可引用
注：在上表中，公共对象指的是地址池、地址组等。
 
二、安全策略的内容
 
安全策略的作用就是对通过防火墙的数据流进行检验，符合安全策略的合法数据流才能通过防火墙。
 安全策略的内容有以下三点：
 1、策略匹配条件 策略匹配条件包括源目安全区域、源目IP地址、用户、服务、应用、时间段等。
 2、策略动作 策略动作要么是允许，要么是禁止。
 3、内容安全内容安全包括反病毒、入侵防御、URL过滤、文件过滤、内容过滤、应用行为控制、邮件过滤等。
 
三、安全策略配置
 
在华为系列防火墙中，安全侧路的配置流程如下所示：
 
 在华为系列防火墙中，所有的接口和策略都是基于区域（zone）的。在华为系列USG6000防火墙设备中，区域可以分为系统默认分类和自定义分类两种。
 系统默认分类又可以分为Local（本地）、Trust（信任）、**Untrust（外网）和DMZ（非军事化区）**四种。
 自定义分类就可以自定以区域的名称，但是必须给区域配置安全级别，安全级别范围是1-100，且不能和已有的区域的安全级别重复。
 在华为防火墙中，必须将接口划分为一个区域之后，该接口才可以使用。
 原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200/article/details/119117156

CORS全称Cross-Origin Resource Sharing, 即跨域资源共享，是一个由一系列HTTP头组成的系统，这些HTTP头决定浏览器是否阻止前端javascript代码获取跨域请求的响应。为什么需要CORS ？ 这是因为浏览器存在同源安全策略，当我们在当前域请求另外一个域的资源时，浏览器默认会阻止脚本读取它的响应，这时CORS就有了用武之地。
 
同源策略
 
同源策略是浏览器的一个重要的安全策略，它用于限制一个源的文档或其加载的脚本如何与另外一个源进行交互，它能够隔绝恶意文档，减少被攻击的媒介。
 
同源的定义
 
如果两个URL的协议、主机名和端口号都是相同的，那么这两个URL就是同源的，
 
下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:
 
URL
结果
原因
http://store.company.com/dir2/other.html
同源
只有路径不同
https://store.company.com/secure.html
非同源
协议不同
http://store.company.com:81/dir/etc.html
非同源
端口号不同
http://news.company.com/dir/other.html
非同源
主机名不同
 
也就是说当在http://store.company.com/dir/page.html这个网站中向https://store.company.com、http://store.company.com:81和http://news.company.com三个地址发起AXJX请求都会失败并且会报跨域的错误。这就是浏览器的同源策略，只能访问同源的数据。
 
源的修改
 
实际上，在一个源下可以修改当前源，比如在http://hello.word.com/index.html下，有一个脚本执行了以下语句：
 
document.domain = 'word.com'
 
那么当前网站能与http://word.com通过同源检测，即允许访问http://word.com的数据。需要注意的是document.domain只能设置为当前域的父域, 并且在设置之后，端口号会变成null，例如还是在http://hello.word.com/index.html下执行以下语句会失败：
 
document.domain = 'hello2.word.com'
 
跨源网络访问
 
事实上，不是所有跨源操作都被禁止。跨源操作主要分为三大类，跨源写操作、跨源资源嵌入和跨源读操作。
 
跨源写操作一般是被允许的。如超链接、重定向、表单提交。
跨源资源嵌入一般也是被允许的。如嵌入<img />、<video />、<audio />等。
跨源读操作不被允许，要实现跨源读操作，可以使用JSONP或CORS。
 
跨源访问
 
跨域（跨源）的解决方案主要有两种，JSONP和CORS, 当然还可以是代理或者反代理的手段。
 
JSONP
 
JSONP是一种hack，并不是一种官方解决跨域的手段，JSONP只能进行GET请求。它主要是利用<script>标签来发起请求，来达到突破浏览器同源策略的目的。
 
<html>
  <head>
    <title>JSONP</title>
  </head>
  <body>
    <script>
      function myCallback(res) {
        console.log("result:", res);
      }
    </script>
    <!-- 发起请求 -->
    <script src="http://localhost:8080/getData?callback=myCallback"></script>
  </body>
</html>
 
后端服务实现：
 
const http = require('http');

var data = {
    name: 'BruceLee',
    password: '123456'
};

const server = http.createServer((request, response) => {
    console.log('url:', request.url)
    if (request.url.startsWith('/getData')) {
       // 取到callback参数
        const callbackFn = request.url.split('=')[1];
        response.writeHead(200, {
            'Content-Type': 'application/json;charset=utf-8'
        });

        // 返回一段 JavaScript 代码
        response.end(`${callbackFn}(${JSON.stringify(data)})`);
    }
});

server.listen(8080, () => {
    console.log('The server is running at http://localhost:8080');
});

 
其原理非常简单：
 
前端使用<script>向http://localhost:8080/getData?callback=myCallback（这里的url携带callback参数是为了告诉后端，前端回调函数的名字是myCallback）请求一个js脚本，其实就是一段字符串。
后端取到它的callback参数，然后返回 myCallback({name: 'BruceLee',password: '123456'})。
前端script标签在拿到脚本后自然会执行脚本，也就是执行myCallback({name: 'BruceLee',password: '123456'}),所以会调用myCallback函数。
 
CORS
 
前文已指出：CORS是一套跨域资源共享机制，它基于HTTP头实现。那么什么场景需要用到CORS? 它具体是怎样工作？又使用了哪些HTTP头？
 
用到CORS的场景
 
有四类场景需要用到CORS，
 
使用XMLHttpRequest 或 Fetch 发起的跨源 HTTP 请求。
Web 字体 (CSS 中通过 @font-face使用跨源字体资源)。
WebGL 贴图。
使用 drawImage 将 Images/video 画面绘制到 canvas。
 
CORS工作过程
 
CORS对那些可能对服务器数据产生副作用的请求需要在请求之前发送一个OPTIONS预检请求，从而获知服务器是否允许该跨源请求。我们这里把那些 ‘不需要发预检请求’ 的请求称为简单请求，满足以下条件的请求被称为简单请求。
 
使用GET、HEAD、POST。
请求头仅包含允许人为设置的在Fetch规范定义的对CORS安全的字段集合。该集合为： 
  
Accept
Accept-Language
Content-Language
Content-Type （值仅限于text/plain, multipart/form-data,application/x-www-form-urlencoded）
 
请求中的任意XMLHttpRequestUpload 对象均没有注册任何事件监听器；
请求中没有使用 ReadableStream 对象。
 
简单请求会直接发起请求，请求头会携带origin表明当前源，响应头需要返回Access-Control-Allow-Origin: *, *通配符表示允许任何源请求数据，可以使用具体的值来限制访问数据的源，比如当为Access-Control-Allow-Origin: http://foo.example,则表示只允许http://foo.example这个域访问数据。必须注意：当xhr请求设置withCredentials为true，即请求携带cookies时，Access-Control-Allow-Origin的值不能为*，必须为具体的某个域, 而且响应头还必须存在Access-Control-Allow-Credentials: true，否则请求会失败。
 
与简单请求不同，“需预检的请求”要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器,以获知浏览器是否允许该请求。
 
首先在预检请求头中使用
 
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
 
Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法。
Access-Control-Request-Headers 告知服务器，实际请求将携带两个自定义请求首部字段：X-PINGOTHER 与 Content-Type。服务器据此决定，该实际请求是否被允许。
 
预检请求响应头会包含:
 
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
 
Access-Control-Allow-Methods表明服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求。
Access-Control-Allow-Headers 表明服务器允许请求中携带字段 X-PINGOTHER 与 Content-Type。
Access-Control-Max-Age 表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。
 
CORS HTTP头
 
上面已经介绍了一些用于CORS的HTTP头，下面再简单归纳一下：
 
CORS HTTP 请求头字段
 
Origin字段表明预检请求或实际请求的源站。
Access-Control-Request-Method用于预检请求。其作用是，将实际请求所使用的 HTTP 方法告诉服务器。
Access-Control-Request-Headers 用于预检请求。其作用是，将实际请求所携带的首部字段告诉服务器。
 
CORS HTTP 响应头字段
 
Access-Control-Allow-Origin 值指定了允许访问该资源的外域 URI。
Access-Control-Expose-Headers在跨源访问时，XMLHttpRequest.getResponseHeader()方法只能拿到一些最基本的响应头，Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。
Access-Control-Max-Age头指定了预检请求的结果能够被缓存多久。
Access-Control-Allow-Credentials,当请求的credentials设置为true时是否允许浏览器读取response的内容。当用在对preflight预检测请求的响应中时，它指定了实际的请求是否可以使用credentials。
Access-Control-Allow-Methods字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。
Access-Control-Allow-Headers字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。
 
参考文档
 
跨资源共享

浏览器的安全策略：
 1.同源策略
 2.多进程架构
 3.拦截恶意网址，基于“黑名单”
 4.支持EV SSL证书
 
同源策略是浏览器最核心也最基本的安全功能。域名、端口、http协议
 
浏览器的同源策略，限制了来自不同源的“document”或脚本，对当前“document”读 取或设置某些属性。
 
在浏览器中，＜script＞、＜img＞、＜iframe＞、＜link＞等标签都可以跨域加载资源，而不受同 源策略的限制。这些带“src”属性的标签每次加载时，实际上是由浏览器发起了一次 GET 请 求。不同于 ⅩMLHttpRequest 的是，通过 src 属性加载的资源，浏览器限制了 JavaScript 的权限， 使其不能读、写返回的内容。
 
多进程架构浏览器是指当发生崩溃时，只是Tab页发生崩溃。
 
目前各个浏览器的拦截恶意网址的功能都是 基于“黑名单”的。
 
常见的恶意网址分为两类：一类是挂马网站，这些网站通常包含有恶意的脚本如 JavaScript 或 Flash，通过利用浏览器的漏洞（包括一些插件、控件漏洞）执行 shellcode，在用户电脑中 植入木马；另一类是钓鱼网站，通过模仿知名网站的相似页面来欺骗用户。
 
恶意网址拦截的工作原理很简单，一般都是浏览器周期性地从服务器端获取一份最新的恶 意网址黑名单，如果用户上网时访问的网址存在于此黑名单中，浏览器就会弹出一个警告页面。
 
PS：PhishTank 是互联网上免费提供恶意网址黑名单的组织之一，它的黑名单由世界各地的志 愿者提供，且更新频繁。
 
主流浏览器都开始支持EⅤ SSL证书（Extended Ⅴalidation SSL Certificate），以增强对安全网站的识别。