常见的Web应用攻击手段
 
1.XSS攻击
 
XSS攻击即跨站点脚本攻击（Cross Site Script），指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
 
分类
 
 
1.1 反射型
 
攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击的目的
 
 
1.2 持久型
 
黑客提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击的目的
 
 
防护手段
 
 
1.3消毒
 
XSS攻击者一般都是通过在请求中嵌入恶意脚本达到攻击的目的，这些脚本是一般用户输入中不使用的，如果进行过滤和消毒处理，即对某些html危险字符转义就可以让绝大部分攻击失败
 
 
1.4HttpOnly
 
浏览器禁止页面JavaScript访问带有HttpOnly属性的Cookie，可以防止Cookie中的数据被窃取
 
 
2.注入攻击
 
分类
 
 
2.1 SQL注入攻击
 
攻击者在HTTP请求中注入恶意SQL命令（drop table users;），服务器用请求参数构造数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。
 
 
2.2 OS注入攻击
 
 
防护手段
 
 
2.3 消毒
 
通过正则匹配，过滤请求数据中可能注入的SQL
 
 
2.4 参数绑定
 
使用预编译手段，绑定参数是最好的防SQL注入方法。目前许多数据访问层框架，如IBatis，Hibernate等，都实现SQL预编译和参数绑定，攻击者的恶意SQL会被当做SQL的参数，而不是SQL命令被执行。
 
 
3.CSRF攻击
 
攻击者通过跨站请求，以合法用户的身份进行非法操作，如转账交易、发表评论等；
 CSRF的主要手法是利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。其核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份。
 
防护手段
 
 
3.1 Token验证
 
通过在请求参数中增加随机数的办法来阻止攻击者获得所有请求参数：在页面表单中增加一个随机数作为Token，每次响应页面的Token都不相同，从正常页面提交的请求会包含该Token值，而伪造的请求无法获得该值，服务器检查请求参数中Token的值是否存在并且正确以确定请求提交者是否合法
 
 
3.2 验证码
 
验证码则更加简单有效；
 请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。但是输入验证码是一个糟糕的用户体验，所以请在必要时使用，
 
 
3.3 Referer check
 
