大家好，你们可以叫我凌，是个16岁的网络安全学习者。

今天我们来完成下 [极客大挑战 2019]EasySQL 靶场。我们先把基础靶场完成，随后循环递进，目标是 BUUCTF 全通关。那么我们就直接开始吧！

解题思路

先启动靶场。

打开靶场，发现就是个普通的登录框。

那我们就随便输入点数字然后使用Burp进行截包看看。

发现存储用户名和密码的参数，那么就发送到重发模块方便SQL注入。

因为不清楚注入点在 username 还是 password 哪个里面，因此我们一个个进行尝试

在这里，我们先使用 “--” 或者 “#” 将后面内容进行注释，以免妨碍到测试。

这里补充个关于 SQL 注入测试的常见知识点。在测试过程中，我们经常会使用加号"+"来拼接语句，或者使用"--+"进行注释。然而，许多人对这一操作存在误解，其背后的逻辑并非如此简单。实际上，这里的加号本质上代表的是空格，它是空格的一种 URL 编码形式。因此，将其理解为字符串拼接操作并不准确，认为它是注释语句的一部分更是错误的。

由此可知，我们常用的 “--+” 本质上与 “--%20” 是相同的，都表示注释后跟一个空格。

那我们继续，加上注释符 “#” 后使用 单引号“'” 查看注入类型。

GET /check.php?username=111'%23&password=222 HTTP/2

没有报错，那如果不用 单引号 呢？

GET /check.php?username=111%23&password=222 HTTP/2

看来依旧没有报错，但是基于后端接收的是 用户名，那么我们就保留 单引号继续测试。

先使用万能密码尝试，看看能否成功。

这里使用的是URL编码，最常用的就是 %20 代表空格，以及 %23 代表井号。

GET /check.php?username=111'%20or%201=1%23&password=222 HTTP/2

直接翻译过来就是这个样子：

username=111' or 1=1#

这样子，flag就成功出来了。

CTF2{1f476eb3-6f1d-42ce-b164-2cb208a9740b}

那我们接下来使用加号“+”进行拼接看看效果是否一样。

GET /check.php?username=111'+or+1=1%23&password=222 HTTP/2

很好，也成功了，这样子这题就算是完成了。

注意！这里的 %23 并不能替换为 “#” ！否则浏览器将直接丢弃后面的密码部分！

根据 HTTP/1.1 和 URI 规范，# 及其后面的内容属于 Fragment（片段），作用是让浏览器定位页面位置（如锚点跳转）。

关键规则：浏览器和合法的 HTTP 客户端在发送请求时，会丢弃 # 及其后面的所有内容，不会将其发送到服务器端。

因此，当你发送这个请求时，服务器（Web 后端）实际接收到的请求行是：

GET /check.php?username=111'+or+1=1 HTTP/2

而 &password=222 参数被浏览器截断了，根本没有发给服务器。

因此，响应包会返回 “Input your username and password”

靶场小结

考点标签

SQL注入、万能密码、登录框绕过、注释符

核心教训

1. 登录框是 SQL 注入的高发区：后端SQL通常是 “SELECT * FROM users WHERE username='$user' AND password='$pass'”，用户输入直接拼接进SQL语句，没有任何过滤。
2. 万能密码的原理：“admin or 1=1#” 中的单引号闭合了原SQL的引号，“or 1=1” 让WHERE条件永远为真，# 注释掉了后面的密码验证部分。最终执行的SQL变成 “SELECT * FROM users WHERE username='admin' or 1=1#' AND password='...'”，密码检查被完全跳过。
3. 注释符的正确理解：--+ 中的 + 不是注释的一部分，而是 URL 编码中空格的表示。真正的注释符是 “-- ”（两个短横加一个空格）。可以在 URL 里用 “--+” 或 “--%20”，效果完全一样，因为 + 和 %20 在服务端都会被解码为空格。

解题关键步骤

1. 看到登录框，先用 “任意内容+' ” 测试闭合，页面报错确认存在 SQL 注入。
2. 用万能密码 “111' or 1=1#” 成功绕过登录。
3. 页面回显 Flag。