web安全性分析

发布于 2022-03-09  171 次阅读


因为笔者是网安专业的,web安全也是一个比较重要的问题,所以来浅谈一下。

首先,我们要知道有哪些web安全问题。

XSS-跨站脚本攻击(Cross-Site Scripting)

定义

  • 是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点,进而添加一些代码,嵌入到web页面中去。使得别的用户访问都会执行相应的嵌入代码。
  • 从而盗取用户资料,利用用户身份进行某种动作或者对访问者进行病毒式侵害的一种攻击方式。

攻击类型

  • 反射型
    • 把用户输入的数据"反射"给浏览器端,这种攻击方式需要攻击者诱使用用户点击一个恶意链接,或者提交一个表单或者进入一个恶意网站,注入脚本进入会被攻击者的网站,可以获取用户隐私数据(如cookie)的脚本。
  • 存储型
    • 把用户输入的数据存储在服务器端,当浏览器请求数据时,脚本从服务器上传回并执行。这种XSS攻击具有很强的稳定性。
    • 场景:攻击者在论坛上写下一篇包含恶意 JavaScript 文章或评论,文章或评论发表后,所有访问该文章或评论的用户,都会在它们的浏览器中执行这段恶意的JavaScript代码。
  • 基于DOM
    • 通过恶意脚本修改页面的DOM结构,是纯粹发生在客户端的攻击。

XSS防御

  • 过滤转义字符
function filterXss(str){
   var s = "";
   if(str.length == 0) {
       return "";
  }
   s = str.replace(/&/g,"&");
   s = s.replace(/</g,"&lt;");
   s = s.replace(/>/g,"&gt;");
   s = s.replace(/ /g,"&nbsp;");
   s = s.replace(/\'/g,"&#39;");
   s = s.replace(/\"/g,"&quot;");
   return s;
}
  • 在cookie中设置 HttpOnly 属性,使得 JS 脚本无法读取 cookie 信息,防止劫取Cookie。
  • CSP内容安全策略

CSRF-跨站请求伪造(CROSS-SITE REQUEST FORGERY)

攻击原理:

  • 用户登录 A网站
  • A网站 确认身份,给客户端 Cookie
  • 用户在没有退出 A网站 的情况下,访问 B网站
  • B网站 页面向 A网站 发起一个请求
  • 根据 网站B 的请求,浏览器带着产生的 Cookie 访问 网站A

防御方法:

  • GET 请求不对数据进行修改
  • 不让第三方网站访问到用户的 Cookie SameSite:可以对 Cookie 设置 SameSite 属性。该属性设置 Cookie 不随着跨域请求发送,该属性可以很大程序减少跨站请求伪造,但是该属性目前并不是所有浏览器都兼容了。
  • 防止第三方网站请求接口 Refere验证:通过验证 Refere 来判断该请求是否是第三方网站发起的,在后台接到请求的时候,可以通过请求头中的 Refere 请求头来判断请求来源。 使用场景: 不仅防范跨站请求伪造,还可以防止图片盗链
  • 请求时附带验证信息,比如 验证码 或者 Token 验证码:跨站请求伪造攻击往往是在用户不知情的情况下构造了网络请求,而验证码会强制用户必须与应用进行交互,才能完成最终请求。 添加Token验证:服务器下发一个随机 Token,每次发起请求时将Token携带上,服务器建立拦截器验证Token是否有效。

危害:

利用用户登录态在用户不知情的情况下完成业务请求:

  • 盗取用户资金
  • 冒充用户发帖背锅
  • 损坏网站名誉

跟跨脚本攻击(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。

SQL注入

定义:

就是通过把 SQL 命令插入到 Web 表单提交 或 输入域名 或 页面请求的查询字符串,后台执行 SQL 语句时直接把前端传入的字段拿来做 SQL 查询。

SQL注入攻击方法:

  • 注入点的不同分类
    • 数字型注入
    • 字符型注入
  • 提交方式的不同分类
    • GET注入
    • POST注入
    • COOKIE注入
    • HTTP注入
  • 获取信息的方式不同分类
    • 基于布尔的盲注
    • 基于时间的盲注
    • 基于报错的注入

防御:

  • 不要使用动态SQL
    • 避免将用户提供的输入直接放入SQL语句中
    • 最好使用准备好的语句和参数化查询,这样更安全。
  • 不要把敏感数据保留在纯文本中
    • 加密存储在数据库中的私有/机密数据
    • 这样可以提供了另一级保护,以防攻击者成功地排出敏感数据。
  • 限制数据库权限和特权
    • 将数据库用户的功能设置为最低要求
    • 这将限制攻击者在设法获取权限时可以执行的操作
  • 避免直接向用户显示数据库错误
    • 攻击者可以使用这些错误消息来获取有关数据库的信息
  • 对访问数据库的Web应用程序使用Web应用程序防火墙(WAF)
    • 这为面向Web的应用程序提供了保护,它可以帮助识别SQL注入尝试
    • 根据设置,它还可以帮助防止SQL注入尝试到应用程序(以及数据库)
  • 定期测试与数据交互的Web应用程序
    • 这样做可以帮助捕获可能允许的SQL注入的新错误或回归
  • 将数据库更新为最新的的可用修补程序
    • 这可以防止攻击者利用旧版本存在的已知弱点/错误