OWASP TOP10 网络安全威胁整理

本贴最后更新于 2390 天前,其中的信息可能已经时移世易

缘起

  • 上月底到合肥参加了 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 = ?
  1. 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 漏洞。

场景

怎么做

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

04 失效的访问控制

描述

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

场景

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

怎么做

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

05 安全配置错误

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

06 敏感信息泄露

描述

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

如何做?

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

07 应对攻击防护不足

描述

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

怎么做

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

08 跨站请求伪造(CSRF)

描述

场景

  • 应用程序允许用户提交不包含任何保密字段的状态改变请求,如:
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 条
  • Java

    Java 是一种可以撰写跨平台应用软件的面向对象的程序设计语言,是由 Sun Microsystems 公司于 1995 年 5 月推出的。Java 技术具有卓越的通用性、高效性、平台移植性和安全性。

    3165 引用 • 8206 回帖
  • 安全

    安全永远都不是一个小问题。

    189 引用 • 813 回帖 • 2 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • nanolikeyou

    很好的文章,目前正在做相关的培训材料,开发人员确实不懂会有哪些安全问题。

  • zonghua

    第四点需要在编码中注意