软件系统安全问题

XSS漏洞

Xss 是 cross site scripting 的简称,指的是把JS代码存入目标服务器,然后其他客户端在访问服务器的时候,就会在客户端执行恶意JS,从而达到入侵或者盗取客户端信息的目的。

XSS分为反射型、DOM型、存储型

反射型:反射型一般是发送一个url给受害者,骗取用户点击,然后恶意代码就会在客户端执行。所以这也是为什么我们不能随意点击邮件里面的,或者不明目的的网站里面的链接的原因

DOM型:DOM型XSS是从另一个维度对XSS进行划分,反射型,或者存储型XSS都可以是DOM型的。它的特征就是恶意代码是通过操作DOM来达到恶意目的的而已

存储型XSS是在服务器的输入端,插入自己的恶意代码,然后把这些代码提交到服务器端。而后其他的客户端在访问服务器时,就会在客户端执行。因为现在很多的输入是接收富文本编辑框输入的,服务器端没有过滤的话存储型XSS更容易实现

解决方案:

  • 实现Filter类
  • 继承HttpServletRequestWrapper进行处理
  • 定义转义与反转义工具类
  • FilterConfig
  • 配置文件进行配置

Crsf

Csrf指的是 cross site request forgery 请求欺骗。指的是恶意代码,盗取用户的身份信息,然后利用此敏感信息发起对服务器的访问,获取有价值的信息,甚至盗取用户的银行信息。

黑客通过恶意手段让用户执行恶意脚本,访问恶意服务器,恶意服务器返回恶意js,盗取用户身份并发起对原服务器的访问,恶意服务器获取到服务器有价值的数据信息。

防范 CSRF 攻击可以遵循以下几种规则:

  • Get 请求不对数据进行修改
  • 不让第三方网站访问到用户 Cookie
  • 阻止第三方网站请求接口
  • 请求时附带验证信息,比如验证码或者 Token

解决方案:使用token,并对token属性进行甄别,以判断是否是真的客户。

  • SameSite

    可以对 Cookie 设置 SameSite 属性。该属性表示 Cookie 不随着跨域请求发送,可以很大程度减少 CSRF 的攻击,但是该属性目前并不是所有浏览器都兼容

  • Referer Check

    HTTP Referer是header的一部分,当浏览器向web服务器发送请求时,一般会带上Referer信息告诉服务器是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律,如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面,来判断是不是CSRF攻击

    但在某些情况下如从https跳转到http,浏览器处于安全考虑,不会发送referer,服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞,那么攻击者可以在其他网站注入恶意脚本,受害者进入了此类同域的网址,也会遭受攻击。出于以上原因,无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。

  • Anti CSRF Token

    目前比较完善的解决方案是加入Anti-CSRF-Token。即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token,并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值,会进行校验该请求当中的token和cookie当中的token值是否都存在且相等,才认为这是合法的请求。否则认为这次请求是违法的,拒绝该次服务。

    这种方法相比Referer检查要安全很多,token可以在用户登陆后产生并放于session或cookie中,然后在每次请求时服务器把token从session或cookie中拿出,与本次请求中的token 进行比对。由于token的存在,攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时,当某个页面消耗掉token后,其他页面的表单保存的还是被消耗掉的那个token,其他页面的表单提交时会出现token错误

  • 验证码

    应用程序和用户进行交互过程中,特别是账户交易这种核心步骤,强制用户输入验证码,才能完成最终请求。在通常情况下,验证码够很好地遏制CSRF攻击。但增加验证码降低了用户的体验,网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段,在关键业务点设置验证码

短信轰炸

登录验证码绕过

SQL注入

重复提交

目录遍历\穿越

任意文件上传

文件的上传对于服务器入侵是必须的。各种木马,webshell都要为黑客打开通道,因此,文件上传漏洞对于运维人员是致命的。要定时巡检,寻找可疑的文件。定期对服务器文件系统进行拍照,对比早先的快照以发现可疑文件。

解决方案:

  • 检查文件上传路径 (避免截断、解析漏洞、目录遍历)
  • 文件扩展名检测+MIME 验证,白名单机制(避免服务器以非图片的 文件格式解析文件)
  • 不在web目录、无脚本执行权限
  • 文件内容检查或者图片的二次渲染(避免图片中插入webshell)
  • 文件重命名(如随机字符串或者时间戳等方式,防止攻击者得到webshell路径)

DDOS攻击

目标服务器发起高压力的访问,导致服务器无法响应正常的访问

解决办法:

细调防火墙参数,以及对恶意访问IP的封堵。

点击劫持

解决办法:

X-Frame-Options 配置

X-FRAME-OPTIONS是一个 HTTP 响应头,在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe 嵌套的点击劫持攻击

web 容器上进行配置,添加 X-Frame-Options 响应头

  • DENY,表示页面不允许通过 iframe 的方式展示
  • SAMEORIGIN,表示页面可以在相同域名下通过 iframe 的方式展示
  • ALLOW-FROM,表示页面可以在指定来源的 iframe 中展示

弱口令

垂直越权

水平越权

参考链接:

web开发常见的几大安全问题 - pretty.sunshine - 博客园 (cnblogs.com)

再谈web系统安全 - 知乎 (zhihu.com)

本文标题:软件系统安全问题

文章作者:wsylp

发布时间:2021年05月08日 - 14:05

最后更新:2021年05月08日 - 17:05

原始链接:http://wsylp.github.io/2021/05/08/软件系统安全问题/

许可协议: 本文为 wsylp 版权所有 转载请保留原文链接及作者。

-------------本文结束感谢阅读-------------