XSS，CSRF，SSRF 之间的区别

一.XSS

XSS是跨站脚本攻击，攻击者通过篡改网页，嵌入恶意脚本程序，用户在浏览网页时，会触发恶意操作。

例如：攻击者可以获取用户敏感信息，如：cookie，sessionid，密码等，或者控制用户的浏览器进行恶意操作。

xss本质上是恶意代码未过滤，与正常的代码混合在一起。

我是这么理解的：我们利用xss漏洞，使恶意代码能够保存在网页前端，与正常的代码混合在一起，当保存恶意代码的网页重新加载的时候，恶意代码会在用户的浏览器上执行。

javascript可以用来获取用户的cookie，改变网页内容，url跳转。

xss类型：

反射型：

通过给别人发送带有恶意脚本代码参数的url，当url地址被打开时，特有的恶意代码执行。

根据他的操作特点，一般反射型xss攻击：

http://123123.com/aa?a="><script>alert("xss")</script>。

用户访问这个地址，就会执行弹窗操作了。

在公司实习的时候有碰到过这样的漏洞，JQuery版本过低会存在这样的xss跨站安全漏洞。

这里也补充一下具体实操过程：

方法一：网上有很多的利用代码，但这种代码没办法直观的向公司展示该网站存在漏洞，感兴趣的可以直接去网上搜一下很多。

方法二：直接在网页的console窗口输入

$.fn.jquery

$("element[attribute='<img src=123123 οnerrοr=alert(123)>']");

第一个命令是查看jquery版本号，第二个命令是直接操作xss，存在弹窗说明存在xss跨站漏洞。

一般到这个地步就可以提交了漏洞报告了，但我实习的公司领导让我证明他有什么实质性危害，所以这里进一步进行操作，获取cookie。

利用xss在线利用平台，

https://xssaq.com/

使用上面的方法，发现网站存在xss漏洞，进一步利用

我们在TLXSS平台创建一个项目，查看配置代码，使用这个配置代码

在console控制台输入，回车

回到xss平台，我们发现了我们触发的IP已经被返回。

这个网页应该是没有cookie，但可以利用这个网站做进一步操作，这里我就结束了。

补充一下：这里学到了一个新方法记录一下：下载一个editthiscookie，如果能够获取到cooie，可以使用这个修改自己的cookie从而登录。这个后面如果我能找到更好的漏洞，我再试试。

总结一下反射型XSS，xss能做什么：我们通过构造一个含有xss攻击的链接，诱导受害者点击触发，我们就能进行下一步操作，但这个缺点就是每次攻击都需要受害者点击。

存储型：

存储型xss又称持久型跨站点脚本，一般攻击代码是存储在网站数据库的，当一个页面被用户打开的时候执行。每当用户浏览含有攻击代码的网页时，脚本会自动执行。

所以这种类型的xss攻击更持久，危害面更大。

一般这种漏洞的表现形式是留言板，或者任何可以输入文字并且能保存在网页上的地方。

如果网页没有对输入做任何过滤，直接将其保存在网页前端，那只要用户登录，加载前端网页那就可以执行这段代码。

这里我们利用在线平台演示：

存在留言板，尝试输入<script>alert(1)</script>

刷新界面我们发现存在弹窗，说明我们上传的恶意代码已经被保存在网页上了。

DOM型

DOM型XSS漏洞是一种特殊地XSS，是基于文档对象模型Document Object Model 的一种漏洞。

DOM是什么：DOM用通俗的话来讲就是浏览器用来表示网页内容的一种结构化方式，可以将其想象成一个树状结构，每个网页的元素都是这棵树上的节点。

DOM型是不与后台服务器产生数据交互的，是一种通过DOM操作前端代码输出的时候产生的问题，大部分属于反射型。

是非持久型的。

其实好像是可以直接写入前端

可能触发DOM型XSS的属性：

document.referer

window.name

location

innerHTML

document.write

如何测试基于DOM的XSS，两种测试方法：

测试HTML sink

测试JS执行sink

那反射型和DOM型区别是什么？

DOM型xss是不经过服务器仅仅是通过网页本身的JavaScript进行渲染触发的。

我们通过实验来理解一下：

实验一：

实验室：在 document.write 接收器中使用 select 元素内的源 location.search 的 DOM XSS |网络安全学院 (portswigger.net)

该实验使用javascript函数，该函数将数据写入页面。

F12查看网页源代码，发现存在document.write,storeid是通过document.write提取参数。

我们尝试传递这个参数

我们发现他是被写到前端的

传递恶意参数进去

成功

实验二：

查看源代码，这里写入是用innerHTML,所以script和svg都无法使用了。

换个方法<img  src=1 οnerrοr=alert(1)>

实验三：JQuery 中的DOM XSS

根据提示，点击submit feedback 查看网页代码，href不仅可以跳转路径，也可以放入js代码

这里的开发者可能会进行一些操作从而使攻击者不能输入script，这里也做一下记录，后面方便查看：

1.限制字数：如果是在前端代码限制字数，可以直接F12-elements直接修改输入最大长度。

2.对关键词的过滤：

2.1过滤引号，使用/string/替代引号。

2.2过滤script标签

