json格式,CSRF如何防御?

一个常见的问题是“我需要保护由javascript发出的JSON请求吗?”答案是,这视情况而定。但是,您必须非常小心,因为有些CSRF漏洞会影响JSON请求。例如,恶意用户可以使用以下格式使用JSON创建CSRF:

这将产生以下JSON结构

如果应用程序未验证Content-Type,则该应用程序将被暴露。根据设置的不同,仍然可以通过更新URL后缀以.json结尾来利用验证内容类型的Spring MVC应用程序,如下所示:

针对上述官方的描述,有两个问题想请教各位老师:

2.1 产生了如上述的JSON结构会造成什么问题?

这会有什么影响么?如果造成了原本想直接传递给后台的表单数据,变成了传递json,后台在接收参数、做参数解析的时候就会报错。为什么会涉及CSRF问题?

意思是原本只处理json数据的接口,增加校验后,将会拒绝处理其他数据类型么?但是如果接口传递的数据不是json类型的,在参数解析的时候也会报错啊?增加这个校验的必要性是?

}
因为 HTTP 协议是无状态的,所以很久以前的网站是没有登录这个概念的,直到网景发明 cookie 以后,网站才开始利用 cookie 记录用户的登录状态。cookie 是个好东西,但它很不安全,其中一个原因是因为 cookie 最初被设计成了允许在第三方网站发起的请求中携带,CSRF 攻击就是利用了 cookie 的这一“弱点”,如果你不了解 CSRF,请移步别的地方学习一下再来。

当我们在浏览器中打开 站点下的一个网页后,这个页面后续可以发起其它的 HTTP 请求,根据请求附带的表现不同,这些请求可以分为两大类:
上面说的同步和异步并不是正式术语,只是我个人的一种区分方式。
这些由当前页面发起的请求的 URL 不一定也是 上的,可能有 的,也可能有 的。我们把发送给 上的请求叫做第一方请求(first-party request),发送给 和

Lax,下面分别讲解:

严格模式,表明这个 cookie 在任何情况下都不可能作为第三方 cookie,绝无例外。比如说假如 会。举个实际的例子就是,假如淘宝网站用来识别用户登录与否的 cookie 被设置成了 SameSite=Strict,那么用户从百度搜索页面甚至天猫页面的链接点击进入淘宝后,淘宝都不会是登录状态,因为淘宝的服务器不会接受到那个 cookie,其它网站发起的对淘宝的任意请求都不会带上那个

会,也就是说用户在不同网站之间通过链接跳转是不受影响了。但假如这个请求是从 发起的对 的异步请求,或者页面跳转是通过表单的 post 提交触发的,则 bar 也不会发送。

}

上一篇内容整理到漏洞篇章的SQL注入,下文会接着SQL注入后的漏洞内容继续整理!

注:作者才学疏浅、知识有限,在整理的过程中难免存在一些错误或是不完整的部分,如果存在疏漏、错误,还请各位批评指正。文章篇幅过长,建议收藏阅读,请善用CTRL+F搜索相关知识,知识整理搜集会存在不足之处,可以使用搜索引擎搜索查看相关知识的详细内容。

XSS全称为Cross Site Scripting,为了和CSS分开简写为XSS,中文名为跨站脚本。该漏洞发生在用户端,是指在渲染过程中发生了不在预期过程中的JavaScript代码执行。XSS通常被用于获取Cookie、以受攻击者的身份进行操作等行为。

反射型XSS是比较常见和广泛的一类,举例来说,当一个网站的代码中包含类似下面的语句:

,则可执行预设好的JavaScript代码。

反射型XSS通常出现在搜索等功能中,需要被攻击者点击对应的链接才能触发,且受到XSS Auditor、NoScript等防御手段的影响较大。储存型XSS

储存型XSS相比反射型来说危害较大,在这种漏洞中,攻击者能够把攻击载荷存入服务器的数据库中,造成持久化的攻击。

DOM型XSS不同之处在于DOM型XSS一般和服务器的解析响应没有直接关系,而是在JavaScript脚本动态执行的过程中产生的。

上面是利用CSS selectors完成攻击的一个示例

当可以插入CSS的时候,可以使用

当字符较多时,则可以结合

等CSS属性缩小范围,以获取更精确的内容XSS 常用Payload

当后端程序通过不正确的正则表达式(比如将http之后到com为止的字符内容,也就是,认为是访问请求的host地址时)对上述URL的内容进行解析的时候,很有可能会认为访问URL的host为,而实际上这个URL所请求的内容都是192.168.0.1上的内容。利用跳转