HTTP请求头的Referer域中记录着请求来源，可通过检查请求来源，验证其是否合法。
 

 IPS（入侵防护系统）和WAF（Web应用防护系统）两款产品有不同的使用场景，随着Web应用发展带来的复杂度，对安全性要求也日趋增高，Waf的出现是顺应了市场和技术的需要。
 
 Web应用防护无疑是一个热门话题。由于技术的发展成熟和人们对便利性的期望越来越高，Web应用成为主流的业务系统载体。在Web上“安家”的关键业务系统中蕴藏的数据价值引起攻击者的青睐，网上流传的Web漏洞挖掘和攻击工具让攻击的门槛降低，也使得很多攻击带有盲目和随机性。比如利用GoogleHacking原理的批量查找具有已知漏洞的应用程序，还有SQL批量注入和挂马等。但对于重要的Web应用（比如运营商或金融），始终有受利益驱动的黑客进行持续的跟踪。
 
 如果说传统的“大而全”安全防护产品能抵御大多数由工具产生的攻击行为，那么对于有针对性的攻击行为则力不从心。而WAF正是应需求而生的一款高端专业安全产品，这也是市场需求细化的必然趋势。但由于其部署和功能方面与IPS有类似，有人提出疑问，为什么不能用IPS，或者说WAF与IPS有什么异同？谁更适合保护Web服务器？
 
 这些疑问其实是有道理的，差异化的产生在于高端需求是不同的，从而需要细化功能贴合具体需求和符合应用现状的产品，这也是用户需求是随着业务自身的发展所决定的。
 
 保镖和保安
 
 为了更好的理解两款产品差异性，我们先用这个保镖（WAF）和保安（IPS）比喻来描述。
 
 大楼保安需要对所有进出大楼人员进行检查，一旦发现可疑人员则禁止他入内，但如果混进“貌似忠良”的坏人去撬保险柜等破坏行为，大楼保安是无能为力的。
 
 私人保镖则是指高级别、更“贴身”的保护。他通常只保护特定的人员，所以事先需要理解被保护人的身份、习惯、喜好、作息、弱点等，因为被保护人的工作是需要去面对不同的人，去不同的场合，保镖的职责不能因为危险就阻止、改变他的行为，只能去预见可能的风险，然后量身定做合适的保护方案。
 
 这两种角色的区别在于保安保护的是整个大楼，他不需要也无法知道谁是最需要保护的人，保镖则是明确了被保护对象名单，需要深刻理解被保护人的个性特点。
 
 通过上面的比喻，大家应该明白两者的之所以会感觉相似是因为职责都是去保护，但差异在于职能定位的不同。从技术原理上则会根据定位来实现。下面通过几个层面来分析WAF和IPS的异同。
 
 事件的时间轴
 
 对于安全事件的发生，有三个时间点：事前、事中、事后。传统的IPS通常只对事中有效，也就是检查和防护攻击事件，其他两个时间点是WAF独有的。
 
 事前是指能在事件发生之前通过主动扫描检测Web服务器来发现漏洞，通过修复Web服务器漏洞或在前端的防护设备上添加防护规则等积极主动手段来预防事件发生。事后则是指即使Web服务器被攻击了，也必须有网页防篡改功能，让攻击者不能破坏网站数据。
 
 为什么不能具备事中的100%防护能力？其实从以下几个方面就知道对于事中只能做到相对最佳防护而不能绝对，因为：
 
 1. 软件先天是有缺陷的，包括应用到第三方的组件和函数库无法控制其安全性；
 
 2. 应用程序在更新，业务是持续发展的、动态的，如果不持续监控和调整安全策略，也是会有疏漏的；
 
 3. 攻击者永远在暗处，可以对业务系统跟踪研究，查找漏洞和防护缺陷，用各种变形繁杂的手法来探测，并用于攻击；
 
 4. 任何防护设备都难以100%做到没有任何缺陷，无论是各种算法还是规则，都是把攻击影响降低到最小化。
 
 所以需要用一个可闭环又可循环的方式去降低潜在的威胁，对于事中疏漏的攻击，可用事前的预发现和事后的弥补，形成环环相扣的动态安全防护。事前是用扫描方式主动检查网站并把结果形成新的防护规则增加到事中的防护策略中，而事后的防篡改可以保证即使疏漏也让攻击的步伐止于此，不能进一步修改和损坏网站文件，对于要信誉高和完整性的用户来说，这是尤为重要的环节。
 
 如果仅仅是对于事件的时间轴有区别，那么还是可以采用其他产品来进行辅助，但关键的是事中的防护也是有深度的差异，那么下面我们来谈谈对于事中的差异。
 
 纵深度差异
 
 事中，也就是实时防护，两者的区别在于一个是纵横度，一个是深度。IPS凸显的优势在于纵横度，也就是对于网络中的所有流量进行监管，它面对的是海量数据，处理TCP/IP模型中网络流量从物理层到应用层是逐层递交，IPS主要定位在分析传输层和网络层的数据，而再往上则是复杂的各种应用层协议报文，WAF则仅提供对Web应用流量全部层面的监管。
 
 监管层面不同，如果面对同样的攻击，比如SQL注入，它们都是可以防护的，但防护的原理有区别，IPS基本是依靠静态的签名进行识别，也就是攻击特征，这只是一种被动安全模型。如下是一个Snort的告警规则：
 
 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS （msg:“SQL Injection - Paranoid”; flow:to_server,established;uricontent:“.asp”;pcre:“/（\%27）|（‘）|（--）|（%23）|（#）/i”; classtype:Web-application-attack; sid:9099; rev:5;
 
 这里主要是检查在SQL注入中提交的元字符，包括单引号（ ）和双横（ -- ），从而避免注入1 or 1=1—之类的攻击发生，但同时又要考虑这些元字符转换成Hex值来逃脱过滤检查，于是又在规则里增加了其对应的十六进制编码后的字符串。
 
 当然，要从签名特征来识别攻击要考虑的东西还很多，不仅元字符还有SQL关键字，包括：select insert update等，以及这些关键字的大小写变形和拼接，利用注释逃脱过滤，如下所示例：
 
 使用大小写混杂的字符：SeLecTfRom“
 
 把空格符替换为TAB符或回车符：select[TAB]from
 
 关键词之间使用多个空格：select from
 
 字符串的数值编码：0x414141414141 或 0x41004100410041004100
 
 插入被数据库忽略的注释串：sel/**/ectfr/**/om select/**/ from
 
 使用数据库支持的一些字符串转换功能：char（65）或chr（65）
 
 使用数据支持的字符串拼接操作：sel+ect +fr+om’”、“‘sel||ect ||fr||om
 
 可以设想一下，如果要检测以上的变形字符后的攻击则需要增加相应的签名特征，但更重要的是要充分考虑转换编码的种类，上面示例的snort的规则把可疑字符以及其转换后的Hex值放入同一条规则里检查，如果对于变形后繁多的攻击种类，这是滞后的并且会造成签名臃肿。
 
 对于比较粗浅的攻击方式两者都能防护，但市面上大多数IPS是无法对报文编码做多重转换的，所以这将导致攻击者只需构建诸如转换编码、拼接攻击语句、大小写变换等数据包就可绕过输入检查而直接提交给应用程序。
 
 而这恰恰又是WAF的优势，能对不同的编码方式做强制多重转换还原成攻击明文，把变形后的字符组合后在分析。那为什么IPS不能做到这个程度？同样还有对于HTTPS的加密和解密
 
 产品架构
 
 大家知道IPS和WAF通常是串联部署在Web服务器前端，对于服务器和客户端都是透明的，不需要做任何配置，似乎都是一样的组网方式，其实有很大差异。首先我们看看市面主流WAF支持的部署方式：
 
 l 桥模式
 
 l 路由模式
 
 l 反向代理
 
 l 旁路模式（非串联）
 
 这两者串联部署在Web服务器前端时，市面上的大多数IPS均采用桥模式，而WAF是采用反向代理模式，IPS需要处理网络中所有的流量，而WAF仅处理与Web应用相关的协议，其他的给予转发，如下图：
 
 桥模式和反向代理模式的差异在于：桥模式是基于网络层的包转发，基本都没有协议栈，或只能简单的模拟部分协议栈，分析网络报文流量是基于单包的方式，所以要处理分片报文、数据流重组、乱序报文、报文重传、丢包都不具备优势。同时网络流量中包括的协议种类是非常多的，每种应用层协议都有自身独特的协议特征和格式要求，比如Ftp、SSH、Telnet、SMTP等，无法把各种应用流量放到应用层协议栈来处理。
 
 WAF系统内嵌的协议栈是经过修改和优化的，能完全支持Http应用协议的处理，这意味着必须遵循RFC标准（Internet Requests For Comments）来处理Http报文，包括如下主要RFC：
 
 l RFC 2616 HTTP协议语法的定义
 
 l RFC 2396 URL语法的定义
 
 l RFC 2109 Cookie是怎样工作的
 
 l RFC 1867 HTTP如何POST，以及POST的格式
 
 RFC中对Http的request行长度、URL长度、协议名称长度、头部值长度等都是有严格要求的，以及传输顺序和应用格式，比如Html参数的要求、Cookie的版本和格式、文件上传的编码 multipart/form-data encoding等，这些应用层内容只能在具有完整应用层协议栈的前提下才可正确识别和控制，对于不完整的丢包，重传包以及伪造的畸形包都会通过协议校验机制来处理。
 
 上一节提到的WAF对Https的加解密和多重编码方式的解码正是由于报文必须经过应用层协议栈处理。反之，IPS为什么做不到？是由于其自身的桥模式架构，把Http会话”打碎“成多个数据包在网络层分析，而不能完整地从应用层角度来处理和组合多个报文，并且应用层协议繁多，全部去支持也是不现实的，产品的定位并不需要这样。下一节的学习模式更是两者的截然不同的防护机制，而这一机制也是有赖于WAF的产品架构。
 
 基于学习的主动模式
 
 在前面谈到IPS的安全模型是应用了静态签名的被动模式，那么反之就是主动模式。WAF的防御模型是两者都支持的，所谓主动模式在于WAF是一个有效验证输入的设备，所有数据流都被校验后再转发给服务器，能增加应用层逻辑组合的规则，更重要的是具备对Web应用程序的主动学习功能。
 
 学习功能包括：
 
 1. 监控和学习进出的Web流量，学习链接参数类型和长度、form参数类型和长度等；
 
 2. 爬虫功能，爬虫主动去分析整个Web站点，并建立正常状态模型；
 
 3. 扫描功能，主动去扫描并根据结果生成防护规则。
 
 基于学习

             
