performing-web-application-penetration-test

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Performing Web Application Penetration Test

Web应用渗透测试执行指南

When to Use

适用场景

  • Testing web applications before production deployment to identify exploitable vulnerabilities
  • Conducting compliance-driven security assessments (PCI-DSS requirement 6.6, SOC 2 Type II)
  • Validating remediation of previously identified web application vulnerabilities during retesting
  • Assessing third-party web applications before integration into the organization's environment
  • Evaluating custom-developed web applications where automated scanning alone is insufficient
Do not use against web applications without written authorization, against production systems during peak traffic hours without explicit approval, or for denial-of-service testing of web infrastructure.
  • 生产部署前测试Web应用,识别可被利用的漏洞
  • 开展合规驱动的安全评估(PCI-DSS要求6.6、SOC 2 Type II)
  • 复测时验证已识别Web应用漏洞的修复情况
  • 集成第三方Web应用到组织环境前进行评估
  • 评估仅靠自动化扫描不足以覆盖的定制开发Web应用
禁止使用场景:未经书面授权测试Web应用;未经明确批准在高峰时段测试生产系统;对Web基础设施进行拒绝服务测试。

Prerequisites

前提条件

  • Signed statement of work (SoW) defining the target application URLs, environments (staging/production), and testing boundaries
  • Burp Suite Professional license with up-to-date extensions (Active Scan++, Autorize, JSON Beautifier, Logger++)
  • Valid test accounts at each privilege level (unauthenticated, standard user, administrator) for authorization testing
  • Application documentation including API specifications (OpenAPI/Swagger), sitemap, and technology stack details
  • Browser configured with Burp Suite proxy (FoxyProxy recommended) and Burp CA certificate installed
  • 已签署的工作说明书(SoW),明确目标应用URL、环境(预发布/生产)和测试边界
  • 带有最新扩展(Active Scan++、Autorize、JSON Beautifier、Logger++)的Burp Suite Professional许可证
  • 各权限级别(未认证、标准用户、管理员)的有效测试账户,用于授权测试
  • 包含API规范(OpenAPI/Swagger)、站点地图和技术栈详情的应用文档
  • 已配置Burp Suite代理的浏览器(推荐使用FoxyProxy),且已安装Burp CA证书

Workflow

工作流程

Step 1: Reconnaissance and Application Mapping

步骤1:侦察与应用映射

Map the entire attack surface of the web application:
  • Configure Burp Suite proxy and spider the application by browsing every page, form, and function manually while Burp captures the sitemap
  • Use Burp's Discover Content feature to find hidden directories and files not linked from the visible application
  • Identify the technology stack from response headers (
    X-Powered-By
    ,
    Server
    ), cookies (JSESSIONID = Java, PHPSESSID = PHP, ASP.NET_SessionId = .NET), and page extensions
  • Enumerate endpoints using
    ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u https://target.com/FUZZ -mc 200,301,302,403
  • Review JavaScript files for hardcoded API endpoints, secrets, and client-side routing using Burp's JS Link Finder extension or
    LinkFinder.py
  • Document all entry points: URL parameters, POST bodies, HTTP headers, cookies, file uploads, and WebSocket connections
绘制Web应用的完整攻击面:
  • 配置Burp Suite代理,手动浏览每个页面、表单和功能,同时让Burp捕获站点地图
  • 使用Burp的Discover Content功能查找未在可见应用中链接的隐藏目录和文件
  • 从响应头(
    X-Powered-By
    Server
    )、Cookie(JSESSIONID = Java、PHPSESSID = PHP、ASP.NET_SessionId = .NET)和页面扩展名识别技术栈
  • 使用命令
    ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u https://target.com/FUZZ -mc 200,301,302,403
    枚举端点
  • 使用Burp的JS Link Finder扩展或
    LinkFinder.py
    审查JavaScript文件,查找硬编码API端点、密钥和客户端路由
  • 记录所有入口点:URL参数、POST请求体、HTTP头、Cookie、文件上传和WebSocket连接

Step 2: Authentication Testing

步骤2:认证测试

Test authentication mechanisms for weaknesses:
  • Credential enumeration: Submit valid and invalid usernames to identify differences in response (timing, message, HTTP status) that reveal valid accounts
  • Brute force protection: Attempt 10-20 rapid login attempts with invalid credentials to verify account lockout and rate limiting are enforced
  • Password policy: Test password creation with weak passwords (123456, password, single character) to verify policy enforcement
  • Multi-factor authentication bypass: Test for MFA bypass by directly accessing post-authentication pages, manipulating MFA tokens, or replaying successful MFA responses
  • Session fixation: Note the session token before and after authentication. If the token does not change after login, session fixation is possible
  • Remember me functionality: Inspect persistent authentication tokens for predictability, encryption, and proper expiration
  • Password reset: Test the password reset flow for token predictability, token expiration, account enumeration via the reset form, and host header injection
