网络攻击与防范

593 阅读5分钟

XSS跨站脚本攻击

一些漏洞

  • html文本中被注入script标签
  • js中拼接的数据突破了原有限制如字符串被闭合
  • href/src中包含了javasript:等可执行代码 总之,大多来自于将用户输入的文本进行了HTML插入或者直接无转义的执行

分类

储存型

攻击步骤:存-取-运行
1.恶意代码提交到数据库中
2.用户打开网站时服务端将恶意数据取出渲染到了前端
3.恶意代码被执行来窃取数据,冒充用户交互,调用网站接口执行操作等

反射型

攻击步骤:构建URL-用户点击了恶意URL-URL数据被渲染或执行
1.构造特殊恶意URL
2.用户打开恶意URL,恶意代码被拼接到HTML返给浏览器
3.浏览器将URL恶意代码取出运行,恶意代码被执行

DOM型

1.构造恶意URL
2.用户打开恶意URL
3.JS代码编程层面取出了URL数据并执行

预防

预防攻击者提交恶意代码-输入过滤

  • 前端使用escapeHTML()过滤会被直接构建请求的方式绕过。
  • 后端过滤的转义会使得再数据展示使用时造成一些麻烦如字符串长度获取,数据变量化后渲染。
  • 所以输入过滤并不可靠,对通过URL构建的攻击也难以奏效

预防浏览器执行恶意代码-防止HTML注入

  • 纯前端渲染,将代码与数据分隔(前后端分离已经做到了这一点)
  • 对HTML中添加的数据做充分的转义
    • HTML对HTML直接加入的内容简单转义可以奏效,但是cssStyle,aHref等作用不大。需要针对不同上下文做不同转义。不过Java服务端渲染的一些库已经做的非常完善。
    • Vue/React工程只要不使用v-html/dangerouslySetInnerHTML,框架已经帮助预防了dom型攻击。
    • dom的内联事件监听,js计时器延迟事件都会将字符串解析为可执行代码。

其他的防范措施

Content Security Policy

CSP
严格的 CSP 在 XSS 的防范中可以起到以下的作用:

  • 禁止加载外域代码,防止复杂的攻击逻辑。
  • 禁止外域提交,网站被攻击后,用户的数据不会泄露到外域。
  • 禁止内联脚本执行(规则较严格,目前发现 GitHub 使用)。
  • 禁止未授权的脚本执行(新特性,Google Map 移动版在使用)。
  • 合理使用上报可以及时发现 XSS,利于尽快修复问题。 其他措施
  • HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注入后也无法窃取此 Cookie。
  • 验证码:防止脚本冒充用户提交危险操作。

CSRF跨站请求伪造

初识

攻击流程

1.用户登陆了网站a,登陆凭证被保留在cookie
2.用户点击了恶意连接,连接中向网站a发送了请求,浏览器默认添加了cookie

举例

<img src="http://bank.example/withdraw?amount=10000&for=hacker" > 用户打开了含有这个标签的页面,会向src发送一个get请求。

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script> 

伪造了post请求

<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
  重磅消息!!
<a/>

较为离谱的诱导链接

特点

  • 攻击发生在三方网站,无法阻止攻击的发生
  • 攻击冒用了登陆凭证但无法获取其凭证
  • 通常是跨域的,本域一般来自可以发图片和链接的论坛形式

防护

针对跨域的防护

  • http中,异步请求带有两个Header字段标记来源域名,且不能被自定义
    • Orgin Header :如果存在可以直接使用其判断,302重定向和IE11(因为它跟别人同源定义不同)不会带有。
    • Referer Header :HTTP协议规定使用其记录请求来源,但是由浏览器实现,无法保证浏览器没有漏洞。且有方法隐藏此字段,如a标签的referrerpolicy="no-referrer"
    • 两个字段都没有且没有做其他防护,这时候建议阻止此请求。
  • Cookie的Samesite属性可以设置只有在同站请求时发送cookie(同站是有效顶级域名的下一级相同的域名,如子域名算同站不算同源)且浏览器普及性不佳。
  • 阻止了搜索引擎的链接且无法防护非同源的攻击,这种方法并不完善

针对攻击只是冒用无法获取的防护

  • CSRF token
    • 将seesion中拿到的token遍历加入页面所有的正确a/from中而不是存在cookie
    • seesion耗费服务器资源,可以使用分布式校验
  • 使用验证码或者二级密码来起到csrf token的效果,也是广泛使用的方法
  • 双重cookie验证
    • 将cokkie取出加入到接口参数中,验证请求头cookie与参数cookie是否相等
    • cookie必须种在跟域名下来确保子域名可以拿到cookie而不误伤
    • 子域名被XSS后可以更改根域名cookie而进一步发生csrf攻击

其他攻击

  • http劫持-https防范
  • DNS劫持,没啥好办法
  • 点击劫持,通过透明iframe来让用户点了视觉A但透明的B转账按钮-禁用被iframe显示
  • Dos攻击-黑名单
  • 恶意文件,上传.php并尝试访问