说明：该文档基于MatriXay
和Acunetix
等安全测试工具的测试报告。 
 
 
 
 
 
一  漏洞级别：紧急、高危、中危、低危、信息。前三种级别的漏洞对网站的危害较大。
 
 
 
 
 
二  漏洞类型：（漏洞级别）
 
 
a、跨站点脚本（XSS）（紧急）
 
 
b、框架注入（高危）
 
 
c、链接注入（高危）
 
 
d、CSRF攻击
 
 
e、跨域Flash文件访问资源（中危）
 
 
f、启用了不安全的HTTP方法（中危）
 
 
g、会话Cookie中缺少HttpOnly属性（低危）
 
 
h、敏感文件、测试文件（低危）
 
 
i、服务器版本泄露（低危）
 
 
 
 
 
三 漏洞的描述与防御
 
 
1 跨站点脚本（XSS）
 
 
     描述：恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。
 
 
 
 
 
     防御：避免XSS攻击的方法有很多，比如过滤敏感字符、将敏感字符转义等。实际项目中采用了OWASP的一个开源的项目AntiSamy来彻底解决XSS攻击问题。AntiSamy是一个可以确保用户输入的HTML、CSS、JavaScript符合规范的API。它确保了用户无法在HTML中提交恶意代码，而这些恶意代码通常被输入到个人资料、评论等会被服务端存储的数据中。
 
 