测试认证机制的弱点:
  • 凭证枚举:提交有效和无效用户名,识别响应(响应时间、提示信息、HTTP状态码)的差异,以此判断有效账户
  • 暴力破解防护:快速尝试10-20次无效登录,验证是否启用了账户锁定和速率限制
  • 密码策略:使用弱密码(123456、password、单字符)测试密码创建流程,验证策略是否被执行
  • 多因素认证绕过:通过直接访问认证后页面、篡改MFA令牌或重放成功的MFA响应,测试MFA是否可被绕过
  • 会话固定:记录认证前后的会话令牌。如果登录后令牌未变化,则存在会话固定风险
  • 记住我功能:检查持久化认证令牌的可预测性、加密情况和过期设置
  • 密码重置:测试密码重置流程的令牌可预测性、令牌过期时间、通过重置表单枚举账户的可能性,以及主机头注入风险

Step 3: Authorization Testing

步骤3:授权测试

Verify that access controls are properly enforced:
  • Horizontal privilege escalation (IDOR): Using Account A, capture requests that access Account A's resources. Replay those requests substituting Account B's identifiers (user IDs, order numbers, filenames). Use Burp's Autorize extension to automate this across all endpoints.
  • Vertical privilege escalation: Using a low-privilege account, attempt to access administrative functions by directly browsing to admin URLs, modifying role parameters in requests, or manipulating JWT claims
  • Forced browsing: Attempt to access resources that should require authentication by directly navigating to internal URLs collected during mapping
  • HTTP method tampering: If GET is blocked on an endpoint, try PUT, POST, DELETE, PATCH, or use method override headers (
    X-HTTP-Method-Override: DELETE
    )
  • Path traversal in authorization: Test URL path manipulation (
    /api/users/123/../456/profile
    ) to bypass path-based authorization checks
