网络安全后端【免费下载链接】juice-shopOWASP Juice Shop: Probably the most modern and sophisticated insecure web application项目地址https://gitcode.com/gh_mirrors/ju/juice-shop点击查看免费下载导读本文围绕 OWASP Juice Shop 仓库中的verify-challenge技能文档.ai/skills/verify-challenge/SKILL.md系统梳理在向 Juice Shop 提交或合并一个新挑战Challenge时必须满足的元数据、配置、翻译、教程脚本、编码挑战与测试用例等全部前置条件与项目约定。无论你是为 Juice Shop 贡献新漏洞挑战的开发者还是负责代码审查的维护者阅读本文后将掌握一套可逐项执行的验收清单并能对照仓库源码challenges.yml、lib/config.schema.ts、models/challenge.ts、config/fbctf.yml与测试目录理解每一条规则背后的实现机制。一、挑战验证的整体工作流verify-challenge技能定义了一个六步验证流程覆盖从「挑战定义」到「测试审计」的完整链路。每一步都对应仓库中的具体文件验收时应按序执行步骤动作涉及文件1分析挑战定义name、key、category、difficulty、hints 等data/static/challenges.yml2验证配置集成挑战 key 是否进入 CTF 配置体系lib/config.schema.ts、config/fbctf.yml、models/challenge.ts3检查新分类 / 新标签的翻译条目frontend/src/assets/i18n/en.json4审查配套资源Hacking Instructor 脚本、编码挑战文件frontend/src/hacking-instructor/challenges/、data/static/codefixes/5审计测试对disabledEnv约束的处理test/api、test/cypress/e2e6汇总发现缺失或错误的元数据、损坏的配置、不一致之处—二、挑战定义的权威来源data/static/challenges.yml所有挑战的「唯一事实来源」是 data/static/challenges.yml当前仓库中约定义了 100 个挑战。每个条目是一段 YAML 文档块验收时须逐项核对以下规则。2.1 name 与 key 的唯一性及 key 格式所有挑战的name与key必须全局唯一key必须使用 camelCase且通常以Challenge结尾例如loginAdminChallenge、restfulXssChallenge、passwordHashLeakChallenge。从源码看key的约束不仅是「约定」而且是「硬约束」在 models/challenge.ts 中定义了CHALLENGE_KEYS数组as const只读常量并通过type ChallengeKey typeof CHALLENGE_KEYS[number]生成联合类型数据库模型中key字段使用DataTypes.ENUM枚举值即CHALLENGE_KEYS见 models/challenge.ts。因此一个不在CHALLENGE_KEYS中的 key 根本无法入库验证挑战时务必将新 key 追加到该数组。这也解释了为何CHALLENGE_KEYS被称为 CTFcountryMapping记录 key 的 source of truth。2.2 category必须属于既有分类或新增分类category必须是一个已存在的分类或作为一个新分类补充。技能文档列出的既有分类共 17 个Broken Access Control、Broken Anti Automation、Broken Authentication、Cryptographic Issues、Improper Input Validation、Injection、Insecure Deserialization、Miscellaneous、Security Misconfiguration、Security through Obscurity、Sensitive Data Exposure、Unvalidated RedirectS、Vulnerable Components、XSS、XXE、Observability Failures。这些分类在 frontend/src/assets/i18n/en.json 中以CATEGORY_UPPER_CASE_NAME与CATEGORY_UPPER_CASE_NAME_DESCRIPTION键存在如CATEGORY_BROKEN_ACCESS_CONTROL: Broken Access Control由前端渲染分类名与说明。若引入新分类必须同步添加这两条翻译键详见第四节。2.3 difficulty1 到 6 的整数difficulty必须是 16 的整数。仓库中的真实示例印证了取值分布「Confidential Document」挑战difficulty: 1「Blocked RCE DoS」挑战difficulty: 5「Arbitrary File Write」挑战difficulty: 6。后端模型 models/challenge.ts 将其定义为DataTypes.INTEGER前端计分板frontend/src/app/score-board/也依赖该数值渲染难度星标。2.4 description允许基础 HTML但要求简洁清晰描述可包含基础 HTML 标签如i、code、a但必须保证与既有挑战的措辞风格一致简洁、清晰、句子式大小写与标点避免与已有挑战产生「相似描述 相似分类」的重复。真实示例见 data/static/challenges.yml 的 API-only XSS 条目其中嵌入了i与code转义后的 iframe payload。后端在入库时按普通字符串存储DataTypes.STRING前端渲染时会解析其中的 HTML因此标签必须正确闭合否则会破坏界面结构。2.5 hints数量与递进性上限67 条推荐35 条内容应渐进引导用户走向解法但不得直接揭示答案。以 data/static/challenges.yml 的 Password Hash Leak 为例其 3 条 hints 从「检查网络流量」→「寻找返回用户信息的 API」→「过于通用的数据检索方案可能反噬」层层递进符合验收要求。2.6 mitigationUrl必须是 OWASP 资源若存在mitigationUrl则必须指向 OWASP 资源当存在与挑战范围匹配的OWASP Cheat Sheet时强烈优先使用之。仓库中的真实取值包括https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.htmlXSS 类挑战https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.htmlAdmin Registrationhttps://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposurePassword Hash Leak。少数挑战可显式声明mitigationUrl: ~null例如 data/static/challenges.yml 的 Blockchain Hype 挑战模型层 models/challenge.ts 也将其声明为CreationOptionalstring | null。2.7 tags可选的语义标记tags为可选字段当前仓库中的既有标签包括Danger Zone、Good for Demos、Prerequisite、OSINT、Contraption、Shenanigans、Tutorial、Brute Force、Good Practice、Code Analysis、Web3、With Coding Challenge、AI / LLM。真实用法示例「Blocked RCE DoS」同时标记Danger Zone见 data/static/challenges.yml「Blockchain Hype」标记了Contraption、Code Analysis、Web3三个标签见 data/static/challenges.yml。在 models/challenge.ts 中tags以string | undefined声明YAML 列表序列化为字符串存储而en.json为每个标签维护了显示名与说明如TAG_DANGER_ZONE_DESCRIPTION: Marks potentially dangerous challenges which are disabled on Docker/Heroku by default...。2.8 disabledEnv环境禁用约束disabledEnv可选值为Docker、Heroku、Windows用于标记那些在特定部署环境中技术上不兼容或过于危险的挑战典型如 RCE 类挑战。真实示例restfulXssChallenge、rceChallenge、persistedXssUserChallenge均同时禁用了Docker与Heroku见 data/static/challenges.yml、data/static/challenges.yml。该字段的运行时语义在 lib/utils.ts 的getChallengeEnablementStatus中实现当挑战存在disabledEnv且当前运行在对应环境通过isDocker()/isHeroku()/isWindows()判定时返回enabled: false同时若配置的safetyMode为enabled无论处于何种环境都会禁用带disabledEnv的挑战返回disabledBecause: Safety Mode而safetyMode: disabled则无条件放行。理解这一逻辑是第五节「测试审计」的前提。三、配置层集成CTF 模式下的三处同步新挑战必须无缝接入 CTFCapture The Flag模式配置技能文档要求同步修改三个文件。3.1models/challenge.ts追加 CHALLENGE_KEYS如前所述models/challenge.ts 的CHALLENGE_KEYS是挑战 key 的唯一权威枚举。CTF 配置中的ctf.countryMapping记录键必须严格限定在该枚举内——这一点由 lib/config.schema.ts 保证export const ChallengeKeySchema z.enum(CHALLENGE_KEYS as unknown as [ChallengeKey, ...ChallengeKey[]]) const CountryEntrySchema z.object({ name: z.string(), code: z.string() }) export const CountryMappingSchema z.record(ChallengeKeySchema, CountryEntrySchema)也就是说任何未在CHALLENGE_KEYS中注册的挑战 key连配置校验这一关都过不了z.record的键类型即ChallengeKeySchema。3.2lib/config.schema.tsCTF 配置的 Zod 校验lib/config.schema.ts 中的CtfSchema定义了完整的 CTF 配置结构export const CtfSchema z.object({ showFlagsInNotifications: z.boolean(), showCountryDetailsInNotifications: z.enum([none, name, flag, both]), countryMapping: CountryMappingSchema.nullable().optional(), systemWideNotifications: z.object({ ... }).optional() })其中showCountryDetailsInNotifications控制挑战解出后通知中展示的国家信息粒度不显示 / 仅名称 / 仅国旗 / 两者兼有。这些校验规则由 lib/startup/validateConfig.ts 在服务启动阶段执行配置不合法会直接导致启动失败。3.3config/fbctf.ymlcountryMapping 条目config/fbctf.yml 是 CTF 模式的典型配置示例在ctf.countryMapping下为每个挑战分配一个国家名与 ISO 3166-1 alpha-2 国家代码。真实条目示例如下ctf: showFlagsInNotifications: true showCountryDetailsInNotifications: both countryMapping: scoreBoardChallenge: name: Canada code: CA loginAdminChallenge: name: Russian Federation code: RU unionSqlInjectionChallenge: name: Slovakia code: SK redirectCryptoCurrencyChallenge: name: Korea code: KR验收要点每个新挑战 key 必须在countryMapping下有一条对应记录name国家名与code国家代码在该文件中必须各自唯一避免 CTF 框架中出现冲突。四、国际化新分类与新标签的翻译条目若新挑战引入了新分类category或新标签tag必须在 frontend/src/assets/i18n/en.json 中添加对应键规则如下分类新增CATEGORY_UPPER_CASE_NAME与CATEGORY_UPPER_CASE_NAME_DESCRIPTION标签新增TAG_UPPER_CASE_NAME与TAG_UPPER_CASE_NAME_DESCRIPTION命名名称中的空格替换为下划线如Good for Demos→GOOD_FOR_DEMOS。仓库中的实际键位分布frontend/src/assets/i18n/en.jsonTAG_DANGER_ZONE/TAG_DANGER_ZONE_DESCRIPTIONTAG_GOOD_FOR_DEMOS/TAG_GOOD_FOR_DEMOS_DESCRIPTIONTAG_WITH_CODING_CHALLENGE/TAG_WITH_CODING_CHALLENGE_DESCRIPTIONCATEGORY_BROKEN_ACCESS_CONTROL/CATEGORY_BROKEN_ANTI_AUTOMATION等全部分类键。注意TAG_AI/LLM是唯一包含斜杠的标签键其余标签均遵守「空格转下划线 全大写」约定。此外仓库为每种语言维护了独立的 JSON 文件frontend/src/assets/i18n/ 下共 43 个语言包新增键后各语言包会通过 crowdin 等流程同步翻译但en.json 是所有语言的基准验收时只要求英文键存在即可。五、Hacking Instructor 脚本tutorial 挑战如果挑战在 data/static/challenges.yml 中声明了tutorial例如adminSectionChallenge的tutorial: { order: 8 }则必须配套编写 Hacking Instructor 脚本脚本文件必须位于 frontend/src/hacking-instructor/challenges/文件名应与挑战key匹配有时省略Challenge后缀。仓库中已存在 14 个脚本如 frontend/src/hacking-instructor/challenges/loginAdmin.ts、scoreBoard.ts、domXss.ts、privacyPolicy.ts等。以loginAdmin.ts为例其导出的LoginAdminInstruction结构如下export const LoginAdminInstruction: ChallengeInstruction { name: Login Admin, hints: [ { text: To start this challenge, youll have to log out first., fixture: #navbarAccount, unskippable: true, resolved: waitForLogOut() }, { /* ...更多提示步骤... */ } ] }脚本规则要点遵循官方 Tutorials 指南的编写规范有效使用highlight与text步骤对应fixture选择器与text提示文本借助 frontend/src/hacking-instructor/helpers/helpers.ts 中提供的等待函数如waitForInputToHaveValue、waitForAngularRouteToBeVisited、waitForLogOut语调与复杂度必须与既有脚本保持一致关键步骤可设置unskippable: true强制用户按顺序完成。验收时应确认脚本能通过tutorial声明正确关联到挑战且所有fixture选择器在真实页面中存在。六、编码挑战Coding Challenge配套文件若挑战带有编码挑战对应With Coding Challenge标签则必须在 data/static/codefixes/ 中提供配套文件标准结构为challengeKey.info.yml包含fixes每种修复方案的说明与hints引导提示challengeKey_1_correct.ts修复后的正确版本代码片段challengeKey_2.ts、challengeKey_3.ts等带漏洞的变体版本。仓库中 40 组 codefixes 文件均可作为范式。以loginAdminChallenge为例其信息文件 data/static/codefixes/loginAdminChallenge.info.yml 定义了 4 种修复方案id 14分别说明自定义黑名单拦截注定失败、仅部分使用 Sequelize 绑定仍可注入、正确绑定但引入功能性 bug、以及完整使用绑定机制等价于 Prepared Statement 的正确修复。对应代码文件包括正确版 data/static/codefixes/loginAdminChallenge_4_correct.ts使用bind: [...]参数绑定与loginAdminChallenge_1.ts_3.ts等漏洞变体。验收要点正确版与每个漏洞变体的说明都必须清晰让学习者理解为何对、为何错文件命名遵循key_n[_correct].ts约定_correct后缀唯一标识正确方案遵循官方 Code Snippets 指南的写法。后端通过 routes/vulnCodeFixes.ts 与 routes/vulnCodeSnippet.ts 提供编码挑战的 API并由 lib/codingChallenges.ts 计算挑战的codingChallengeStatus见 models/challenge.ts 的codingChallengeStatus与hasCodingChallenge字段。七、测试审计disabledEnv必须由测试显式处理第六步是整个验收流程的关键只要挑战声明了disabledEnv对应的 API 测试或 Cypress 端到端测试就必须用启用检查包裹否则测试会在禁用该挑战的环境如 Docker中失败。标准写法如下if (utils.isChallengeEnabled(challenges.myNewChallenge)) { it(should solve my new challenge..., () { // test logic }) }导入约定utils来自../../lib/utilschallenges来自../../data/datacacheAPI 测试Cypress 测试则视类型从对应位置导入。仓库中的真实范例位于 test/api/user.test.ts由于persistedXssUserChallenge声明了disabledEnv: [Docker, Heroku]其「POST new user with XSS attack in email address」用例被utils.isChallengeEnabled(challenges.persistedXssUserChallenge)条件包裹。类似模式还出现在 test/api/b2b-order.test.ts、test/api/feedback.test.ts、test/api/file-upload.test.ts、test/api/product.test.ts 中。支撑该检查的底层函数链为isChallengeEnabledlib/utils.ts→getChallengeEnablementStatuslib/utils.ts后者基于当前运行环境Docker / Heroku / Windows与challenges.safetyMode配置综合判定启用状态。八、推断规则与最佳实践技能文档补充的隐性规则同样应纳入验收清单一致性挑战名称应令人印象深刻但不宜过长描述与 hints 遵循既有风格句子式大小写、规范标点。HTML 净化描述中的 HTML 标签必须正确闭合避免破坏前端渲染。去重检测新增挑战前先搜索既有挑战中相似的名称、分类或描述确保新挑战提供独特价值。难度校准参考1入门级无需任何工具23中级需要 DevTools 或 Burp/ZAP 等基础工具45高级需要复杂的绕过、脚本编写或深入研究6专家级多步骤、冷门漏洞或高技术门槛。仓库中难度为 6 的真实案例是「Arbitrary File Write」fileWriteChallenge其解法涉及第三方库的任意文件覆盖漏洞需要从多处文件上传点中识别受影响的那一个属于典型的高技术门槛挑战。九、验收流程小结Checklist将技能文档的六步工作流压缩为一份可直接对照的最终检查表挑战定义name/key唯一且key为 camelCase Challenge后缀category合法difficulty∈ [1, 6]description简洁且 HTML 闭合hints数量 ≤ 7 且递进mitigationUrl指向 OWASP优先 Cheat Sheettags来自既有集合disabledEnv取值 ∈ {Docker, Heroku, Windows}。配置集成key已追加至 models/challenge.ts 的CHALLENGE_KEYSconfig/fbctf.yml 的ctf.countryMapping已添加唯一国家名与国家代码。翻译新分类/新标签的CATEGORY_*、TAG_*键已加入 frontend/src/assets/i18n/en.json。配套资源tutorial挑战有对应 Hacking Instructor 脚本编码挑战有key.info.yml与_correct/漏洞变体文件。测试带disabledEnv的挑战其 API 与 Cypress 测试均以isChallengeEnabled包裹。汇总报告输出缺失/错误元数据、损坏配置与不一致之处。以上任一条目不满足新挑战都不应被合入主分支而逐一核对该清单的过程也正是verify-challenge技能所定义的完整验收闭环。赞分享网络安全后端【免费下载链接】juice-shopOWASP Juice Shop: Probably the most modern and sophisticated insecure web application项目地址https://gitcode.com/gh_mirrors/ju/juice-shop点击查看免费下载相关推荐OpenClaw 发布验证实战基于 verify-release Skill 校验常规与 Extended-Stable 发布完整性OpenClaw 发布验证实战基于 verify release Skill 校验常规与 Extended Stable 发布完整性 OpenClaw“ThAI 应用AI Agent交互助手后端即时通讯网关OWASP Juice Shop 网络安全实战完整教程在当今数字化时代Web应用安全已成为每个开发者和安全从业者必须掌握的技能。OWASP Juice Shop作为业界公认的最佳网络安全培训平台通过模拟真实电商网络安全后端Linter for Zotero基于自动校验与修复的元数据规范化插件实战指南Linter for Zotero基于自动校验与修复的元数据规范化插件实战指南 导读 本文围绕开源插件 zotero format metadata http开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考