参考：http://download.csdn.net/detail/weixin_36087172/9893927
 
 
 
 
 
2 框架注入
 
 
描述：攻击者有可能注入含有恶意内容的 frame 或 iframe 标记。如果用户不够谨慎，就有可能浏览该标记，却意识不到自己会离开原始站点而进入恶意的站点。之后，攻击者便可以诱导用户再次登录，然后获取其登录凭证。
 
 
防御：过滤客户端提交的危险字符，客户端提交方式包含GET、POST、COOKIE、User-Agent、Referer、Accept-Language等。建议过滤出所有以下字符：
            |（竖线符号）
            & （& 符号）
            ;（分号）
            $（美元符号）
            %（百分比符号）
            @（at 符号）
            '（单引号）
            "（引号）
            \'（反斜杠转义单引号）
            \"（反斜杠转义引号）
            <>（尖括号）
            ()（括号）
            +（加号）
            CR（回车符，ASCII 0x0d）
            LF（换行，ASCII 0x0a）
            ,（逗号）
            \（反斜杠）
 
 
 
 
 
3链接注入
 
 
   描述：“链接注入”是修改站点内容的行为，其方式为将外部站点的 URL 嵌入其中，或将有易受攻击的站点中的脚本 的 URL 嵌入其中。将 URL 嵌入易受攻击的站点中，攻击者便能够以它为平台来启动对其他站点的攻击，以及攻击这个易受攻击的站点本身。
 
 
   防御：同框架注入。
 
 
4 CSRF攻击
 
 
   描述：CSRF（Cross-site request forgery跨站请求伪造，也被称为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
 
 
   防御：表单中添加校验token，该token不保存在cookie中。即：由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。
 
 
 
 
 