preg_replace("/<script>/","$text);这种是只过滤了script，我们可以使用大小写混淆的方法进行注入

<ScriPT>alert(/string/)</scripT>

preg_replace("/<script>/i","",$text);这种是不分大小写都过滤，我们可以使用嵌套的script标签进行绕过

<scr<script>ipt>alert(/string/)</scr</script>ipt>

2.3不区分大小写，过滤script及其之间的所有内容）

2.3.1使用str_ireplace()过滤

$nickname = str_ireplace("script", "", @$_POST['nickname']);//昵称

这里直接使用str_ireplace()函数进行不区分大小写地过滤script关键字。

可以使用双写script绕过

<Sscriptcript>alert(1)</Sscriptcript>

原因：str_ireplace()函数只找到了中间的script关键字。

2.3.2使用preg_relplace()函数进行正则表达式过滤script关键字。

$text=preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $text); //过滤了<script 及其之间的所有内容

此处使用了正则匹配的方式过滤了script及其之间的所有内容，无法使用script注入，但我们可以通过img，body等标签时间或者iframe等标签的src注入恶意的javascript代码。

eg：<svg οnlοad="alert(1)">

<img src=x οnerrοr=alert(1)>

2.4过滤alert关键字

$nickname = preg_replace( "/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i", "", @$_POST['nickname']);//昵称 $nickname = preg_replace( "(.*)a(.*)l(.*)e(.*)r(.*)t/i", "", $nickname);//昵称

使用编码绕过：

使用字符编码。

<a href=javascript:alert(1)>a</a>

这里只过滤了alert，所以我只将alert进行编码了。

编码后：<a href="javascript:&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;">a</a>

 2.5服务器端代码存在url解码的情况

$text=preg_replace("/</","&lt;",$text); //将<转化为html实体

$text=preg_replace("/>/","&gt;",$text); //将>转化为html实体

代码中存在url解码相关的函数，我们可以先对<>进行url编码，从而绕过实体转化。

%3cscript%3ealert(1)%3c/script%3e

二.CSRF

CSRF是跨站请求伪造，于XSS不同，XSS利用站点内的信任用户，而CSRF则伪装成受信任用户请求受信任的网站。

攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己以前认证过的站点并运行一些操作。

攻击者欺骗受害者访问用户存在登录证明的网站。

CSRF攻击原理：

CSRF 之所以有效是因为微博、浏览器遵循同源原则，不会阻止从一个站点向另一个站点发送请求。

当用户保持登陆状态，其认证信息会被自动附加到任何向该网站发出的请求上，即使这个网站是由第三方网站触发的。

CSRF防御策略

1.token验证

最常见的防御机制是在每个敏感操作请求中加入一个随机生成的token，此token存储在服务器端，在用户登录时放入页面的隐藏字段或HTTP头部中。服务器接收到请求后，拦截验证token是否有效。

但存在问题就是无法保证token本身的安全。像是在一些论坛上用户可以自己发表内容，黑客在上面发表自己的网站的地址。由于系统也会在这个地址上加上token，黑客可以在自己的网站上得到这个token。

避免此问题，可以在添加token的时候添加一个判断，如果这个链接是链到自己本站的，就在后面添加token，如果不是就不加。

CSRF令牌验证中常见缺陷

绕过 CSRF 令牌验证 |网络安全学院 (portswigger.net)

1.csrf令牌的验证取决于请求方法

某些应用在请求为post方法的时候能够正确验证令牌，但在使用GET方法时跳过验证。

这种情况下，攻击者可以切换到get方法来绕过验证。

POST情况下显示302

右击修改请求方法，使用GET发现可以

右击使用工具生成poc，解决问题。

2.csrf令牌的验证取决于令牌的存在

某些应用不会验证令牌是否必须存在，如果令牌不存在则跳过验证。

这种情况下直接删除令牌即可。

3.csrf令牌未绑定到用户会话

某些程序不验证令牌是否已发出请求的用户属于同一会话。

这种情况下，攻击者可以使用自己的账户登录应用程序，获取有效令牌，然后将令牌提供给csrf攻击中的受害者用户。

直接利用自己的令牌操作受害者。

4.CSRF

2.referer头部

验证referer头部，确保是来自预期的站点。但这种方法不是一定安全的，因为referer头部是可以被篡改的。

3.samesite cookie属性

设置cookie的samesite属性为Lax或者Strict，可以有效防止跨站请求携带Cookie。

4.验证码

CSRF漏洞的挖掘

1.最简单的方法就是抓取一个正常的请求的数据包，如果没有referer和token，那么极有可能是存在CSRF漏洞。

2.存在referer字段，但referer字段删掉后重新提交依旧有效，那也有可能存在csrf漏洞。

3.使用工具

三.SSRF

SSRF是一种由攻击者构造形成由服务器端发起请求的一个安全漏洞。

是服务器被操控来发出请求。

ssrf的形成大多数是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标做过滤与限制。

我们可以这么理解SSRF，存在服务端从别的服务端获取数据，并且我们可以修改目标地址从而获取服务器中的信息。

我们通过实验来进一步理解：

What is SSRF (Server-side request forgery)? Tutorial & Examples | Web Security Academy (portswigger.net)

1.针对本地服务器的ssrf

我们尝试点击网页，发现该网页符合我们的要求，存在从其他服务器获取数据，且我们可以改动，题目给的提示是本地服务器，所以直接输入http://localhost/admin

2.针对其它系统的ssrf

基本和实验1是一样的，题目给了一个网段。我们需要通过暴力破解来找到服务器具体是哪个网址。暴力破解出是131，后面就和本地是一样的操作了。

大概就是这么多，这篇笔记的主要目的是为了帮我去区分这几个漏洞之间的区别，具体的漏洞学习还会有新的笔记。

全是个人见解和网络上学习来的，欢迎大家指出错误。