验证访问控制是否被正确执行:
  • 水平权限提升(IDOR):使用账户A捕获访问账户A资源的请求,重放这些请求并替换为账户B的标识符(用户ID、订单号、文件名)。使用Burp的Autorize扩展在所有端点上自动化此测试
  • 垂直权限提升:使用低权限账户,尝试通过直接浏览管理员URL、修改请求中的角色参数或篡改JWT声明来访问管理功能
  • 强制浏览:直接导航到映射阶段收集的内部URL,尝试访问需要认证的资源
  • HTTP方法篡改:如果某个端点禁止GET方法,尝试使用PUT、POST、DELETE、PATCH,或使用方法覆盖头(
    X-HTTP-Method-Override: DELETE
  • 授权中的路径遍历:测试URL路径篡改(
    /api/users/123/../456/profile
    ),以绕过基于路径的授权检查

Step 4: Input Validation and Injection Testing

步骤4:输入验证与注入测试

Test all input points for injection vulnerabilities:
  • SQL injection: Insert payloads like
    ' OR 1=1--
    ,
    ' UNION SELECT NULL,NULL--
    , and time-based blind payloads (
    '; WAITFOR DELAY '0:0:5'--
    ) into every parameter. Use sqlmap for automated detection and exploitation of confirmed injection points.
  • Cross-Site Scripting (XSS): Test reflected, stored, and DOM-based XSS with payloads like
    <script>alert(document.domain)</script>
    ,
    "><img src=x onerror=alert(1)>
    , and event handlers. Test in all contexts: HTML body, attributes, JavaScript, and URLs.
  • Server-Side Request Forgery (SSRF): Supply internal URLs (
    http://169.254.169.254/latest/meta-data/
    ,
    http://127.0.0.1:6379/
    ) in parameters that fetch external resources (webhooks, image URLs, import functions)
  • Command injection: Insert OS command separators (
    ;
    ,
    |
    ,
    &&
    ,
    `
    ) followed by commands (
    id
    ,
    whoami
    ,
    ping -c 3 collaborator.net
    ) in parameters processed by the server
  • XML External Entity (XXE): Submit XML payloads with external entity declarations (
    <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
    ) in XML upload or API endpoints
  • Server-Side Template Injection (SSTI): Test with
    {{7*7}}
    ,
    ${7*7}
    ,
    <%= 7*7 %>
    in parameters rendered by template engines
测试所有输入点的注入漏洞:
  • SQL注入:向每个参数插入
    ' OR 1=1--
    ' UNION SELECT NULL,NULL--
    等 payload,以及基于时间的盲注 payload(
    '; WAITFOR DELAY '0:0:5'--
    )。使用sqlmap自动化检测和利用已确认的注入点
  • 跨站脚本(XSS):使用
    <script>alert(document.domain)</script>
    "><img src=x onerror=alert(1)>
    和事件处理程序测试反射型、存储型和DOM型XSS。在所有上下文(HTML正文、属性、JavaScript、URL)中进行测试
  • 服务器端请求伪造(SSRF):在获取外部资源的参数(Webhook、图片URL、导入功能)中提供内部URL(
    http://169.254.169.254/latest/meta-data/
    http://127.0.0.1:6379/
  • 命令注入:在服务器处理的参数中插入操作系统命令分隔符(
    ;
    |
    &&
    `
    ),后跟命令(
    id
    whoami
    ping -c 3 collaborator.net
  • XML外部实体(XXE):在XML上传或API端点中提交包含外部实体声明的XML payload(
    <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
  • 服务器端模板注入(SSTI):在模板引擎渲染的参数中测试
    {{7*7}}
    ${7*7}
    <%= 7*7 %>
    等 payload

Step 5: Session Management Testing

步骤5:会话管理测试

Evaluate the security of session handling:
  • Session token analysis: Collect 100+ session tokens and analyze for randomness using Burp Sequencer. Check token length (minimum 128 bits of entropy), character set, and predictability.
  • Session expiration: Verify that sessions expire after a defined idle timeout and absolute timeout. Test by capturing a session token, waiting beyond the timeout, and replaying.
  • Cookie security flags: Verify
    Secure
    ,
    HttpOnly
    , and
    SameSite
    flags are set on session cookies. Missing
    HttpOnly
    enables XSS-based session theft. Missing
    SameSite
    enables CSRF.
  • CSRF testing: Identify state-changing operations (password change, email update, fund transfer) and test if they can be triggered from a cross-origin page without a valid CSRF token
  • Concurrent session handling: Test if the application limits the number of concurrent sessions and if logging in from a new location invalidates the previous session
评估会话处理的安全性:
  • 会话令牌分析:收集100+个会话令牌,使用Burp Sequencer分析其随机性。检查令牌长度(至少128位熵)、字符集和可预测性
  • 会话过期:验证会话在设定的空闲超时和绝对超时后是否过期。测试方法:捕获会话令牌,等待超时后重放
  • Cookie安全标志:验证会话Cookie是否设置了
    Secure
    HttpOnly
    SameSite
    标志。缺少
    HttpOnly
    会导致基于XSS的会话窃取,缺少
    SameSite
    会导致CSRF
  • CSRF测试:识别状态变更操作(修改密码、更新邮箱、转账),测试是否可以从跨源页面在无有效CSRF令牌的情况下触发这些操作
  • 并发会话处理:测试应用是否限制并发会话数量,以及从新位置登录是否会使之前的会话失效

Step 6: Business Logic Testing

步骤6:业务逻辑测试

Test application-specific logic flaws that automated scanners cannot detect:
  • Race conditions: Send multiple simultaneous requests to exploit time-of-check-to-time-of-use (TOCTOU) vulnerabilities (double-spending, coupon reuse, voting multiple times) using Burp Turbo Intruder
  • Workflow bypass: Attempt to skip steps in multi-step processes (checkout, registration, approval) by directly requesting later-stage endpoints
  • Numeric manipulation: Modify prices, quantities, or amounts to negative values, zero, or extremely large numbers to test for integer overflow or logic errors
  • File upload bypass: Test file upload restrictions by modifying MIME types, double extensions (file.php.jpg), null bytes (file.php%00.jpg), and content-type manipulation
测试自动化扫描工具无法检测的应用特定逻辑缺陷:
  • 竞争条件:使用Burp Turbo Intruder发送多个并发请求,利用检查时间到使用时间(TOCTOU)漏洞(重复消费、优惠券重复使用、多次投票)
  • 工作流绕过:通过直接请求后期阶段的端点,尝试跳过多步骤流程(结账、注册、审批)中的步骤
  • 数值篡改:将价格、数量或金额修改为负值、零或极大值,测试整数溢出或逻辑错误
  • 文件上传绕过:通过修改MIME类型、双重扩展名(file.php.jpg)、空字节(file.php%00.jpg)和内容类型篡改,测试文件上传限制

Step 7: Report and Remediation Guidance

步骤7:报告与修复指导

Compile all findings into a structured report:
  • Write an executive summary describing the overall application security posture in business terms
  • Document each finding with title, severity (CVSS 3.1), affected URL/parameter, description, reproduction steps, screenshots, and HTTP request/response pairs from Burp
  • Provide specific remediation guidance for each finding including code-level fixes where applicable
  • Include a risk matrix showing the distribution of findings by severity
  • Deliver the report securely (encrypted, not via email attachment) and schedule a findings walkthrough with the development team
将所有发现整理为结构化报告:
  • 撰写执行摘要,用业务术语描述应用的整体安全状况
  • 记录每个发现,包括标题、严重性(CVSS 3.1)、受影响的URL/参数、描述、复现步骤、截图以及来自Burp的HTTP请求/响应对
  • 为每个发现提供具体的修复指导,包括适用的代码级修复
  • 包含按严重性分布的风险矩阵
  • 安全交付报告(加密,不通过邮件附件发送),并安排与开发团队的发现讲解会议

Key Concepts

关键概念

TermDefinition
OWASP WSTGThe Web Security Testing Guide; a comprehensive open-source guide to testing web application security organized by test category (authentication, authorization, input validation, etc.)
IDORInsecure Direct Object Reference; a vulnerability where the application exposes internal object identifiers and fails to verify the requesting user is authorized to access that object
CSRFCross-Site Request Forgery; an attack that forces an authenticated user's browser to send a forged request to a vulnerable web application
Session FixationAn attack where the attacker sets a user's session ID to a known value before the user authenticates, then hijacks the session after login
Forced BrowsingAttempting to access application resources by directly requesting URLs not linked from the visible application, bypassing intended access controls
SSTIServer-Side Template Injection; injecting template directives into server-side template engines to achieve remote code execution
术语定义
OWASP WSTGWeb安全测试指南;一份全面的开源Web应用安全测试指南,按测试类别(认证、授权、输入验证等)分类
IDOR不安全直接对象引用;一种漏洞,应用暴露内部对象标识符,且未验证请求用户是否有权访问该对象
CSRF跨站请求伪造;一种攻击,强制已认证用户的浏览器向易受攻击的Web应用发送伪造请求
Session Fixation会话固定攻击;攻击者在用户认证前将其会话ID设置为已知值,然后在用户登录后劫持会话
Forced Browsing强制浏览;通过直接请求未在可见应用中链接的URL,尝试访问应用资源,绕过预期的访问控制
SSTI服务器端模板注入;向服务器端模板引擎注入模板指令,以实现远程代码执行

Tools & Systems

工具与系统

  • Burp Suite Professional: Primary web application testing proxy providing interception, scanning, and manual testing tools including Repeater, Intruder, and Sequencer
  • ffuf: Fast web fuzzer for directory/file discovery, parameter fuzzing, and virtual host enumeration
  • sqlmap: Automated SQL injection detection and exploitation tool supporting all major database engines and injection techniques
  • Nuclei: Template-based vulnerability scanner with community-maintained templates for known CVEs and misconfigurations
  • SecLists: Curated collection of wordlists for fuzzing, credential testing, and payload delivery used throughout web application testing
  • Burp Suite Professional:主要的Web应用测试代理,提供拦截、扫描和手动测试工具,包括Repeater、Intruder和Sequencer
  • ffuf:快速Web模糊测试工具,用于目录/文件发现、参数模糊测试和虚拟主机枚举
  • sqlmap:自动化SQL注入检测和利用工具,支持所有主流数据库引擎和注入技术
  • Nuclei:基于模板的漏洞扫描器,包含社区维护的已知CVE和配置错误模板
  • SecLists:精心整理的字典集合,用于模糊测试、凭证测试和payload交付,贯穿整个Web应用测试流程

Common Scenarios

常见场景

Scenario: E-Commerce Application Pre-Launch Security Assessment

场景:电商应用上线前安全评估

Context: A retail company is launching a new e-commerce platform built on Node.js with a React frontend and PostgreSQL database. The application handles credit card payments through Stripe integration and stores customer PII. Testing scope includes the staging environment with full API access.
Approach:
  1. Map the application through manual browsing and API documentation review, identifying 47 unique endpoints
  2. Test authentication flows including social login (OAuth), standard login, and password reset
  3. Discover IDOR vulnerability in the order retrieval API (
    /api/orders/{orderId}
    ) where any authenticated user can view any order by iterating order IDs
  4. Identify stored XSS in the product review feature that executes when administrators view the admin dashboard
  5. Find SSRF in the product image import function that allows reading AWS EC2 instance metadata
  6. Test payment logic by manipulating price values in the client-side cart before checkout submission
  7. Report all findings with specific Node.js code-level remediation (parameterized queries, input sanitization with DOMPurify, authorization middleware)
Pitfalls:
  • Testing only the frontend while ignoring the API layer that lacks independent authorization checks
  • Missing business logic flaws by relying solely on automated scanning without manual testing
  • Not testing the same functionality across different privilege levels to catch authorization issues
  • Overlooking client-side JavaScript for hardcoded API keys, debug endpoints, and internal URLs
背景:某零售公司即将推出基于Node.js、React前端和PostgreSQL数据库的新电商平台。应用通过Stripe集成处理信用卡支付,并存储客户PII(个人可识别信息)。测试范围包括具有完整API访问权限的预发布环境。
方法:
  1. 通过手动浏览和API文档审查映射应用,识别出47个唯一端点
  2. 测试认证流程,包括社交登录(OAuth)、标准登录和密码重置
  3. 发现订单检索API(
    /api/orders/{orderId}
    )中的IDOR漏洞,任何已认证用户可通过遍历orderId查看任意订单
  4. 识别出产品评论功能中的存储型XSS,当管理员查看管理控制台时会触发执行
  5. 发现产品图片导入功能中的SSRF漏洞,允许读取AWS EC2实例元数据
  6. 通过在客户端购物车中篡改价格值,测试支付逻辑
  7. 报告所有发现,并提供针对Node.js的具体代码级修复建议(参数化查询、使用DOMPurify进行输入清理、授权中间件)
常见误区:
  • 仅测试前端,忽略缺乏独立授权检查的API层
  • 仅依赖自动化扫描,遗漏手动测试才能发现的业务逻辑缺陷
  • 未在不同权限级别测试相同功能,导致遗漏授权问题
  • 忽略客户端JavaScript中的硬编码API密钥、调试端点和内部URL

Output Format

输出格式

undefined
undefined

Finding: Insecure Direct Object Reference in Order API

Finding: Insecure Direct Object Reference in Order API

ID: WEB-003 Severity: High (CVSS 7.5) Affected URL: GET /api/v1/orders/{orderId} Parameter: orderId (path parameter)
Description: The order retrieval endpoint does not verify that the authenticated user owns the requested order. Any authenticated user can access any order's details including customer name, shipping address, email, phone number, and order items by incrementing the orderId path parameter.
Reproduction Steps:
  1. Authenticate as user A (testuser@example.com)
  2. Note user A's order ID: 10451
  3. Send GET /api/v1/orders/10452 with user A's session token
  4. Observe that user B's order details are returned with full PII
HTTP Request: GET /api/v1/orders/10452 HTTP/1.1 Host: staging.example.com Authorization: Bearer eyJhbGc....[User A's token]
HTTP Response (truncated): HTTP/1.1 200 OK {"orderId":10452,"customerName":"Jane Smith","email":"jane@...","address":"123 Main St"}
Impact: An attacker can enumerate all customer orders and extract PII (names, emails, addresses, phone numbers) for an estimated 25,000 customers.
Remediation: Add authorization middleware that verifies the authenticated user's ID matches the order's userId field before returning order data. Implement UUIDs instead of sequential integers for order identifiers to prevent enumeration.
undefined
ID: WEB-003 Severity: High (CVSS 7.5) Affected URL: GET /api/v1/orders/{orderId} Parameter: orderId (path parameter)
Description: The order retrieval endpoint does not verify that the authenticated user owns the requested order. Any authenticated user can access any order's details including customer name, shipping address, email, phone number, and order items by incrementing the orderId path parameter.
Reproduction Steps:
  1. Authenticate as user A (testuser@example.com)
  2. Note user A's order ID: 10451
  3. Send GET /api/v1/orders/10452 with user A's session token
  4. Observe that user B's order details are returned with full PII
HTTP Request: GET /api/v1/orders/10452 HTTP/1.1 Host: staging.example.com Authorization: Bearer eyJhbGc....[User A's token]
HTTP Response (truncated): HTTP/1.1 200 OK {"orderId":10452,"customerName":"Jane Smith","email":"jane@...","address":"123 Main St"}
Impact: An attacker can enumerate all customer orders and extract PII (names, emails, addresses, phone numbers) for an estimated 25,000 customers.
Remediation: Add authorization middleware that verifies the authenticated user's ID matches the order's userId field before returning order data. Implement UUIDs instead of sequential integers for order identifiers to prevent enumeration.
undefined