5 跨域Flash文件访问资源
 
 
描述：Web页面资源是否能从不同域的Flash应用程序进行访问。
 
 
防御：修改根目录crossdomain.xml文件 例:
 
 
<allow-access-from domain="*.eduyun.cn" to-ports="*"/>
 
 
6  启用了不安全的HTTP方法
 
 
描述：HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法；HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。这些方法对可以对web服务的上传、删除、修改等操作，从而对服务产生威胁。
 
 
防御：两种方法：1 WebDAV有权限控制 2 屏蔽上述新增方法。一般在不需要上述HTTP1.1新增方法的情况下。常用第二种方法。
 
 
第二种方法又分为两种办法，1是修改web服务的web.xml，2是修改tomcat的web.xml,这样对tomcat中所有服务都有效。
 
 
示例：
 
 
   <security-constraint>
 
 
    <web-resource-collection>
 
 
        <web-resource-name>fortune</web-resource-name>
 
 
        <url-pattern>/*</url-pattern>
 
 
        <http-method>PUT</http-method>
 
 
        <http-method>DELETE</http-method>
 
 
        <http-method>HEAD</http-method>
 
 
        <http-method>OPTIONS</http-method>
 
 
        <http-method>TRACE</http-method>
 
 
    </web-resource-collection>
 
 
    <auth-constraint></auth-constraint></security-constraint>
 
 
 
 
 
7 cookie中缺少HttpOnly属性
 
 
描述：应用程序测试过程中，检测到所测试的Web应用程序设置了不含“HttpOnly”属性的会话cookie。有可能被客户端恶意脚本访问，造成信息泄露。
 
 
防御：对于要依赖于cookie验证的web服务来说，HttpOnly cookies是一个解决方案，在支持HttpOnly cookies的浏览器中（IE6以上，FF3.0以上），javascript是无法读取和修改HttpOnly cookies，或许这样可让网站用户验证更加安全。示例： cookie.setHttpOnly(true);
 
 
 
 
 
8 敏感文件、测试文件（低危）
 
 
描述：Web应用程序显露了某些文件名称，此信息可以帮助攻击者对站点进一步的攻击。比如根目录下的测试文件，像某些test.jsp、a.jsp 等等。
 
 
防御：不需要保留的，应该删除掉。如果确实需要，应该修改成更复杂的命名。
 
 
9 服务器版本泄露。
 
 
   描述：某些报错、404可能会泄露服务器的版本信息，从而有可能会提供一些信息给攻击者，造成信息不安全的情况。
 
 
   防御：404,500等页面，以及所有的提示找不到的页面或者方法，都应该屏蔽，跳转到相应的报错提示页面。注意配置tomcat的404页。   
 
 
   参考：   http://blog.csdn.net/weixin_36087172/article/details/76671572  
 
 
 
 四 提示
 
 
   
 
 
   为了web服务避免安全攻击，紧急、高危、中危级别的漏洞应该及时修复。另外对于版本特别老旧的js，jquery,以及服务器，最好更换到更高的版本，以防安全隐患。对于一些敏感信息，如用户名，密码，email地址不要出现在url中。
 

 背景
 近些年来，国内政府和企业网站被篡改的类似黑客攻击入侵事件频出，造成的社会影响及经济损失巨大，越来越多的企事业单位高度重视Web应用安全。
 
其中，黑客针对Web应用资产发起的弱口令攻击尤为常见。
 
即黑客通过已有的大量账号信息，快速批量验证能够访问目标Web资产的账号。这种攻击方式由于利用难度不大，且一旦获取到目标系统的弱口令，进入目标Web系统，可以扩大攻击者的攻击范围，被广为使用。
 
【学习资料】
 
常见的Web弱口令攻击场景
 
一类是为了获取目标应用的访问权限，对账号(如Admin、Root等)的密码进行尝试；
 
另一类是为了获取到目标系统的用户群体信息，如通过对大量手机号的尝试登录，碰撞目标系统可能存在的用户群体，并对碰撞出的用户群，进行有针对性的商业活动。
 
Web弱口令攻击手法
 
Web弱口令常见的攻击手法有：准备攻击字典、执行爆破。
 
准备攻击字典
 
进行Web弱口令攻击前，黑客需要预先准备攻击用的账号/密码字典。最常见的途径，是通过之前各大网站泄露的口令，进行分类统计和汇总。
 
2021年初NordPass发布了2020年的弱口令调查统计结果，第一位的还是连续多年霸榜的123456。
 
 图3-1 弱口令排名
 
基于历年外泄的用户密码信息，很多攻击者会按照不同的维度，整理出常见用户和常用密码的字典。
 
 图3-2 口令字典样例
 
很多Web应用系统出厂时，提供的默认账号口令，也会成为攻击者利用的对象。
 
 图3-3 部分常用安全设备弱口令
 
对特定攻击目标的账号和密码，黑客可利用社工手段进行收集和生成，如对用户账号的信息收集，通过社交站点、脉脉、领英、招聘类网站等，都可以或多或少找到相关目标的人员信息。【网络安全学习资料·攻略】
 
 图3-4 某站点可搜索到的人员信息
 
一般情况下，能够获取到企业人员信息，企业内各Web系统的账号基本也能获取到。虽然各家企业的账号命名方式略有不同，但是据统计，最常使用的是姓名的全拼。
 
而且，存在部分公司在开通员工账号时，会使用统一的初始密码，且没有强制要求账号在初始登录后就修改密码。
 
 图3-5 某系统默认密码
 
一些企业会使用一种常见也被广泛使用的口令生成方式，是根据目标系统所在公司名称、域名等内容，进行有针对性的拼接生成。
 
 图3-6 口令生成工具
 
3.2 执行爆破
 
字典准备完成之后，实施攻击的核心是查找和抓取登录接口，将字典内容填入接口内，进行快速的登录尝试，根据目标站点的响应内容，判断攻击结果。
 
相关接口的来源比较多，部分场景下，直接通过Web页面内的登录/注册页面就可以定位到，某些则可能需要目录爆破以及搜索JS内容才能获取到。
 
 图3-7 获取登录接口
 
如果相关登录接口需要调整的内容不多，可直接利用Burpsuite之类的发包工具完成，或者需要预先编写脚本，对要使用的登录信息进行预处理，如对用户名进行Base64编码，以满足服务端对此接口的接收要求。
 
 图3-8 Burpsuite爆破攻击
 
常见应对方式
 
针对长久以来的Web弱口令攻击问题，防守方也形成了众多的防御方法。
 
4.1 口令生成强制安全策略
 
在口令生成的时候，需要满足一定的安全策略，才会被系统接受，如常见的口令生成安全策略：
 
 
 
1）长度大于8；
 
 
2）包含数字和字母；
 
 
3）字母包含大小写；
 
 
4）包含特殊字符。
 
 
4.2 口令管理安全策略
 
常见的口令安全管理策略，主要有以下方面：
 
 
 
1）定期修改密码，如每三月一改；
 
 
2）建立统一账号登录系统；
 
 
3）双因子认证；
 
 
4）验证码；
 
 
上述的口令生成策略并不能完全规避弱口令的生成，比如Qwer1234就符合上述的生成策略，但是因为其“便利”的键盘顺序，为很多人所使用。
 
口令管理安全策略，如果实现或者管理不当，同样会出现问题。定期修改的密码，新密码与旧密码相比，可能只是最后的尾数做了修改；
 
双因子的具体实现中，如果双重验证因子没有进行有效的限制，同样存在被爆破的可能；验证码的自动识别以及人工打码，已经形成了一条黑色产业。
 
Web应用隔离防护
 
钛星Web应用隔离系统采用了另外一种防护方式，将用户与实际的Web应用系统隔离，对用户隐藏与Web服务端的交互细节，能有效防护针对Web应用的弱口令攻击行为。
 
5.1 架构说明
 【网络安全学习资料·攻略】
 
 
图5-1 Web应用隔离架构
 
在架构上，Web应用隔离系统串接于用户浏览器与真实的Web应用服务器之间，对用户透明，用户端浏览器不需做任何配置上的调整。
 
Web隔离系统与Web服务器之间保持原有的访问交互方式，对用户提供原有服务的“镜像”，隐藏服务端的所有代码层面的细节，基于用户在浏览器端的行为与真实服务器进行交互。
 
基于这种架构，Web应用隔离主要完成两方面的任务：
 
任务一，接收用户在浏览器上触发的鼠标键盘操作事件及Get请求，将鼠标键盘事件转化成真实的请求（比如Post、Put等），以及Get请求，发送给Web服务器；
 
任务二，将源网站所有的活动脚本及API在Web隔离平台执行，重构网页内容，返回给用户浏览器，即用户侧浏览器上，隔离系统展示的Web页面，与用户直接访问原网站相同，但是不含源网站活动脚本及API等信息。
 
5.2 防御原理
 
传统的防御方式，一是增加身份验证接口的访问难度，从多个维度上，对用户身份进行鉴定，只有多个维度都满足条件，才会允许通过。二是不断对来自用户的请求进行检测，当发现有大量的异常请求时，再通过安全设备对相关请求进行拦截。
 
钛星的Web应用隔离防护产品，采用了不同的防御方式。
 
5.2.1 脚本及API隐藏
 
Web弱口令攻击的前提及核心是能够找到口令输入的接口，并且接口的响应内容，能够对账号或密码的可用状态进行区分。
 
Web应用隔离系统会把Web应用服务器的内容，以视觉流的方式，发送给用户端的浏览器，隐藏真实的活动脚本及API，让攻击者无法探测到具体的API，从而无法进行攻击。
 
正常访问模式下，JS代码中通常包含了大量的接口地址和参数，甚至有的站点因为配置不当，导致Webpack信息对外可见。
 
 图5-2 JS信息暴露
 
Web应用隔离模式下，相关JS代码止步于Web应用隔离服务端，Web用户的浏览器侧只保存有少量客户浏览器与隔离服务端的交互JS。
 
 图5-3 隔离模式源码差异
 
5.2.2 HTTP请求类型过滤
 
即使通过某种方式，攻击者拿到了真实服务器的认证API，也无法利用。
 
隔离系统只接受Get请求和用户产生的鼠标键盘操作事件，其它类型如Post、Option、Head等，隔离平台不接受并丢弃，不会传递相关请求到真实Web服务器，这将拦截大部分的爆破流量。【网络安全学习资料·攻略】
 
 图5-4 构造请求数据被拦截
 
5.2.3 请求URL加密
 
Web应用隔离模式下，Web浏览器与Web应用隔离设备之间进行交互，以HTTP Get的方式进行。
 
即Web应用隔离设备只接收客户浏览器发送过来的Get请求，其它类型的请求不再处理。且URL采用了加密，对于通过URL实现的一些攻击方式实现了完全免疫。
 
 图5-5 URL加密工作原理
 
下图为加密后的效果，浏览器地址栏，原有的URL地址中，Host保持不变，但其后的Path内容，以加密字符串的方式展示和使用，原有URL不再可用。
 
 图5-6 URL加密效果
 
5.2.4 弱口令输入检查
 
Web应用隔离系统能够对页面中的密码输入进行识别，并对输入的口令进行检测。当检测到弱口令时，可根据系统预置安全策略(阻止、提示用户修改、仅记录)进行处理。这种方式不需对业务系统进行改造，可有效防范和检测弱口令的生成和使用。
 
综上，Web应用隔离系统可以完全防护对Web应用系统的弱口令攻击，从根本上解决问题，让服务方从容应对外部安全威胁，为Web用户提供安全稳定的服务。
 
最后
 
关注我，持续更新！！！私我获取【网络安全学习资料·攻略】