Brute Force(爆破)
Security Level: low
- 便在登录框输入：
尝试一下admin 密码123456
出现incorrect - 打开burpsuite 拦截包 进行爆破
- 找到包 发送到Intruder
send to intruder在Intruder的positions选择中，先点击clear$清除所有的变量。添加变量并将attack type的值设置为cluster bomb(集束炸弹)
攻击类型有四种：
- Sniper： 单参数爆破，多参数时使用同一个字典按顺序替换各参数，只有一个数据会被替换
- Battering ram： 多参数同时爆破，但用的是同一个字典，每个参数数据都是一致的
- Pichfork： 多参数同时爆破，但用的是不同的字典，不同字典间数据逐行匹配
- Cluster bamb： 多参数做笛卡尔乘积模式爆破
- 可以看到左侧的payload，只要把包中的变量添加好之后，即可进行设置参数字典，分别给用户名变量和password变量导入字典（本地）
payload类型选简单列表即可，因为是导入字典进行爆破，如果有其他需求也可按照所示进行配置。 - 配置好字典之后
start attack(开始爆破) - 会弹出枚举框，按照length降序排列 等待爆破完成
- length的长度与其他的不同的即是破解成功的用户名和密码
可以看到admin password组合的回显长度明显不同，包响应也可以看出破解成功。
Security Level: Medium
相比Low级别的代码，Medium级别的代码主要增加了mysql_real_escape_string函数，这个函数会对字符串中的特殊符号（x00，n，r，，’，”，x1a）进行转义，把其中的字符串给过滤掉了，基本上能够抵御sql注入攻击，那低等级时候用到的注入就失效了，需要注意的是中级的暴力破解相对来说较慢是因为有个sleep函数，在破解失败后会使程序停止运行两秒。所以我们直接用爆破方法即可，和low级的一样。
Medium部分原文链接：https://blog.csdn.net/qq_40216188/article/details/129417395
Security Level: High(暂时预留一下)
Command Injection（命令注入）
Security Level: low
- 输入IP地址，发现跟正常
ping相同，可以ping通且回显正常，所以考虑在执行ping命令同时执行其他命令，也就是命令注入。
命令连接符:
& ：前面一个命令无论是否执行，后面的命令都能执行，两个命令都执行&&：前面一个命令执行成功后，才能执行后面一个命令，两个命令都执行|：前面一个命令无论是否执行，后面的命令都能执行且只执行后面一个||：前面一个命令不能正常执行后，才能执行后面一个命令- 这里用
|连接我们的命令 - 显然我们可以执行系统命令，注入成功
Security Level: medium
- 这里查看源码 发现只是增加了对
&&和;的过滤，所以我们仍然可以使用&或者|进行其他命令的执行（比如系统命令）。 - 比如执行
dir命令查看当前目录下的文件
Security Level: High
- 发现之前的注入没法用了 原因是其添加了更多的过滤：
- 但是仔细观察源码发现对于
|的过滤有一点漏洞，这里是仅仅过滤了|，也就是|+一个空格，所以只要|后紧跟命令，不添加空格即可成功注入。
Cross Site Request Forgery (CSRF)（跨站请求伪造）
CSRF（跨站请求伪造）是一种恶意的网络攻击，它利用用户在当前已登录的Web应用中的身份凭证，诱骗用户执行他们本不打算执行的操作。
一个成功的CSRF攻击依赖于以下几个条件：
- 用户已登录目标网站： 用户在浏览器中有目标网站的有效会话Cookie。
- 目标网站完全依赖Cookie等凭证进行身份验证： 服务器收到请求后，只验证Cookie，不验证请求的来源。
- 用户被诱骗访问恶意页面： 攻击者通过邮件、聊天工具、论坛等渠道发送链接，诱使用户点击。
防御CSRF的核心思想是：增加一个攻击者无法伪造的“暗号”。
以下是几种主流的防御方法：
- CSRF Token（最常用、最有效）
原理： 服务器在返回给用户的表单中，嵌入一个随机生成的、不可预测的字符串（Token）。当用户提交表单时，必须将这个Token一并送回服务器。服务器会验证这个Token是否有效。
为什么有效： 恶意网站B无法知道这个Token的值是什么，因为它无法读取来自网站A的响应内容（受同源策略限制），因此它构造的请求中无法包含正确的Token。
- SameSite Cookie 属性
原理： 这是一种浏览器端的防御机制。在设置Cookie时，可以指定 SameSite 属性。
Strict：最严格，浏览器完全禁止在跨站请求中发送此Cookie。Lax：宽松一些，允许在安全的HTTP方法（如GET）且是顶级导航（如点击链接）的跨站请求中发送Cookie，但POST请求等不行。None：允许跨站发送，但必须同时设置 Secure 属性（仅限HTTPS）。
为什么有效： 它直接从源头（浏览器）阻止了Cookie在跨站场景下被发送，使得攻击者无法利用用户的登录凭证。
- 验证请求来源（Referer / Origin Header）
原理： 服务器检查HTTP请求头中的 Origin 或 Referer 字段，判断请求是否来自合法的源（即自己的网站域名）。
缺点： 有些用户出于隐私考虑会禁用Referer头，因此这种方法可以作为辅助手段，但不建议作为唯一防御。
Security Level: low
- 这里尝试输入密码改为1234，发现浏览器的url栏显示了一些参数（包括我们的输入），这意味着 我们完全可以直接构造这个url请求，而不是登录当前这个网站，来达到修改密码的目的，换言之，我们完全可以构造一个自己想要的url请求，让其他用户在其不知道的情况下点击，进而达到修改他人账户密码的目的。
- 这里对源码进行分析：
发现其仅仅对”password_new”和”password_conf”进行一致性验证，并没有经过任何过滤之类的操作，完全可以执行CSRF攻击。
Security Level: medium
- 这里查看源码，发现其对请求的来源进行了验证，这里是通过Referer字段进行验证
- 当我们通过直接构造url进行直接的请求时，回显”That request didn’t look correct”，这时就不能直接通过单纯的让其他用户点击我们构造的url请求的链接了， 在此基础上，我们应该抓包下来这个请求，并修改其Referer字段，让服务器认为是由用户本人做出的行为。
- 这里我们将在网站上的修改请求和直接构造的url请求抓包：
网站上的：
伪造的：
4. 这里可以看出伪造的请求没有Referer字段，然后构造其Referer与我们在网站上的Referer字段一致，可以看到修改成功
Security Level: High
- 这次修改密码，发现url栏有回显token
- 查看源码发现有Anti-CSRF token的验证
由于Anti-CSRF Token机制的加入，攻击者通常无法直接获取到Token值，因为Token是随会话变化且与用户会话关联的，并且受到同源策略的保护。但是，在某些情况下，如果应用存在其他安全漏洞或设计缺陷，仍然可能被利用。
以下是几种可能的方法：
方法一：利用Token生成或验证的漏洞
这是最直接的攻击思路，针对Token机制本身的弱点
- Token可预测
场景：如果Token不是真正的随机数（例如，基于时间、用户ID等可预测因素生成）。
攻击：攻击者可以注册一个账户，分析自己账户Token的生成规律，然后推算目标用户的Token。
实验复现：编写一个生成算法有缺陷的Token（如md5(username + timestamp)），然后尝试预测。
- Token与会话未绑定
场景：Token只验证值是否正确，但不验证这个Token是否属于当前会话的用户。
攻击：攻击者可以先登录自己的账户，获取一个有效的Token，然后将这个Token用于构造给目标用户的恶意请求。如果服务器接受了，说明存在漏洞。
实验复现：用两个浏览器（用户A和用户B），用A的Token替换到B的请求中，看是否成功。
- Token在GET请求中
场景：Token通过URL参数传递（例如/change-password?token=abc123）。
攻击：如果Token通过URL泄露（例如被浏览器历史、Referer头、日志记录），攻击者就能直接获取并使用它。
实验复现：故意将Token放在GET请求的URL中，然后观察浏览器的网络日志或Referer，看是否能被第三方网站捕获。
方法三：利用用户会话的固有风险
会话固定攻击
场景：攻击者能迫使受害者使用一个由攻击者已知的会话ID（和对应的CSRF Token）。
攻击：攻击者先获取一个有效的{Session ID, CSRF Token}对，然后通过某种方式（如XSS或链接注入）让受害者使用这个会话。之后，攻击者就可以用他知道的Token来构造请求了。
同源策略：
同源策略是浏览器实施的一种核心安全机制，它阻止一个”源”的文档或脚本与另一个”源”的资源进行交互。它的目的是隔离潜在的恶意文档，保护用户数据免受未经授权的访问。
同源就是协议 域名 端口相同。
- 这里的场景是token已经通过url泄露，所以就可以通过一些捕获手段获取到，再进行url的构造，将token拼接到表单中，就可以完成攻击了。
SQL Injection（SQl 注入）
SQL注入基本步骤
SQL注入的基本步骤通常包括以下几个阶段：
判断注入类型：首先需要判断注入点是数字型还是字符型。数字型注入不需要闭合字符，而字符型注入需要通过单引号或双引号来闭合。
确定可控列数：通过ORDER BY语句判断SQL查询中可控制的列数。
获取数据库信息：利用UNION SELECT语句结合information_schema数据库获取目标数据库的信息，包括数据库名、表名和列名。
提取数据：通过构造合适的SQL查询语句提取目标数据，如用户名和密码等。
Security Level: low
使用常规的SQL注入方式：
输入1 查看返回数据：1'查看返回数据，显示报错：继续输入
1' and '1' ='1，查看返回数据:根据
id=1'报错和id=1'and '1'='1正确，判断需要闭合字符，所以是字符型注入。接下来通过
order by语句判断可控列数：#是注释掉后面的语句说明字段只有两列，然后来利用sql语句获取信息：
输入1' union select database(),user()#
查看当前数据库名称和执行当前查询的用户名
然后就可以通过构造合适的SQL查询语句提取目标数据：
输入1' union select table_name,table_schema from information_schema.tables where table_schema= database()#可以看到当前数据库下的表名为
guestbook和users继续查询
users表下的数据：
输入1' union select version(),group_concat(column_name) from information_schema.columns where table_schema=database() and table_name='users'#继续查询users 表中的user、password字段数据
输入1' union select user,password from users#可以看到成功爆出用户名、密码，密码采用 md5 进行加密，可以用一些md5的破解手段获取密码。
防御SQL注入
防御SQL注入的有效方法包括：
过滤危险字符：使用正则表达式匹配和过滤SQL关键字，如SELECT、UNION、WHERE等。
使用预编译语句：使用PDO或其他数据库抽象层，通过占位符进行数据库操作，而不是直接将变量拼接到SQL语句中。