Table of Contents
---------------------- bWAPP v2.2 -----------------------
/ A1 - Injection /HTML Injection - Reflected (GET)
HTML Injection - Reflected (POST)
HTML Injection - Reflected (Current URL)
HTML Injection - Stored (Blog)
iFrame Injection
LDAP Injection (Search)【待开化】
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)
SQL Injection (CAPTCHA)
SQL Injection (Login Form/Hero)
SQL Injection (Login Form/User)
SQL Injection (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)
SQL Injection - Blind (Web Services/SOAP)
XML/XPath Injection (Login Form)
XML/XPath Injection (Search)
/ A2 - Broken Auth. & Session Mgmt. /
Broken Authentication - CAPTCHA Bypassing
Broken Authentication - Forgotten Function
Broken Authentication - Insecure Login Forms
Broken Authentication - Logout Management
Broken Authentication - Password Attacks
Broken Authentication - Weak Passwords
Session Management - Administrative Portals
Session Management - 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)
Cross-Site Scripting - Reflected (POST)
Cross-Site Scripting - Reflected (JSON)
Cross-Site Scripting - Reflected (AJAX/JSON)
Cross-Site Scripting - Reflected (AJAX/XML)
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)
/ A4 - Insecure Direct Object References /
Insecure DOR (Change Secret)
Insecure DOR (Reset Secret)
Insecure DOR (Order Tickets)
/ A5 - Security Misconfiguration /
Arbitrary File Access (Samba)
Cross-Domain Policy File (Flash)
Cross-Origin Resource Sharing (AJAX)
Cross-Site Tracing (XST)
Denial-of-Service (Large Chunk Size)
Denial-of-Service (Slow HTTP DoS)
Denial-of-Service (SSL-Exhaustion)
Denial-of-Service (XML Bomb)
Insecure FTP Configuration
Insecure SNMP Configuration
Insecure WebDAV Configuration
Local Privilege Escalation (sendpage)
Local Privilege Escalation (udev)
Man-in-the-Middle Attack (HTTP)
Man-in-the-Middle Attack (SMTP)
Old/Backup & Unreferenced Files
Robots File
/ A6 - Sensitive Data Exposure /
Base64 Encoding (Secret)
BEAST/CRIME/BREACH Attacks
Clear Text HTTP (Credentials)
Heartbleed Vulnerability
Host Header Attack (Reset HTMLrage (Secret)
POODLE Vulnerability
SSL 2.0 Deprecated Protocol
Text Files (Accounts)
/ A7 - Missing Functional Level Access Control /
Directory Traversal - Directories
Directory Traversal - Files
Host Header Attack (Cache Poisoning)
Host Header Attack (Reset Poisoning)
Local File Inclusion (SQLiteManager)
Remote & Local File Inclusion (RFI/LFI)
Restrict Device Access
Restrict Folder Access
Server Side Request Forgery (SSRF)
XML External Entity Attacks (XXE)
/ A8 - Cross-Site Request Forgery (CSRF) /
Cross-Site Request Forgery (Change Password)
Cross-Site Request Forgery (Change Secret)
Cross-Site Request Forgery (Transfer Amount)
/ A9 - Using Known Vulnerable Components /
Buffer Overflow (Local)
Buffer Overflow (Remote)
Drupal SQL Injection (Drupageddon)
Heartbleed Vulnerability
PHP CGI Remote Code Execution
PHP Eval Function
phpMyAdmin BBCode Tag XSS
Shellshock Vulnerability (CGI)
SQLiteManager Local File Inclusion
SQLiteManager PHP Code Injection
SQLiteManager XSS
/ A10 - Unvalidated Redirects & Forwards /
Unvalidated Redirects & Forwards (1)
Unvalidated Redirects & Forwards (2)
/ Other bugs... /ClickJacking (Movie Tickets)
Client-Side Validation (Password)
HTTP Parameter Pollution
HTTP Response Splitting
HTTP Verb Tampering
Information Disclosure - Favicon
Information Disclosure - Headers
Information Disclosure - PHP version
Information Disclosure - Robots File
Insecure iFrame (Login Form)
Unrestricted File Upload
--------------------------- Extras --------------------------
Client Access Policy File
Cross-Domain Policy File
Evil 666 Fuzzing Page
Manual Intervention Required!
Unprotected Admin Portal
We Steal Secrets... (html)
We Steal Secrets... (plain)
WSDL File (Web Services/SOAP)
在输入框中分别输入:
得效果如下:
如图在POST参数中提交HTML代码:
产生如下结果:
正常情况下显示如下:
显示内容为当前URL,故可以在URL后面添加HTML代码来达到注入的效果:
只有在IE浏览器中实现,Chrome和Firefox中HTML参数均为解析出来。
正常提交数据会存储在数据库,刷新页面后内容依然存在:
在此可以提交HTML内容,以达到页面注入的效果:
- iframe是可用于在HTML页面中嵌入一些文件(如文档,视频等)的一项技术。对iframe最简单的解释就是“iframe是一个可以在当前页面中显示其它页面内容的技术”。
- 通过利用iframe标签对网站页面进行注入,是利用了HTML标签,实际上就是一个阅读器,可以阅读通过协议加载的活服务器本地的文件、视频等。
http://49.234.33.158/bWAPP/bWAPP/iframei.php?ParamUrl=https://www.baidu.com/&ParamWidth=500&ParamHeight=250
理解LDAP与LDAP注入
根据反应时间判断命令是否成功执行
【漏洞描述】
SSI是英文Server Side Includes的缩写,翻译成中文就是服务器端包含的意思。从技术角度上说,SSI就是在HTML文件中,可以通过注释行调用的命令或指针。SSI具有强大的功能,只要使用一条简单的SSI命令就可以实现整个网站的内容更新,时间和日期的动态显示,以及执行shell和CGI脚本程序等复杂的功能。SSI可以称得上是那些资金短缺、时间紧张、工作量大的网站开发人员的最佳帮手。
(Server-side Includes)服务器端包含提供了一种对现有HTML文档增加动态内容的方法。apache和iis都可以通过配置支持SSI,在网页内容被返回给用户之前,服务器会执行网页内容中的SSI标签。在很多场景中,用户输入的内容可以显示在页面中,比如一个存在反射XSS漏洞的页面,如果输入的payload不是xss代码而是ssi的标签,服务器又开启了ssi支持的话就会存在SSI漏洞。
【检测条件】
1、Web服务器已支持SSI(服务器端包含)。
2、Web应用程序在返回HTML页面时,嵌入用户输入。
3、参数值未进行输入清理。
【检测方法】
1、黑盒检测
首先寻找Web服务器事实上是否支持SSI指令。由于SSI支持很常见,答案几乎是肯定的。然后只需要通过传统信息收集技术,了解我们的检测目标运行哪些类型的Web服务器即可。无论能否成功发现这一信息,我们都可以通过查看检测网站的内容来猜测其是否支持SSL:由于.shtml文件后缀名是用来表明网页文件是否包含SSI指令的,因此如果该网站使用了.shtml文件,那说明该网站支持SSI指令。然而.shtml后缀名并非是强制规定的,因此如果没有发现任何.shtml文件,并不意味着目标网站没有受到SSI注入攻击的可能。
下一个步骤。这不仅需要确认是否可以进行SSI注入攻击,还需要确认我们用来注入恶意代码的输入点。这一步的测试跟测试其它代码注入漏洞一样。我们需要找到运行用户提交输入的每一个网页,并确认应用程序是否正确验证了所提交的输入,反之则确认是否存在按输入原样显示的数据(如错误信息、论坛发帖等)。除了常见的用户提供的数据外,常考虑的输入变量就是容易伪造的HTTP请求头和Cookie内容。
一旦我们有了潜在注入点的清单,可以检查输入是否得到正确验证,并找出所提供的数据将在网站按原样显示的地方。必须确保我们能够使用SSI指令中使用的字符:
and[a-zA-Z0-9] //能在同一个地方通过服务器并被解析。
利用验证的缺乏就像使用如下所示的字符串进行表单提交那样容易:
不要用传统的字符串:
当下次服务器需要提供指定的页面时,就会解析该指令,这样页面就包含了Unix标准密码文件内容。
如果Web应用程序将使用这些数据建立一个动态产生的页面,在HTTP头信息中也可以执行该注入:
GET/HTTP/1.0
Referer:
User-Agent:
2、灰盒检测实例
如果能查看应用程序的源代码,我们可以轻松找出:
A、是否使用SSI指令;如果使用,web服务器就启动了SSI支持。这就导致SSI注入至少成为需要调查的潜在问题;
B、用户输入、cookie内容和HTTP标题头在哪里处理;很快就能生成一张完整的输入变量清单;
C、如何处理输入、使用什么样的过滤方式、应用程序不允许什么样的字符通过、考虑了多少种编码方式。使用grep执行这些步骤,找到源代码中的正确关键词(SSI指令、CGI环境变量、涉及用户输入的变量任务、过滤函数等等)。
【修复方案】
由于未对用户输入正确执行危险字符清理,可能会在Web服务器上运行远程命令。这通常意味着完全破坏服务器及其内容。
1、清理用户输入。禁止可能支持SSI的模式/字符。
2、由于SSI会带来许多安全风险,建议您不在Web站点中使用SSI,即关闭服务器对ssi的支持即可。
【SSI语法】
目前,SSI主要有以下几种用用途:
1、显示服务器端环境变量<#echo>
2、将文本内容直接插入到文档中<#include>
3、显示WEB文档相关信息<#flastmod #fsize> (如文件制作日期/大小等)
4、直接执行服务器上的各种程序<#exec>(如CGI或其他可执行程序)
5、设置SSI信息显示格式<#config>(如文件制作日期/大小显示方式)
高级SSI
SSI指令基本格式:
如程序代码:
说明:
1.是HTML语法中表示注释,当WEB服务器不支持SSI时,会忽略这些信息。
2.#exec 为SSI指令之一。
3.cmd 为exec的参数, cat /etc/passwd为参数值,在本指令中指将要执行的命令。
注意:
1.