XSS、CSRF、SSRF

举报
拈花倾城 发表于 2022/02/16 15:49:27 2022/02/16
【摘要】 XSS、CSRF、SSRF

@TOC

相同不同

相同点:

XSS,CSRF,SSRF三种常见的Web服务端漏洞均是由于,服务器端对用户提供的可控数据过于信任或者过滤不严导致的。

相同点:
XSS,CSRF,SSRF三种常见的Web服务端漏洞均是由于,服务器端对用户提供的可控数据过于信任或者过滤不严导致的。

不同点:
XSS是服务器对用户输入的数据没有进行足够的过滤,导致客户端浏览器在渲染服务器返回的html页面时,出现了预期值之外的脚本语句被执行。

CSRF(跨站请求伪造)是服务器端没有对用户提交的数据进行随机值校验,且对http请求包内的refer字段校验不严,导致攻击者可以利用用户的Cookie信息伪造用户请求发送至服务器。

SSRF(服务端请求伪造)是服务器对用户提供的可控URL过于信任,没有对攻击者提供的RUL进行地址限制和足够的检测,导致攻击者可以以此为跳板攻击内网或其他服务器。

修复方式

xss:修复方式:对字符实体进行转义、使用HTTP Only来禁止JavaScript读取Cookie值、输入时校验、浏览器与Web应用端采用相同的字符编码

a)HttpOnly属性

   为Cookie中的关键值设置httponly属性,众所周知,大部分XSS(跨站脚本攻击)的目的都是通过浏览器的同源策略,来获取用户Cookie,从而冒充用户登陆系统的。

   如果为Cookie中用于用户认证的关键值设置httponly属性,浏览器将会禁止js通过同源策略访问cookie中设有httponly属性的信息,因此以劫持用户认证cookie为目的XSS攻击将会失败。

    但很明显,只为cookie中的值设置Httponly是不够的,因为XSS攻击并不是只能获取用户COOKIE,它还可以窃取用户浏览器信息,模拟用户身份执行操作等等

b) 对输入和URL参数进行过滤(白名单和黑名单

c)对输出进行编码

在输出数据之前对潜在的威胁的字符进行编码、转义是防御XSS攻击十分有效的措施。如果使用好的话,理论上是可以防御住所有的XSS攻击的。对所有要动态输出到页面的内容,通通进行相关的编码和转义。当然转义是按照其输出的上下文环境来决定如何转义的。

1、作为body文本输出,作为html标签的属性输出:

比如: u s e r n a m e < / s p a n > , < p > < c : o u t v a l u e = " {username}</span>, <p><c:out value=" {username}"></c:out>

<input type="text" value="${username}" />

此时的转义规则如下:

< 转成 <

转成 >

& 转成 &

" 转成 "

’ 转成 &#39

2、javascript事件

<input type="button" onclick='go_to_url("${myUrl}");' />

除了上面的那些转义之外,还要附加上下面的转义:

\ 转成 \

/ 转成 /

; 转成 ;(全角;)

3、URL属性

如果 <script>, <style>, <imt> 等标签的 src 和 href 属性值为动态内容,那么要确保这些url没有执行恶意连接。

确保:href 和 src 的值必须以 http://开头,白名单方式;不能有10进制和16进制编码字符

cfrs:修复方式:筛选出需要防范CSRF的页面然后嵌入Token、再次输入密码、检验Referer.
Referer头检测法

Referer标识当前请求的来源页面,浏览器访问时除了自动带上Cookie还会自动带上Referer,所以服务端可以检测Referer头是否本网站页面来决定是否响应请求。

Referer是浏览器自动带上的,基于认为浏览器没有相关漏洞的前提下,我们可以认为攻击者是没法伪造Referer头的,也就是检测Referer头的方法是可靠的。

但该方式有时会不受认可,一是因为浏览器是可以设置禁止发送Referer头的,如果使用该方式那么禁止Referer头的浏览将无法正常使用,这可能会降低用户使用体验。二是因为由于移动端的崛起当下流行前后端分离app和web共用一套后端代码,但app是不会自动带Referer头的,如果使用该方式app端不好处理。
token检测法

token就是服务端返回给客户端类似sessionid那样一长串的类值(长是为了防暴力猜解)。csrf依赖于浏览器该问链接时自动对应网站的cookie带上,token不放cookie(一般form表单加个hidden属性的input标签来存放)csrf就没法获取token,这样我们就可以通过检测发送过来的数据包中是否有正确的token值来决定是否响应请求。

在讲清token防御的原理后,我们再来讲token的设计,因为token方式给人的感觉很复杂令人望而生畏。

我们首先明确一个问题,就是能够防止csrf攻击的token,并不需要每次请求都不一样,在用户登录后到退出前的这整个过程中的所有请求token完全可以是一样。因为(在基于没有其他漏洞会泄漏本次会话的token的设想下)黑客是无法获取用户的tokne,所以又何必每个请求都要生成一个新的token呢。(token每次请求都要不一样的想法是受防重放攻击的影响)只考滤防csrf不考滤防重放的情况下,token设计就简单多了。

使用sessionid作为token设计:在csrf中cookie是浏览器自己带上的,本质而言用户的sessionid并未丢失(也就是攻击者并不能知道sessionid是多少),基于此我们完全可以不用另传一个值只需直接将sessionid作为token即可(或者也可以做些运算比如取sessionid的某些值做个md5来做为token,意思都差不多)。判断代码类似 if session[“id”] == $_POST[“token”]

与sessionid同时返回的token设计:在生成sessionid的同时生成一个token(服务端token可以存于session变量中)返回给客户端,客户端保存该token每次请求时都在form表单中提交该值。判断代码类似if session[“token”] == $_POST[“token”]

ssrf

修复方案:

限制协议为HTTP、HTTPS

不用限制302重定向

设置URL白名单或者限制内网IP

面试题:

CSRF 和 XSS 和 XXE 有什么区别,以及修复方式?

XSS是跨站脚本攻击,用户提交的数据中可以构造代码来执行,从而实现窃取用户信息等攻击。修复方式:对字符实体进行转义、使用HTTP Only来禁止JavaScript读取Cookie值、输入时校验、浏览器与Web应用端采用相同的字符编码。 CSRF是跨站请求伪造攻击,是由于没有在关键操作执行时进行是否由用户自愿发起的确认,模仿合法用户对服务器发起请求 。修复方式:筛选出需要防范CSRF的页面然后嵌入Token、再次输入密码、检验Referer XXE是XML外部实体注入攻击,XML中可以通过调用实体来请求本地或者远程内容,和远程文件保护类似,会引发相关安全问题,例如敏感文件读取。修复方式:XML解析库在调用时严格禁止对外部实体的解析。
CSRF、SSRF和重放攻击有什么区别?

CSRF是服务器端没有对用户提交的数据进行严格的把控,导致攻击者可以利用用户的Cookie信息伪造用户请求发送至服务器。而SSRF是服务器对用户提供的可控URL地址过于信任,没有经过严格检测,导致攻击者可以以此为跳板攻击内网或其他服务器。

CSRF是跨站请求伪造攻击,由客户端发起 SSRF是服务器端请求伪造,由服务器发起 重放攻击是将截获的数据包进行重放,达到身份认证等目的

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。