AppSec 基础：保护你的应用程序的核心
Source: Dev.to
作为软件工程师，我们习惯于构建能够正常运行的功能。在应用安全（AppSec）领域，思路会发生转变：我们的目标是确保这些功能不会被破坏。本文旨在帮助你完成这种思维方式的转变，聚焦于你每天设计安全系统和优先处理漏洞时所依赖的核心原则。
CIA三要素
-
机密性 (Confidentiality): 确保敏感数据仅对授权方可访问。
承诺: “我会保守你的秘密”。 -
完整性 (Integrity): 确保数据保持准确、完整且未被篡改，除非授权用户进行修改。
承诺: “我不会让任何人篡改你的数据”。 -
可用性 (Availability): 确保系统和数据在授权用户需要时可访问。
承诺: “当你需要时，我会在”。
思维模型: 想象一个银行金库。厚实的墙壁和经理的钥匙代表机密性；如果你存入100美元并取出100美元（而不是其他金额）的保证代表完整性；银行在营业时间开放则代表可用性。
忽视这些支柱中的任何一个都会导致严重后果：API 密钥或个人数据泄露（机密性）、SQL 注入攻击导致数据库被篡改（完整性）以及 DDoS 攻击导致服务中断（可用性）。
Source: …
风险管理
在 AppSec 中我们不可能把所有问题都解决掉。风险管理是识别、评估并优先处理威胁的过程，以将风险降低到业务可接受的水平。
关键公式：
Riesgo = Probabilidad × Impacto- Probabilidad（可能性）：漏洞被利用的难易程度如何？是否有公开的利用代码？
- Impacto（影响）：如果被利用会造成什么损害？是影响单个用户还是整个数据库？
思维模型：像急诊护士一样进行分诊。如果有一位患者只是纸割伤（影响低），另一位心脏病发作（影响高），你会先处理心脏病发作的患者，即使纸割伤的发生概率是 100 %。
为了管理风险，开发人员应采用 威胁建模（Threat Modeling）（在编写代码前自问“可能会出什么问题？”），并使用 CVSS 等系统对漏洞进行客观评分。
身份验证 vs. 授权
虽然常被混淆，但它们的区别对安全至关重要。
- 身份验证 (AuthN) – 你是谁？ 验证用户或系统的身份（例如通过密码、令牌或生物识别）。
- 授权 (AuthZ) – 你被允许做什么？ 确定已通过身份验证的身份可以访问哪些资源。
思维模型：你的驾驶执照用于身份验证（通过照片和姓名证明你是谁）。同一执照上的年龄用于授权（决定你是否可以购买酒精或租车）。
授权失误，如 IDOR（不安全的对象直接引用），即用户在 URL 中更改 ID 以查看他人数据，是最常见且最危险的之一。黄金法则是：“默认拒绝”，并在每个请求中检查权限，而不仅在登录时检查。
开发中的安全原则（Shift‑Left）
- 深度防御：不要依赖单一控制。使用多层（WAF、加密、输入验证、监控），以便其中一层失效时，其他层仍能保护系统。
- 最小特权原则：用户和系统只能拥有完成工作所需的最小权限。
- 密钥管理：切勿在源代码或 Git 中保存密钥或密码。使用密钥库（如 AWS Secrets Manager 或 HashiCorp Vault）和短期令牌。
- 输入验证：将所有用户输入视为潜在恶意。使用参数化查询以防止 SQL 注入。
- CI/CD 流水线安全：扫描依赖项以查找已知漏洞，并在部署前对代码进行静态分析（SAST）。
结论
安全不是一个检查清单，而是一种在构建防御时像攻击者一样思考的心态。通过掌握 CIA 三要素，了解风险并正确区分身份验证和授权，你将不再只是功能开发者，而成为你应用完整性的第一守护者。