手工注入方法，方便大家测试程序漏洞

第一步：经典字符注入与数字型漏洞探测

让我们从最基础的识别操作开始：在URL参数或表单输入值的末尾添加一个单引号“'”并提交请求。这个动作看似简单，却极具诊断价值。若页面返回了包含数据库语法错误等敏感信息的提示，那么该应用极大概率存在SQL注入安全风险。此项检测是渗透测试流程中初步验证漏洞存在的标志性步骤。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

确认存在异常后，紧接着需要判定注入点属于数字型还是字符型，两者的测试方法有所区别。

针对数字型注入，业界经典的验证语句是“and 1=1”与“and 1=2”。分别提交这两个参数后，观察页面响应是否产生差异。例如，前者页面正常加载，后者则出现错误提示或内容缺失，基本可确认存在数字型SQL注入点。其原理基于SQL逻辑运算：“and”运算符要求前后条件同时为真，查询才返回结果。若程序未对用户输入进行有效过滤，语句“and 1=1”被拼接入原始查询后，因“1=1”恒真，故查询正常执行；而“and 1=2”因“1=2”恒假，导致整个查询条件失效，可能触发程序报错或返回空结果。这一正一反的对比反应，即是指示漏洞存在的关键信号。

数字型注入的常用绕过技巧：

然而，当前多数安全防护机制会直接拦截“and”、“or”等关键词。面对此类过滤，可尝试以下变通方法进行探测：

1. 改用“or”逻辑判断。 尝试提交“or 2>1”和“or 1>2”。同样基于页面差异进行判断。需注意，“or”运算符的特性是前后任一条件为真即返回真值。在利用“or”探测时，有时会出现一种特殊现象：当“or”后接正确表达式时返回错误页面，接错误表达式时反而显示正常。若观察到此类规律，同样强烈暗示存在注入漏洞。

2. 利用“xor”异或运算。 尝试“xor 1=1”与“xor 1=2”。“xor”运算规则为仅当两端表达式真假值不同时才返回真。其响应模式可能与“or”类似：正确表达式可能导致异常页面，错误表达式可能显示正常，这种反常表现是重要的研判线索。

3. URL编码转换绕过。 将“and 1=1”等关键词转换为对应的URL编码格式（例如：%61%6E%64%20%31%3D%31）再提交。部分Web应用防火墙仅对原始明文关键词进行检测，对编码后的字符串可能识别不足，从而绕过防护。

4. 数学运算试探法。 在数字型参数后尝试添加“-0”和“-1”。如果“id=123-0”返回页面与原页面“id=123”一致，而“id=123-1”返回了不同内容或报错，这通常是数字型注入的典型特征。因为“123-0”结果仍为123，查询不变；而“123-1”结果为122，若参数被直接代入SQL语句参与运算，则会查询另一条数据，从而引发页面内容变化。

第二步：字符型与搜索型注入漏洞检测

字符型注入探测

对于字符型参数的判断，标准测试语句为“' and '1'='1”以及“' and '1'='2”。如果两次请求返回的页面内容存在显著不同，表明单引号成功闭合了SQL语句中的字符串边界，字符型注入漏洞成立。

针对字符型过滤的常见绕过方法，可在参数值后附加“'%2b'”（“%2b”为加号“+”的URL编码）。若提交“news.asp?id=123'%2b'”返回页面与原始页面相同，而提交“news.asp?id=123'%2basdf'”返回错误或异样内容，这通常标示此处为字符型（文本型）注入点。

搜索型注入探测

网站搜索功能是SQL注入的高危区域。快速检测方法分为两步：首先在搜索框输入单个单引号“'”进行搜索，若程序返回数据库错误信息，则存在漏洞的可能性超过90%。其次，搜索一个百分号“%”，若页面能正常返回搜索结果（可能为空），则存在漏洞的几率上升至95%。

更精确的验证，需要在搜索词后拼接特定的检测载荷。例如，先搜索关键词“2006”并记录正常结果。随后分别搜索：
“2006%' and 1=1 and '%'='”
“2006%' and 1=2 and '%'='”
若这两次搜索返回的结果集存在明显差异，则可100%确认存在搜索型SQL注入漏洞。确认后，只需将探测语句“and 1=1”部分替换为具体的攻击载荷即可展开进一步利用。

第三步：数据库信息获取与深度利用

识别数据库类型

