1. CSRF和XSS
1.1 什么是 XSS 和 CSRF
CSRF和XSS都是客户端攻击,它们滥用同源策略,利用web应用程序和受害用户之间的信任关系。XSS和跨站脚本攻击允许攻击者破坏合法用户与任何易受攻击的应用程序的交互。
1.2 XSS
1. XSS漏洞发生在web应用程序中,这些应用程序在不进行编码或验证的情况下接受用户输入并在响应中使用它。恶意用户编写恶意代码并通过输入表单提交。目标服务器包含这个脚本及其响应,客户机浏览器执行它。由于浏览器信任web服务器,它授予恶意脚本访问本地存储的cookie、会话令牌和其他敏感客户端信息的权限。
2. XSS攻击原理:不需要你做任何的登录认证,它会通过合法的操作(比如在url中输入、在评论框中输入),向你的页面注入脚本(可能是js、hmtl代码块等)
3. XSS是一个常见的攻击矢量,成功攻击的影响通常因不同的场景而不同,包括:
- 泄露用户文件
- 安装恶意软件/木马
- 窃取网上银行信息
- HTML/DOM 内容修改
- 将用户重定向到未知网站
4. XSS的防范措施(encode+过滤)
XSS的防范措施主要有三个:编码、过滤、校正
- 编码:对用户输入的数据进行HTML Entity 编码。把字符转换成转义字符。Encode的作用是将$var等一些字符进行转化,使得浏览器在最终输出结果上是一样的。
- 过滤:移除用户输入的和事件相关的属性。如onerror可以自动触发攻击,还有onclick等。(总而言是,过滤掉一些不安全的内容)移除用户输入的Style节点、Script节点、Iframe节点。(尤其是Script节点,它可是支持跨域的,一定要移除)。
- 校正:避免直接对HTML Entity进行解码。使用DOM Parse转换,校正不配对的DOM标签。(DOM Parse:它的作用是把文本解析成DOM结构)
1.3 CSRF
1.3.1 什么是CSRF
跨站点请求伪造 (CSRF) 也称一键式攻击,是一种 Web 应用程序网络攻击,可诱使受害者在不知不觉中代表攻击者执行操作。CSRF 攻击利用 Web 应用程序中的一个安全漏洞,该漏洞无法区分经过身份验证的用户会话中的错误请求和合法请求。
攻击者通常使用社会工程技术发起 CSRF 攻击,以诱骗受害者用户加载页面或单击包含恶意请求的链接。该链接从经过身份验证的用户的浏览器向目标网站发送恶意请求。对于大多数网站,浏览器请求本质上包括会话信息,例如会话 cookie、有效令牌或网站与用户关联的登录凭据。如果经过身份验证的用户已经与目标网站处于活动会话中,则站点会将新的恶意请求视为来自用户的有效请求并执行它。
1.3.2 CSRF 攻击类型
如果 Web 应用程序无法区分非法请求和有效请求,那么它很容易受到跨站点请求伪造的攻击。有当认证用户与web应用程序处于活动会话时,攻击才会成功。
1. 登录 CSRF 攻击
使用一种称为Login CSRF攻击的特殊形式的CSRF攻击,攻击者可以访问受害者用户的机密和敏感数据。这种攻击迫使不知情的用户登录到黑客控制的帐户。然后,受害者被骗向账户中添加个人身份识别和敏感信息,如电子邮件地址和信用卡信息。
2. 存储 CSRF 攻击
CSRF攻击包也可以存储在易受攻击的网站上。对手可以通过执行高级XSS攻击或在接受HTML的字段中存储IFRAME或IMG标记来实现存储CSRF攻击。在站点上存储攻击会放大攻击的严重性和可能性,因为受害者用户现在肯定会查看CSRF加载的页面,并且也会自然地对该页面进行身份验证。
1.3.3 CSRF如何防御
1. 将cookie设置为HttpOnly
CRSF攻击很大程度上是利用了浏览器的cookie,为了防止站内的XSS漏洞盗取cookie,需要在cookie中设置“HttpOnly”属性,这样通过程序(如JavaScript脚本、Applet等)就无法读取到cookie信息,避免了攻击者伪造cookie的情况出现。设置cookie为HttpOnly的代码如下:
response.setHeader( "Set-Cookie", "cookiename=cookievalue;HttpOnly");
2. Token 验证(用的最多)
攻击者可以伪造用户的请求,该请求中所有的用户验证信息都存在于cookie中,因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。在请求中放入攻击者所不能伪造的信息,并且该信总不存在于cookie之中。服务器发送给客户端一个token;客户端提交的表单中带着这个token;如果这个token不合法,那么服务器拒绝这个请求。假设请求通过POST方式提交,则可以在相应的表单中增加一个隐藏域:<input type="hidden" name="_toicen" value="tokenvalue"/>
token的值通过服务端生成,表单提交后token的值通过POST请求与参数一同带到服务端,每次会话可以使用相同的token,会话过期,则token失效,攻击者因无法获取到token,也就无法伪造请求。
在session中添加token的实现代码:
HttpSession session = request.getSession();
Object token = session.getAttribute("_token");
if(token == null I I "".equals(token)) {
session.setAttribute("_token", UUID.randomUUIDO .toString());
}
3. 隐藏令牌
把token隐藏在http的head头中。方法二和方法一有点像,本质上没有太大区别,只是使用方式上有区别。
4. Referer验证
Referer指的是页面请求来源。意思是,只接受本站的请求,服务器才做响应;如果不是,就拦截。
1.4 CSRF 与 XSS 的区别
1. XSS攻击遵循双向攻击模式,允许攻击者执行恶意脚本、访问响应,并将后续敏感数据发送到攻击者选择的目的地。另一方面,CSRF是一种单向攻击机制,这意味着攻击者只能发起HTTP请求,但不能检索已发起请求的响应。
2. CSRF攻击要求经过身份验证的用户处于活动会话中,而XSS攻击则不需要。在XSS攻击中,只要用户登录,就可以存储和交付有效载荷。
3. CSRF攻击的范围有限,仅限于用户可以执行的操作,例如点击恶意链接或访问黑客的网站。相反,XSS攻击提供执行恶意脚本来执行攻击者所选择的任何活动,从而扩大了攻击的范围。
4. 在XSS攻击中,恶意代码存储在站点中,而在CSRF攻击中,恶意代码存储在受害用户访问的第三方站点中。
2. CSRF攻击步骤
这里以网银转账为例进行说明CSRF是如何发生的。
- 首先用户通过浏览器访问网银系统
- 用户在网银登录后,浏览器会把用户session_id保存在浏览器Cookie中
- 此时用户在同一个浏览器中访问了第三方网站
- 第三方网站诱导用户访问了网页转账的链接
- 由于用户在网银系统已经登录了,浏览器访问网银转账链接时,会带上用户在网银的Cookie信息
- 网银系统根据用户提交Cookie中的session_id,以为用户本人发起了转账操作,于是执行转账业务。
至此,在用户不知情的情况下,网银执行了转账业务,这就是跨站(第三方站点的发起请求)请求伪造(非用户发起的请求)的基本攻击原理。
3. CSRF手工构造POST型页面方法
手工构造CSRF POST型页面的方法主要涉及到创建一个HTML页面,该页面包含一个表单(form),该表单通过POST方法向目标网站发送数据。由于CSRF(跨站请求伪造)攻击是攻击者利用受害者的身份向网站发送未授权的请求,因此,在构造这样的页面时,需要特别注意表单的构造以及可能的防御措施。
3.1 确定目标网站
首先,需要确定该网站存在CSRF漏洞,并了解该网站的正常请求方式。
3.2 分析目标网站的请求
使用浏览器的开发者工具(按F12或右键点击页面元素选择“检查”)或者使用网络抓包工具如Burp Suite来分析目标网站的正常POST请求。
ps:分析操作的请求URL、请求方法(POST)、参数、请求头(如HTTP)和请求体内容(如表单字段和对应的值)。
3.3 构建恶意HTML页面
使用在 3.2 中收集到的信息来构建一个恶意的HTML页面,伪造目标请求。
这个表单的action属性设置为目标网站的请求URL,method属性设置为POST。根据目标URL所需的参数,在表单中添加相应的input
元素,并设置其name
属性为参数名,value
属性为攻击者希望发送的值。
以下是一个参考示例:
<!DOCTYPE html>
<head>
<title>CSRF TEST</title>
</head>
<body>
<form id="csrfForm" action="http://xxx.com/csrf_post.php" method="POST">
<input type="hidden" name="user" value="hello">
<input type="hidden" name="sex" value="woman">
<input type="hidden" name="email" value="1008610010@qq.com">
<input type="hidden" name="submit" value="submit">
<input type="submit" value="submit">
</form>
</body>
</html>
3.4 诱导目标用户访问恶意页面
构造完成恶意页面后,需要通过各种方法(如电子邮件、社交媒体、消息等)诱使目标用户访问该页面,从而实现CSRF。
4. token类CSRF利用方法
CSRF Token Tracker插件
1. 打开Burp Suite ,在其扩展中找到CSRF Token Tracker插件,并下载。
2. 点击CSRF Token Tracker插件,设置host和name,点击enabled选中和设置following跟随。
3. 详细的操作过程
详细参考链接:BurpSuite进阶篇--自动识别Token值-CSDN博客
5. SSRF常用伪协议
5.1 file://
从文件系统中获取文件内容,格式为file://[文件路径]
- file:///etc/passwd 读取文件passwd
- file:///etc/hosts 显示当前操作系统网卡的IP
- file:///proc/net/arp 显示arp缓存表(寻找内网其他主机)
- file:///proc/net/fib _trie 显示当前网段路由信息
- file:///proc/net/arp 显示arp缓存表(寻找内网其他主机)
5.2 dict://
dict://字典服务协议,访问字典资源,如dict://ip:6739/info。可用于:扫描端口、获取内网信息、爆破密码等。
- dict:// +ip:端口+/TCP/IP数据
如扫描有那些主机开了80端口:dict://172.251.250.1:80,将IP地址最后一段设为payload变量依次扫描,根据Length判断是否返回数据,从而判断端口是否打开 ,利用不同的Payload同时扫描多个IP的多个端口。
5.3 ftp://
- 用途:用于访问本地文件系统中的文件
- 示例: file:///path/to/file.txt ,这里的URL指向本地文件系统中的一个文件
-
5.4 http://
作用:常规URL形式,允许通过HTTP 1.0的GET方法,以只读访问文件或资源。
- http://example.com
- http://example.com/file.php?var1 =val1 &var2=val2
- http://user:password@example.com
- https://example.com
- https://example.com/file.php?var1 =val1 &var2=val2
- https://user:password@example.com
-
5.5 gopher://
利用范围较广:GET提交、POST提交、redis、fastcgi、sql
基本格式:gopher://<目标IP>:<端口>/<gopher-path>
gopher协议默认端口为 70,web也需要加端口。
6. SSRF pikachu靶场通关
6.1 SSRF概述
服务器端请求伪造(SSRF)是一种由攻击者通过构造恶意请求,使服务器代表其执行请求的攻击方式。通常,SSRF 漏洞发生在 Web 应用程序从外部资源获取数据且未对用户输入进行适当验证的情况下。攻击者利用 SSRF 可以访问和操控内部网络资源、读取敏感数据、执行任意操作等。
6.2 SSRF原理
SSRF 攻击的核心在于利用服务器代替攻击者执行 HTTP 请求。攻击者通过控制服务器的请求 URL,可以访问服务器所在网络中的任意资源,包括内部网络中的服务和其他安全隔离的资源。
6.3 SSRF防御措施
1. 输入验证和过滤
- 对用户输入进行严格验证和过滤,确保只允许合法的 URL。
- 使用白名单机制,仅允许访问特定的外部 URL。
2. 网络访问控制
- 限制服务器的网络访问权限,确保服务器只能访问必要的外部资源。
- 使用防火墙和网络隔离技术限制服务器的网络访问范围。
3. 使用 URL 解析库
- 使用安全的 URL 解析库,避免直接操作用户输入的 URL。
- 确保解析后的 URL 是预期的合法 URL。
4. 响应内容限制
- 限制服务器返回的内容类型和大小,防止敏感数据泄漏。
5. 监控和审计
- 实时监控和日志记录服务器的外部请求,检测和响应异常行为。
6.4 SSRF(curl)
1. 打开靶场,点击提示:“累了吧,来读一首诗吧”
2. 点击后报错,查看URL地址,发现是http请求,但是后面多了一个vul。
删除多余的"vul"后,页面恢复正常。
3. 第一关的链接传递了参数url, 此值采用了http协议进行访问
4. 利用file协议让服务器访问本地的文件, 构造的payload为
http://127.0.0.1/vul/ssrf/ssrf_curl.php?url=file:///G:/phpstudy/phpstudy_pro/WWW/flag.txt
5. 利用dict协议扫描3306端口是否开放:
http://127.0.0.1/vul/ssrf/ssrf_curl.php?url=dict://127.0.0.1:3306
6. 利用http协议,访问其他页面(以百度为例), 构造的payload为:
http://127.0.0.1/vul/ssrf/ssrf_curl.php?url=http://www.baidu.com
6.5 SSRF (file_get_content)
该关卡会用到file_get_content函数, 该函数的作用是读取文件的内容, 可直接读取主机绝对路径或相对路径的文件, 也可以使用php伪协议进行利用。
语法:file_get_contents(path,include_path,context,start,max_length)
file_get_content()的用法:PHP file_get_contents() 函数 | 菜鸟教程
1. 同样的操作,点击第二关的链接, 点进去可以看到传递了参数file, 此值采用了http协议进行访问
2. 利用file协议让服务器访问本地的文件, 构造的payload为
http://127.0.0.1/vul/ssrf/ssrf_fgc.php?file=file:///G:/phpstudy/phpstudy_pro/WWW/flag.txt
3. 通过php伪协议读取指定文件
http://127.0.0.1/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=G:/phpstudy/phpstudy_pro/WWW/flag.txt
4. 利用http协议,访问其他页面(以百度为例), 构造的payload为:
http://127.0.0.1/vul/ssrf/ssrf_fgc.php?file=http://www.baidu.com
7. SSRF靶场 根据源代码说明漏洞成因
7.1 SSRF(curl)
查看ssrf_curl.php的源代码
从上面的源代码中可以看出,服务端没有对传入的url进行过滤,而是直接使用传入的url值。
后台使用curl_exec()函数进行了请求,然后又将请求的结果返回给了前端。在这个过程中,明显存在服务端请求伪造,没有对前端的URL进行白名单的过滤。
漏洞成因:服务端对输入的URL缺乏有效过滤和验证,就可能允许恶意URL或IP地址的输入。
7.2 SSRF (file_get_content)
从上面的源代码中可以看出:使用了PHP函数file_get_content()读取文件但却未进行白名单过滤,而是直接使用,导致了SSRF。
漏洞成因:服务端未对URL进行严格的过滤和验证,也未对响应结果进行有效处理。