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或者自己编写转换类,如:
    b70483fa756342ac907d2aa14b19a264-12.png

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条

validate