确认注入点后，首要任务是判断后端数据库的种类。一个广泛应用的方法是提交“and user>0”这样的语句。如果后台是Access数据库，错误信息中常出现“Microsoft JET Database”等字样；若为Microsoft SQL Server，则错误信息中通常包含“SQL Server”关键词。这一步至关重要，它决定了后续注入语句需遵循的特定数据库语法规则。

猜解数据表名、列名与具体数据

在手动注入过程中，“猜解”是核心技术环节。

猜解表名： 使用语句“and exists (select * from 猜解表名)”。若猜测的表名在数据库中真实存在，页面通常会正常响应。

猜解列名： 使用语句“and (select count(猜解列名) from 已知表名)>0”。原理同上，列名猜中则页面正常返回。

判断字段值长度： 使用类似“and (select top 1 len(字段名) from 表名)>长度数值”的语句。通过不断调整“长度数值”，结合页面返回的正/误状态，可逐步推断出字段值的精确字符长度。

逐位猜解字段内容： 此过程较为耗时，通常采用ASCII码值比对法。语句如“and (select top 1 asc(mid(字段名, 起始位, 1)) from 表名)>ASCII猜测值”。其含义是：从指定字段值的第N个字符开始，猜测其ASCII码数值。为提升效率，安全人员常采用“二分法”进行快速定位：例如先试50返回正确，试100返回错误，则取中间值75继续尝试，以此类推，高效锁定准确的ASCII码，再将其转换为对应字符，最终还原出完整字段内容。

两种传统数据库路径暴露手法

在ASP架构网站流行的时期，有两种方法可直接暴露数据库物理路径，被视为经典手段。

1. %5c暴库法： 将网站URL中表示目录层级的正斜杠“/”替换为其URL编码“%5c”（反斜杠）。此操作有时会引发IIS服务器解析错误，进而在返回的错误详情中直接暴露数据库文件的完整磁盘路径。例如，错误信息中若出现类似“'E:\web\database\db.mdb' is not a valid path”的提示，即意味着数据库路径泄露。

2. conn.asp配置文件暴库： 这是一种更早期的漏洞，通过直接访问网站的数据库连接配置文件（如conn.asp、config.asp等）。若服务器配置不当，未正确解析ASP脚本，反而将该文件以纯文本形式返回到浏览器，攻击者即可直接查看其中包含的数据库连接字符串与路径信息。

附录：其他历史经典利用方式

“'or'='or'”万能密码绕过

这堪称SQL注入历史上最古老且广为人知的利用方式之一。在登录表单的用户名或密码字段中输入“'or'='or'”，有可能直接绕过身份验证机制进入系统后台。其变形版本众多，例如：
' or ''='
" or "a"="a
') or ('a'='a
此类漏洞主要存在于早期开发的、登录验证逻辑存在严重缺陷的网站中，其原理是构造永真条件使查询始终返回结果。

联合查询(Union Select)注入

这是一种效率更高、能够直接将查询结果回显至页面上的注入技术。典型操作分为三个步骤：

第一步：确定字段数。 使用类似“and 1=2 union select 1,2,3,4 from 表名”的语句。此处“and 1=2”旨在使前段原始查询结果为空，从而迫使页面显示Union之后查询的结果。数字“1,2,3,4”代表查询的列数，需从1开始逐步增加尝试，直到页面不再报错并正常显示，此时使用的数字个数即为当前查询可用的字段数。通常，页面中会有1到2个数字被显示出来。

第二步：定位回显点并替换字段。 在页面显示数字的位置，将其替换为我们希望查询的数据库字段名。例如，将显示出来的“2”替换为“username”，“3”替换为“password”。

第三步：获取敏感数据。 执行替换后的Union查询，此时页面回显位置将直接展示出目标表中的用户名、密码（可能是明文或哈希值）等敏感信息。

在成功获取后台管理员凭证后，攻击者的下一步通常是扫描或猜测网站后台管理入口地址，尝试登录以获取系统控制权。

尽管如今自动化SQL注入工具功能强大且高效，但深入理解并掌握上述手动探测与利用的每一步原理，仍然是构建扎实网络安全技能体系的基石。只有透彻理解这些基础手法，才能在面对日益复杂的防御措施时，做到精准分析、灵活应对。

最后必须郑重声明： 本文所涉及的所有技术细节与测试方法，仅限用于授权下的安全评估、漏洞研究、教学实验及自身系统防护加固。使用者必须严格遵守国家法律法规与网络安全伦理规范，不得将其用于任何未授权的侵入、破坏活动。共同维护健康、清朗的网络空间安全环境，是每一位从业者与学习者的责任。