如果后端服务器在接收到参数后,正确的解析了URL的host,并且进行了过滤,我们这个时候可以使用跳转的方式来进行绕过。

可以使用如 等服务跳转,但是由于URL中包含了192.168.0.1这种内网IP地址,可能会被正则表达式过滤掉,可以通过短地址的方式来绕过。

常用的跳转有302跳转和307跳转,区别在于307跳转会转发POST请求中的数据等,但是302跳转不会。

通过各种非HTTP协议

如果服务器端程序对访问URL所采用的协议进行验证的话,可以通过非HTTP协议来进行利用。

比如通过gopher,可以在一个url参数中构造POST或者GET请求,从而达到攻击内网应用的目的。例如可以使用gopher协议对与内网的Redis服务进行攻击,可以使用如下的URL:

除了gopher协议,File协议也是SSRF中常用的协议,该协议主要用于访问本地计算机中的文件,我们可以通过类似

这种格式来访问计算机本地文件。使用file协议可以避免服务端程序对于所访问的IP进行的过滤。例如我们可以通过

一个常用的防护思路是:对于用户请求的URL参数,首先服务器端会对其进行DNS解析,然后对于DNS服务器返回的IP地址进行判断,如果在黑名单中,就禁止该次请求。

但是在整个过程中,第一次去请求DNS服务进行域名解析到第二次服务端去请求URL之间存在一个时间差,利用这个时间差,可以进行DNS重绑定攻击。

要完成DNS重绑定攻击,我们需要一个域名,并且将这个域名的解析指定到我们自己的DNS Server,在我们的可控的DNS Server上编写解析服务,设置TTL时间为0。这样就可以进行攻击了,完整的攻击流程为:

  • 服务器端获得URL参数,进行第一次DNS解析,获得了一个非内网的IP对于获得的IP进行判断,发现为非黑名单IP,则通过验证服务器端对于URL进行访问,由于DNS服务器设置的TTL为0,所以再次进行DNS解析,这一次DNS服务器返回的是内网地址。由于已经绕过验证,所以服务器端返回访问内网资源的结果。

有些服务没有考虑IPv6的情况,但是内网又支持IPv6,则可以使用IPv6的本地IP如

或IPv6的内网域名来绕过过滤。利用IDN

一些网络访问工具如Curl等是支持国际化域名(Internationalized Domain Name,IDN)的,国际化域名又称特殊字符域名,是指部分或完全使用特殊的文字或字母组成的互联网域名。

在这些字符中,部分字符会在访问时做一个等价转换,例如

等同。利用这种方式,可以用

等字符绕过内网限制。可能的利用点

在AWS、Google等云环境下,通过访问云环境的元数据API或管理API,在部分情况下可以实现敏感信息等效果。

  • 过滤返回的信息统一错误信息限制请求的端口禁止不常用的协议对DNS Rebinding,考虑使用DNS缓存或者Host白名单

命令执行漏洞(命令注入,远程命令执行)

命令注入通常因为指Web应用在服务器上拼接系统命令而造成的漏洞。

该类漏洞通常出现在调用外部程序完成一些功能的情景下。比如一些Web管理界面的配置主机名/IP/掩码/网关、查看系统信息以及关闭重启等功能,或者一些站点提供如ping、nslookup、提供发送邮件、转换图片等功能都可能出现该类漏洞。

  • 或其他逻辑构造布尔条件
  • 其中{}用来截断,比如cat$IFS2会被认为IFS2是变量名。另外,在后面加个$可以起到截断的作用,一般用$9,因为$9是当前系统shell进程的第九个参数的持有者,它始终为空字符串

上面的方法为通过命令行重定向写入命令,接着通过ls按时间排序把命令写入文件,最后执行 直接在Linux终端下执行的话,创建文件需要在重定向符号之前添加命令 这里可以使用一些诸如w,[之类的短命令,(使用ls /usr/bin/?查看) 如果不添加命令,需要Ctrl+D才能结束,这样就等于标准输入流的重定向 而在php中 , 使用 shell_exec 等执行系统命令的函数的时候 , 是不存在标准输入流的,所以可以直接创建文件

  • 一个在括号内的字符,e.g.
  • 不使用时禁用相应函数尽量不要执行外部的应用程序或命令做输入的格式检查转义命令中的所有shell元字符shell元字符包括

本文介绍了XSS,CSRF,SSRF,命令执行RCE(命令注入,远程命令执行),目录穿越。作者精力有限,不定期更新文章,

作者精力有限,不定期更新文章,点击关注不迷路!

声明:文章内容由十年网安路收集整理,发布于知乎,转载请注明出处!

}

我要回帖

更多关于 token防止csrf原理 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信