Web Security Basics Every Developer Must Know — txt1.ai

作者：Marcus Chen，财富500强金融科技公司高级安全工程师，拥有12年强化处理超过20亿美元日常交易的web应用经验

三年前，我看到一位初级开发者在一个星期五下午4:47将代码推送到生产环境。到下午6:15，我们的安全运营中心像圣诞树一样亮了起来。一个看似无害的搜索功能中的SQL注入漏洞暴露了340,000个客户记录。这次泄露使我们花费了420万美元进行补救、支付监管罚款和损失业务。而这位开发者？是一位才华横溢的工程师，只是他对网络安全所知甚少。

这次事件改变了我对安全教育的看法。我意识到，大多数开发者并不是鲁莽的，他们只是处于知识真空中。计算机科学课程如果运气好可能只花两周时间讲授安全。培训班往往完全跳过这部分。然而，我们被期望在只知道如何堆砖的情况下建立堡垒。

在过去的十年里，我一直在网络安全的前线，从渗透测试到构建被200多名开发者使用的安全框架。我见证了攻击从粗糙的脚本小子尝试演变为复杂的国家级行为。我了解到，基本原理——每位开发者必须内化的基础知识——并没有像你想的那样改变。掌握这些核心原则，你将能防止我每天在生产代码中看到的90%的漏洞。

理解攻击面：你真正保护的是什么

当我问开发者他们在保护什么时，我通常听到的答案是“用户数据”或“数据库”。这并没有错，但不够完整。你的攻击面是你应用程序接受输入、处理数据或与外部系统交互的每一个点。它包括登录表单，但也包括你为内部使用而编写的API端点、管理面板中的文件上传功能，甚至是你向用户显示的错误消息。

让我给你一个具体的例子。我们有一个内部API端点，用于接受JSON负载进行批量用户更新。它是“仅限内部使用”的——不需要身份验证，因为它只能通过我们的VPN访问。除了有人错误配置了反向代理，突然间该端点被暴露到互联网约18小时，直到我们发现。在这18小时内，自动扫描器已经找到了它，并尝试了2847种不同的攻击向量。

攻击面还包括你package.json或requirements.txt中的每一个依赖。当2021年12月Log4Shell漏洞出现时，我花了72个连续小时帮助团队识别和修补受影响的系统。漏洞不在我们编写的代码中——它在一个作为依赖项的依赖日志库中。你的攻击面遍及你整个依赖树，对于一个典型的Node.js应用程序，可能包括800多个软件包。

考虑一下你应用程序的信任边界。可信数据从哪里进入你的系统？每个表单字段、每个URL参数、每个HTTP标头、每个cookie、每个API请求体。如果它来自于你服务器的内存之外，那就是不可信的。我见过开发者仔细验证表单输入，但完全忽略URL参数，或处理POST数据时进行清理，而让GET参数处于完全开放状态。攻击者并不关心你对“应当”验证的心理模型——他们会探测一切。

你的攻击面还包括基于时间的漏洞。你生成的密码重置令牌呢？如果它是可预测的或没有过期，则构成攻击向量。会话标识符、API密钥、临时文件名——任何攻击者可能猜测或暴力破解的东西，只要给他们足够的时间。我曾发现一个系统，其中密码重置令牌只是连续的整数。攻击者可以请求重置自己账户的密码，看到令牌45231，然后尝试令牌45230、45229、45228来重置其他用户的密码。

输入验证：你的第一道防线

如果我可以把一个原则纹在每位开发者的额头上，那就是：绝不要信任用户输入。无论是来自你的移动应用的输入，还是来自你“可信”合作伙伴的API，甚至是你自己前端JavaScript的输入。所有跨越信任边界的数据都必须经过验证、清理，并视为可能恶意，直到另作证明。

最危险的漏洞不是黑客发现的漏洞——而是开发者不知道它们存在于自己代码中的漏洞，直到为时已晚。

我看到开发者一次又一次地犯同样的错误：他们在前端验证输入，认为这就足够了。现实是——我可以在大约15秒内使用浏览器开发工具或简单的curl命令绕过你的前端验证。前端验证属于用户体验，而不是安全。真正的验证发生在服务器上，每一次都需要，没有例外。

有效的输入验证有三个组成部分：类型检查、格式验证和业务逻辑验证。类型检查确保一个期望接收数字的字段实际上接收到数字，而不是包含SQL注入尝试的字符串。格式验证使用允许清单（而不是拒绝清单）确保数据与预期模式匹配。如果你期望的是一个电子邮件地址，请使用合适的电子邮件正则表达式进行验证。如果你期望的是美国电话号码，请明确验证格式。

业务逻辑验证是大多数开发者停止思考的地方。仅仅因为某些东西在技术上是有效的，并不意味着它在你的应用程序上下文中有意义。我曾审查过一段代码，其中一个购物车允许负数量。开发者验证了输入是整数，但从未检查它是否为正数。攻击者可以“购买” -100 个项目，而得到一个信用而不是被收费。修复是微不足道的，但这个疏忽让公司损失了23,000美元，直到被发现。

我的实际方法是：为你的应用程序接受的每个输入定义严格的模式。使用像Joi这样的验证库用于Node.js，Pydantic用于Python，或使用Laravel或Django这样的框架中的内置验证。这些库让你可以准确声明什么是有效的输入，并默认拒绝所有其他内容。当验证失败时，进行记录。来自相同IP地址或用户账户的重复验证失败可能表明正在进行攻击。

还有一点至关重要：在每一层都进行验证。如果数据从你的API流向后台作业再到数据库，请在每一步都进行验证。我见过利用API验证与后台作业处理之间差距的攻击。API正确验证了输入，但后台作业认为数据是安全的，因为它来自数据库。能够直接写入数据库的攻击者（通过一个单独的漏洞）可以绕过所有验证。

认证与授权：了解谁和什么

认证回答“你是谁？” 授权回答“你被允许做什么？” 混淆这两个概念，或者对它们的实现不当，会产生我遇到的最容易被利用的漏洞。我见过拥有坚如磐石的认证系统，却让任何经过身份验证的用户访问任何其他用户数据，因为授权只是事后的思考。