OWASP TOP10 网络安全威胁整理

缘起

• 上月底到合肥参加了 owasp top10 网络安全宣讲。回来后结合在开发中遇到的问题整理并在部门内部做了一次分享，以下是分享内容。

01 注入

描述

• 注入漏洞发生在应用程序将不可信的数据发送到解释器。需要考虑任何向系统发送不信任数据的人。

场景

String query = 
"SELECT * FROM user WHERE user_id ='" 
+ request.getParameter("id") + "'";

• 在该案例中，构造 Web 请求时，将参数 id 设为"' or '1' = '1"，将得到下面的语句，绕过 user_id 的条件判断得到所有用户信息。

SELECT * 
FROM user
WHERE 
user_id = '' or '1' = '1'

• 避免 SQL 注入，一般使用 PreparedStatement 进行数据库操作，将 SQL 语句进行预编译，经过预编译后，传入的参数将被识别为带一对引号的字符串而不是带有 sql 关键字的语句。

怎么做

• 工作中使用到的 Mybatis 提供两种传参数写法：

1. select * from user where name = #{name};

• 此种方法得到的执行语句是：

select * from user where name = ?

2. select * from ${tableName};

• 此种方法得到的执行语句是：

select * from user 

• 假设 tableName 参数值为"user;delete from user;"
  那么会被解析为两条 SQL 语句并执行：

select * from user;delete from user;

• #{}与 ${}的区别可以简单总结如下：

1. #{}将传入的参数当成一个字符串，会给传入的参数加一对单引号
2. ${}将传入的参数直接显示生成在 sql 中，不会添加引号
3. #{}能够很大程度上防止 sql 注入，${}无法防止 sql 注入
4. ${}一般用于传输数据库的表名、字段名等
5. 能用#{}的地方尽量别用 ${}

02 失效的身份认证和会话管理

• Http 请求本身是无状态的，为了进行用户的身份认证，引入了有状态的 session 和 cookie。会话管理不善容易受到攻击，这些环节包括但不仅限于：用户退出登录、密码管理、超时、记住我、秘密问题、帐户更新等。

场景

• 机票预订应用程序支持 URL 重写，把会话 ID 放在 URL 里：

http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii。

• 该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道自己已经泄漏了自己的会话 ID。当他的朋友们使用上面的链接时，他们将会使用他的会话和信用卡。

怎么做

1. 设置合理的会话失效时间，如外部项目可以设置短一些，内部项目设置长一些。
2. 关闭浏览器时清除会话
3. 密码，会话 ID 等敏感数据使用加密链接传输，如使用 https 协议
4. 注销用户时注意清除会话
5. 用户密码加盐

03 跨站脚本 XSS

描述

• XSS：跨站脚本攻击，当应用程序发送给浏览器的页面中包括了用户提供的数据，而这些数据没有经过适当的验证或转义或者没有安全的 Javacript API,就会导致 XSS 漏洞。

场景

• http://10.66.30.142:9093 下演示

怎么做

1. 添加非法字符过滤器，过滤非法输入。
2. 对非法标签进行转换，如使用 Apache 的 commons-lang.jar 或者自己编写转换类,如：
   

• 参考资料：
• http://blog.csdn.net/catoop/article/details/50338259
• http://www.cnblogs.com/TankXiao/archive/2012/03/21/2337194.html
• http://blog.csdn.net/ghsau/article/details/17027893

04 失效的访问控制

描述

• 考虑系统的授权用户类型。用户是否受限于访问某些功能和数据？未经认证的用户是否允许访问任何功能或者数据？

场景

• 用户得到用户名以后，通过带参数请求数据服务，可以访问任何用户的资料信息

怎么做

• 设置登录验证
• 登录验证的基础上控制不同授权用户能访问的页面
• 给接口带上签名

05 安全配置错误

• 包括软件是否及时更新打补丁，是否有不必要的功能（端口服务网页权限账户等），默认账户密码，对应用服务器和应用框架是否进行了安全配置等。

06 敏感信息泄露

描述

• 考虑谁可以访问敏感数据及这些数据的备份。包括静态数据，传输中的数据及浏览器中的数据。
• 常用的敏感数据有：密码、信用卡、身份证号、用户个人信息及其他隐私数据。
• 场景：密码数据库使用未加盐的哈希算法去存储密码。一个文件上传漏洞使得黑客可以获取密码文件。所有这些未加盐哈希的密码通过彩虹表 crack。

如何做？

• 使用加盐的哈希算法去加密敏感数据
• 使用密码专用算法存储密码，如 bcrypt,pbkdf2 或者 scrypt

07 应对攻击防护不足

描述

• 任何具有网络访问权限的人都可以向你的应用程序发送一个请求。你的应用程序能检测到手工攻击和自动化攻击做出相应吗？

怎么做

• 检测攻击：是否做出了不合法的输入？是否频繁进行重复请求等
• 响应攻击：对异常账号进行禁用或监控，对某个 IP 或 IP 段进行自动阻止等。
• 及时打补丁

08 跨站请求伪造（CSRF）

描述

• 诱导用户提交伪造的请求，如果用户认证通过，那么攻击成功。
• 关于 xss 和 csrf 区别请进：https://www.zhihu.com/question/34445731?sort=created

场景

• 应用程序允许用户提交不包含任何保密字段的状态改变请求，如:

http://example.com/app/transferFunds?amount=1500
&destinationAccount=4673243243

• 因此，攻击者构建一个请求，用于将受害用户账户中的现 金转移到自己账户。然后攻击者在其控制的多个网站的图 片请求或 iframe 中嵌入这种攻击。

<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#"
width="0" height="0" />

• 如果受害用户通过 example.com 认证后访问任何一个攻击 者的网站，伪造的请求将自动包含用户的会话信息，授权 执行攻击者的请求。

怎么做

• 使用 Spring 自带的 CSRF 防御措施
• 考虑在所有 Cookie 中使用“SameSite = strict”标志，这在浏览器中越来越受到支持
• 关于 Strict：Strict 是最严格的防护，有能力阻止所有 CSRF 攻击。然而，它的用户友好性太差，因为它可能会将所有 GET 请求进行 CSRF 防护处理。例如：一个用户在 reddit.com 点击了一个链接（GET 请求），这个链接是到 facebook.com 的，而假如 facebook.com 使用了 Samesite-cookies 并且将值设置为了 Strict，那么用户将不能登陆 Facebook.com，因为在 Strict 情况下，浏览器不允许将 cookie 从 A 域发送到 B 域。
• 关于 SameSite 参考：http://bobao.360.cn/learning/detail/2844.html

09 使用含有漏洞的组件

场景

• Spring 远程代码执行—滥用 Spring 中语言表达式的实 现允许攻击者执行任意代码，有效的接管服务器等。

10 未受有效保护的 API

描述

• 目前 Web 应用程序越来越多的使用富客户端访问后台 API 接口。MicroService，Service，Endpoint 等 API 可能会收到各种常见的安全威胁。

场景

• 有一个互联网川创业公司提供了一个公开的 API，可以自动发动短信。这个 API 接受 JSON 格式的请求，其中有 transactionid 参数。API 把 transactionid 作为字符串来解析，并拼接到字符串 sql 查询中，没有做任何参数化或转义。

怎么做

• 参考前面 9 条