应用安全
应用安全考查 Web 与接口层常见漏洞的成因与修复，以及安全开发生命周期中的活动。题目多给一段代码或业务场景，要求判断漏洞类型并选出最优修复措施。
常见漏洞与根因
- 注入（SQL/命令/LDAP）：数据被当作代码解析；修复靠参数化查询、白名单校验、最小权限。
- 失效的身份认证：弱口令、会话固定、无登录失败限制。
- 失效访问控制：水平越权（改 ID 看他人数据）与垂直越权（普通用户调用管理接口）。
- XSS：存储型、反射型、DOM 型，脚本在受害者浏览器中执行。
- CSRF：借用户已认证的 Cookie 伪造请求，攻击者看不到响应。
- SSRF：服务端被诱导访问内网地址，可读取云元数据服务。
- 不安全反序列化：可控数据反序列化导致远程代码执行。
- 组件漏洞与配置错误：默认口令、目录列举、未关闭的调试接口。
防御要点
- 输入校验用白名单与长度、类型约束；输出按上下文编码（HTML 正文、属性、JS、URL 各不相同）。
- Cookie 加 HttpOnly、Secure、SameSite；登录成功后重建会话 ID。
- 关键操作加 CSRF Token；每个对象访问都做归属校验。
- 部署 CSP、WAF 作纵深防御，但不能替代代码修复。
- 文件上传：扩展名白名单、重命名、存入不可执行目录、独立域名。
- SDL：需求定安全需求，设计做 STRIDE 威胁建模，编码用 SAST，测试用 DAST/IAST 与渗透测试，上线后做漏洞响应。
工作示例
某后台“查看订单”接口为 GET /order?id=1001，任意登录用户改 id 即可看他人订单。判断：这是水平越权（失效访问控制），不是 SQL 注入，也不是 CSRF。修复：服务端用当前会话用户 ID 与订单归属比对，或查询时强制附加 owner=当前用户；同时改为 POST 并加 CSRF Token，对 id 做格式校验。只在前端隐藏按钮无效，因为请求可手工构造。
高频陷阱
- 用前端校验替代服务端校验。
- 认为 HttpOnly 能防 CSRF，它防的是脚本读取 Cookie。
- 把 XSS 修复写成“过滤 script 标签”，正确做法是按上下文做输出编码。