# Unicode 安全反模式 **严重性：** 中 ## 总结应用程序无法处理 Unicode 字符表示变体，从而导致用户名欺骗、网络钓鱼和验证绕过： 1. **易混淆的字符（同形文字）：** 来自不同文字的外观相同的字符（拉丁语“a”与西里尔语“а”）。 2. **标准化问题：** 同一字符的多个字节序列（预组合与基本+组合重音）。 3. **零宽度字符：** 隐藏恶意内容或改变字符串长度的非打印字符。 4. **双向文本覆盖：** 控制字符重新排序显示（将“exe.pdf”混淆为“fdp.exe”）。 ## 反模式反模式是在不进行规范化、易混淆检测或控制字符剥离的情况下处理 Unicode 字符串。 ### 错误代码示例 # 漏洞：在没有规范化或易混淆检测的情况下比较字符串。 defauthenticate_user（提供的用户名，密码）： # 此示例假设 `fetch_user_from_db` 需要来自数据库的确切字符串。存储的用户 = fetch_user_from_db(提供的用户名) 如果stored_user和stored_user.password == hash_password(password): # “管理员”帐户存在。 # 攻击者使用用户名“аadmin”（西里尔字母“a”）注册帐户。 # 数据库存储“аadmin”。 # 当攻击者尝试以“admin”身份登录时，“provided_username”是“admin”。 # `fetch_user_from_db` 找到攻击者的“admin”用户。 # 但如果应用程序内部将“аadmin”处理为“admin” # 在其他地方进行检查，例如 `if username == "admin"`, # 那么“аadmin”可能会绕过此检查。 # 或者，更直接地，如果 `fetch_user_from_db` 不区分大小写/规范化： # 攻击者注册“Admin”（拉丁语 A）。 # 合法用户是“admin”（拉丁文a）。 # 两者都可能解析为同一个内部用户，或者一个用户可以欺骗另一个用户。返回真返回错误 # 又例如：域名中允许使用易混淆的字符。 # 攻击者注册“paypal.com”（带有西里尔字母“a”） # 这看起来与“paypal.com”（带有拉丁语“a”）相同，可以进行网络钓鱼。 ### 好的代码示例 # 安全：一致地标准化、过滤和比较 Unicode 字符串。导入unicode数据进口再 def normalize_and_sanitize_username(用户名): # 1.标准化为规范形式（NFC）以进行一致的比较。 # NFC 将组合字符替换为预先组合的等效字符。标准化 = unicodedata.normalize('NFC', 用户名) # 2. 去除零宽度和双向控制字符。 # 防止显示操纵和隐藏内容。 sanitized = re.sub(r'[\u200B-\u200F\u202A-\u202E\u2066-\u2069]', '', 标准化) # 3. 应用易混淆检测（推荐用于关键标识符）。 # 转换为“骨架”形式或使用易混淆数据库。 #（实现取决于特定的库/算法）。 # 4. 强制执行允许字符的白名单。 # 对于用户名，限制为 ASCII 字母数字和有限符号。如果不是 re.fullmatch(r'^[a-zA-Z0-9_.-]+$', 已清理)： raise ValueError("用户名包含不允许的字符。") 返回已消毒 defauthenticate_user_secure（提供的用户名，密码）： # 在存储和比较之前，所有用户名都应该一致地标准化和清理。 sanitized_username = normalize_and_sanitize_username(provided_username) 存储的用户 = fetch_user_from_db(sanitized_username) 如果stored_user和stored_user.password == hash_password(password): 返回真返回错误 # 显示用户名或域名时，考虑使用 Punycode 作为国际化域名 (IDN) # 让欺骗对用户来说更加明显。 ## 检测 * **检查字符串比较：** 查找用户控制字符串的任何比较，尤其是身份验证、授权或访问控制决策。 * **检查输入处理：** 查看输入字符串从接收到存储和显示的处理方式。标准化步骤是否一致应用？ * **使用易混淆的字符进行测试：** 尝试注册使用同形文字（例如，西里尔字母“a”而不是拉丁语“a”）的用户名或域名作为常见保留名称（admin、root）或知名品牌（paypal、apple）。 * **使用零宽度字符进行测试：** 将零宽度字符（例如，`\u200B`）插入到输入中，以查看它们是否绕过长度检查或字符串比较。 ## 预防 * **标准化所有 Unicode 输入：** 在验证、存储或比较之前将所有字符串转换为 NFC（标准化形式 C）。 * **删除危险控制字符：** 删除零宽度空格 (`\u200B`)、双向覆盖 (`\u202E`) 和非打印字符。 * **实施易混淆检测：** 对于关键标识符（用户名、域），使用框架形式或易混淆数据库检查同形文字。 * **限制字符集：** 对于敏感标识符，限制为明确定义的字符集（首选 ASCII 字母数字）。 * **一致应用：** 在整个应用程序（输入、存储、比较、显示）中使用相同的 Unicode 处理（标准化、剥离、过滤）。 ## 相关安全模式和反模式 * [编码绕过反模式]()：Unicode问题是一种可以绕过安全过滤器的特定类型的编码操作。 * [缺少输入验证反模式]()：无法正确处理 Unicode 是不正确的输入验证的一种形式。 * [跨站脚本 (XSS) 反模式]()：恶意 Unicode 字符有时可用于绕过 XSS 过滤器。＃＃参考 * [OWASP Top 10 A05:2025 - 注入]() * [OWASP GenAI LLM05:2025 - 不正确的输出处理]() * [OWASP API 安全 API8:2023 - 安全配置错误]() * [CWE-176：Unicode 处理不当]() * [CAPEC-71：使用 Unicode 编码绕过验证]() * [Unicode 安全注意事项]() * [Unicode 易混淆项]() * 来源：[sec-context]()

Unicode 安全反模式

包含技能