有梦就去追
记录我的探索之路
目录
OWASP TOP10 网络安全威胁整理
OWASP TOP10 网络安全威胁整理
注：本贴于2017-09-10 09:20首次发布于[黑客派社区](https://ld246.com/article/1505006417072)，现将其同步至本人博客
缘起
- 上月底到合肥参加了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提供两种传参数写法：
- select * from user where name = #{name};
- 此种方法得到的执行语句是：
select * from user where name = ?
- select * from ${tableName};
- 此种方法得到的执行语句是：
select * from user
- 假设tableName参数值为"user;delete from user;"
那么会被解析为两条SQL语句并执行：select * from user;delete from user;
- #{}与${}的区别可以简单总结如下：
- #{}将传入的参数当成一个字符串，会给传入的参数加一对单引号
- ${}将传入的参数直接显示生成在sql中，不会添加引号
- #{}能够很大程度上防止sql注入，${}无法防止sql注入
- ${}一般用于传输数据库的表名、字段名等
- 能用#{}的地方尽量别用${}
02失效的身份认证和会话管理
- Http请求本身是无状态的，为了进行用户的身份认证，引入了有状态的session和cookie。会话管理不善容易受到攻击，这些环节包括但不仅限于：用户退出登录、密码管理、超时、记住我、秘密问题、帐户更新等。
场景
- 机票预订应用程序支持URL重写，把会话ID放在URL里：
http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii。
- 该网站一个经过认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们，并不知道自己已经泄漏了自己的会话ID。当他的朋友们使用上面的链接时，他们将会使用他的会话和信用卡。
怎么做
- 设置合理的会话失效时间，如外部项目可以设置短一些，内部项目设置长一些。
- 关闭浏览器时清除会话
- 密码，会话ID等敏感数据使用加密链接传输，如使用https协议
- 注销用户时注意清除会话
- 用户密码加盐
03跨站脚本XSS
描述
- XSS：跨站脚本攻击，当应用程序发送给浏览器的页面中包括了用户提供的数据，而这些数据没有经过适当的验证或转义或者没有安全的Javacript API,就会导致XSS漏洞。
场景
怎么做
- 添加非法字符过滤器，过滤非法输入。
- 对非法标签进行转换，如使用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条