diff --git a/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/15-Test_for_Feature_Flag_Security_Bypass.md b/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/15-Test_for_Feature_Flag_Security_Bypass.md new file mode 100644 index 0000000000..59b3c6e18e --- /dev/null +++ b/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/15-Test_for_Feature_Flag_Security_Bypass.md @@ -0,0 +1,188 @@ +# Testing for Feature Flag Security Bypass + +|ID | +|------------| +|WSTG-CONF-15| + +## Summary + +Feature flags (also known as feature toggles, feature switches, or feature gates) are a software development technique that allows teams to enable or disable functionality without fully deploying (or exposing) new code. While feature flags provide significant benefits for progressive delivery and A/B testing, they can introduce security vulnerabilities when improperly implemented. + +Common security issues with feature flags include: + +- **Client-side manipulation**: Flags evaluated in the browser can be modified by attackers to enable restricted features. +- **Authorization bypass**: Hidden UI elements may still have accessible backend endpoints. +- **Information disclosure**: Flag configurations may leak unreleased features or internal logic. +- **Insecure defaults**: Fallback values when the flag service is unavailable may fail open. +- **Stale flag vulnerabilities**: Unused flags referencing deprecated code paths may contain unpatched vulnerabilities. + +Modern applications increasingly rely on feature flag services (such as: LaunchDarkly, Split, Flagsmith, ConfigCat) or custom implementations for control roll-outs, making security testing of these mechanisms essential. + +## Test Objectives + +- Identify feature flags that gate security-relevant functionality. +- Assess whether feature flag states can be manipulated client-side. +- Verify that backend authorization is independent of flag state. +- Determine if flag configurations expose sensitive information. +- Evaluate fail-safe behavior when the flag service is unavailable. + +## How to Test + +### Identify Feature Flags in the Application + +Search for evidence of feature flag implementations: + +1. **Inspect JavaScript bundles** for references to feature flag services or configuration objects: + +```javascript +// Common patterns to search for: +featureFlags +featureToggles +flags.isEnabled +LaunchDarkly +splitio +flagsmith +``` + +1. **Monitor network traffic** for requests to feature flag endpoints: + +```http +GET /api/features HTTP/1.1 +Host: example.com + +HTTP/1.1 200 OK +Content-Type: application/json + +{ + "features": { + "new_checkout_flow": true, + "admin_panel_v2": false, + "beta_api": false + } +} +``` + +1. **Examine localStorage and cookies** for cached flag values. + +### Test Client-Side Flag Manipulation + +Attempt to modify flag values to enable restricted features: + +1. **Intercept and modify responses**: Use a proxy tool to change flag values from `false` to `true` in API responses. + +```http +# Original response +{"admin_mode": false} + +# Modified response +{"admin_mode": true} +``` + +1. **Modify localStorage**: If flags are cached client-side, change the values directly. + +```javascript +// In browser console +localStorage.setItem('featureFlags', JSON.stringify({ + ...JSON.parse(localStorage.getItem('featureFlags')), + restricted_feature: true +})); +``` + +1. **Observe application behavior**: Determine if the application grants access to functionality that should be restricted. + +### Verify Backend Authorization Independence + +Ensure backend endpoints enforce authorization independently of flag state: + +1. **Identify hidden endpoints**: Extract API endpoints from JavaScript bundles that are associated with disabled features. + +```bash +# Search for API patterns in JS files +grep -oE '/api/v[0-9]+/[a-zA-Z_]+' bundle.js +``` + +1. **Send direct requests**: Attempt to access endpoints for disabled features. + +```http +POST /api/admin/users/delete HTTP/1.1 +Host: example.com +Authorization: Bearer +Content-Type: application/json + +{"user_id": "12345"} +``` + +1. **Expected result**: The server should return `403 Forbidden` if the feature is disabled, not just hide the UI. + +### Test Fallback Behavior + +Evaluate what happens when the feature flag service is unavailable: + +1. **Block connectivity** to the flag provider using browser DevTools network blocking or hosts file modification. + +```bash +# Add to /etc/hosts (testing only) +127.0.0.1 sdk.launchdarkly.com +127.0.0.1 app.split.io +``` + +1. **Observe fallback behavior**: Determine if the application fails open (enables features) or fails closed (disables features). +1. **Security-critical result**: Features gating security controls should default to disabled when the flag service is unreachable. + +### Analyze Flag Configuration for Information Leakage + +Examine flag payloads for sensitive information: + +1. **Capture flag configuration responses** and look for: + - Unreleased feature names revealing roadmap + - Internal tool references + - Targeting rules containing email domains or user identifiers + - Environment-specific configurations + +1. **Example of information leakage**: + +```json +{ + "flags": { + "internal_admin_tool_q1_2025": false, + "bypass_rate_limit_for_enterprise": false, + "show_feature_if_email_contains_@internal.company.com": true + } +} +``` + +### Test for Stale Feature Flags + +Identify and test unused flags that may expose deprecated functionality: + +1. **Map all flags** and their creation dates if available. +1. **Force-enable old flags** and observe if deprecated code paths are accessible. +1. **Assess deprecated code** for known vulnerabilities or security weaknesses. + +## Remediation + +To prevent feature flag security bypass vulnerabilities: + +- **Server-side evaluation**: Evaluate security-critical flags on the server, never trust client-provided values. +- **Authorization independence**: Backend authorization checks must not depend on flag state. +- **Fail-secure defaults**: Configure security-relevant flags to default to disabled if the flag service fails. +- **Minimal client exposure**: Only send flag evaluation results to clients, not targeting rules or full configurations. +- **Flag hygiene**: Implement policies to remove flags after their purpose is complete (typically 30-90 days post-launch). +- **Audit logging**: Log flag evaluations for security-critical features. + +For more details, see: + +- [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) +- [OWASP Top Ten - A01:2021 Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) + +## Tools + +- [Burp Suite](https://portswigger.net/burp) - Intercept and modify HTTP traffic +- [ZAP](https://www.zaproxy.org/) - Web application security testing +- Browser Developer Tools - Network inspection and localStorage modification + +## References + +- [Feature Toggles (aka Feature Flags) - Martin Fowler](https://martinfowler.com/articles/feature-toggles.html) +- [LaunchDarkly Account Security](https://launchdarkly.com/docs/home/account/secure) +- [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) diff --git a/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md b/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md index e501008763..6fb0089a77 100644 --- a/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md +++ b/document/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md @@ -27,3 +27,5 @@ 4.2.13 [Test for Path Confusion](13-Test_for_Path_Confusion.md) 4.2.14 [Test for Other HTTP Security Header Misconfigurations](14-Test_Other_HTTP_Security_Header_Misconfigurations.md) + +4.2.15 [Test for Feature Flag Security Bypass](15-Test_for_Feature_Flag_Security_Bypass.md)