CSRF和SSRF的主要区别在于伪造的身份不同。
CSRF攻击
跨站请求伪造CSRF完全不同与XSS攻击。XSS攻击侧重于获取用户的权限及信息,而CSRF则是攻击者可伪造当前用户的行为,让目标用户误以为请求由当前用户发起,并利用当前用户权限实现业务请求伪造。 CSRF侧重于伪造特定用户的请求。 CSRF攻击的效果是在当前用户不值钱的轻快下,以当前用户的身份发送业务请求并执行。
CSRF漏洞利用场景
想要攻击形成有效的CSRF攻击必须满足三个条件:
- 用户处于登录状态
- 伪造的连接与正常应用请求连接一致。
- 后台未对用户业务开展合法性校验。
尤其需要注意的是,用户必须在登陆状态时点击伪造的页面。
POST请求方式的复杂之处在于需要创建一个隐藏表单,当用户访问时自动提交表单至目标连接,即可实现CSRF攻击。 在CSRF漏洞利用场景中,GET方式与POST方式在漏洞利用效果方面没有区别,只是在构造页面方面POST稍显复杂。
- 当用户是管理员时,攻击者可根据业务功能特点构造语句,在管理员不知情的情况下发起某项业务请求。
- 针对个人用户,如果CSRF漏洞配合存储下XSS漏洞,可实现在当前用户页面上嵌入攻击伪造连接,从而大大增加用户电机的可能性,形成触发攻击的隐患。
- 如果CSRF伪造管理员的高危功能管理请求并诱导管理员执行,那么会对当前系统造成非常大的危害。
针对CSRF的防护方案
尽管攻击的方式千变万化,但归根结底都是没有充分验证当前业务的合法性导致的,因此常用的防护手段重点在于为关键业务点天啊及合理的验证方式,以实现对用户合法身份的二次确认。
- 添加中间环节
由于攻击者只能仿冒用户发起请求,并不能接收服务器的相应内容,因此可在请求被执行前添加防护措施,主要思路为在发起关键业务之前多添加一步验证环节,保证验证环节的内容无法被攻击者获取或碰撞。 (1)添加验证过程,如让用户去进行确认,注意确认流程应由页面接收后在前台进行显示。 (2)添加验证码,利用验证码来确认是否为当前用户发起的请求 - 验证用户请求合法性
(1)验证referer,在referer出,攻击者与当前用户所处的界面完全不同。可通过验证referer值是否合法,即通过验证请求来源的方式确定此次请求是否正常 (2)针对CSRF漏洞,建设web系统时一般会利用toker来识别当前用户身份的真实性,由于攻击者在CSRF利用时无法获得当前用户的token,所以攻击无法正常进行。token必须是一次性且需有较强的随机性。
CSRF漏洞总结
与XSS防护不同的是,CSRF防护不会关注对连接、提交参数的过滤,而是重点对业务开展合法性机械能验证,如验证请求是否来自当前用户、重点功能处添加验证细节、通过token验证等。
SSRF
SSRF是另一种服务器端请求伪造的形式,服务器端请求伪造可以让服务器执行一些在用户侧无法实现的效果,如内网探测、加载特定图片和文件等。
服务器端向第三方发起请求的业务,服务器根据用户提交的参数进行后续业务流程,因此如果用户提交恶意的参数信息,并且服务器未对用户提交的擦书进行合法性判断而直接进行后续请求业务,就会导致出现安全隐患。
攻击者需伪造的请求为服务器端发起的内容,前提是Web服务器存在向其他服务器发起请求并获取数据的功能,并且获取过程中并未对目标地址进行安全过滤或加以限制,导致服务器的请求被伪造,进而实现后续的攻击。
SSRF漏洞利用场景
根据漏洞特点,可能存在SSRF漏洞缺陷的目标有以下几种:
- 图片加载与下载功能:通过URL地址远程加载或下载图片
- 本地处理功能:业务流程中需要对用户输入的参数进行本地处理
- 各类辅助功能:可针对用户输入的参数添加各类辅助信息
- 图片、文章收藏等功能:将远程地址进行本地保存
根据存在SSRF漏洞的不同业务功能环境,SSRF漏洞可实现的攻击效果为:端口扫描、指纹识别、漏洞利用、内网探针
- 对内网Web英语特征进行发现
- 对服务器所在内网进行各类信息探测
- 利用FILE协议读取本地文件
- 针对特定目标进行攻击时隐藏攻击发起地址
SSRF漏洞的实际利用方式以及利用效果完全受制当前的业务环境。
针对SSRF的防护方案
CSRF和SSRF主要区别于伪造目标不同,SSRF漏洞在防护方面需重点解决两个问题
- 用户请求的合法性
- 服务器行为的合规性
优先利用各类黑名单手段对用户输入的内容进行合法性识别,并且严格对用户输入的参数进行格式以及长度显示。 在CSRF漏洞防护中最有效的token防御机制,针对SSRF漏洞则效果较差,因为用户针对每次SSRF漏洞利用均由其自行发起,无需判断用户真实性。 可以利用正则表达式以及黑名单的方式实现针对内网地址的过滤,以达到防护的效果。
SSRF漏洞总结
导致SSRF漏洞的主要愿意在于服务器对用户提供的URL或调用远程服务器的返回信息没有进行验证及过滤,导致传入服务器的数据可能存在其他正常行为。防护措施包括:
- 双向过滤用户端参数,严格限定输入参数、返回结构的数据类型及内容
- 限制请求行为端口,并针对具有服务器请求业务的网络范围进行严格划分
- 针对内网地址添加黑白名单
最合理的措施是从开发阶段就对服务器的主动请求行为进行统一规划与防护
|