1,697 讀數

创建 Web 项目前要问自己的五个问题

经过 Filipp Shcherbanich9m2024/08/01

太長; 讀書

Web 项目失败的原因有很多。在本文中，我将分享我的经验，以帮助您解决其中的一些问题。

技术项目失败的原因有百万种。商业模式计算错误、需求估计过高或成本膨胀，等等。但在我的职业生涯中，我看到不少拥有绝妙想法和良好潜力的项目因看似微小的错误和疏忽而失败。我认为这个原因是最痛苦的，至少对我这个开发人员来说是这样。在本文中，我想分享我的经验，并分析后端开发人员在 Web 应用程序中面临的问题和挑战。我将重点介绍经常被忽视的关键点，并解释如何以最高效率解决这些障碍。我相信这将帮助您最大限度地降低风险并显著提高项目成功的机会。

1. 你的代码中是否存储了任何秘密？

无论听起来多么明显，这一点都至关重要：永远不要在源代码中存储机密或敏感信息。违规可能会导致财务损失和其他严重问题。永远不应存储在代码中的敏感信息包括：

内部或外部服务的 API 密钥和访问令牌
密码和帐户数据，包括数据库和管理系统密码
加密密钥
包含敏感数据的配置文件
安全问题的答案，例如母亲的娘家姓或宠物的名字

不要将此类信息存储在项目代码中，而是使用环境变量。对于更安全的系统，请考虑使用强大的秘密存储解决方案，例如HashiCorp Vault 。 AWS Secrets Manager或者GitHub 机密也可能有用。秘密存储工具的选择取决于项目类型和规模、团队经验和技术堆栈等因素。

如果你认为在应用程序代码中存储敏感信息不是一个严重的问题，那么请考虑一下：仅在 2022 年，GitHub 就检测到超过 170 万个潜在秘密暴露在公共存储库中。想象一下，在私人项目中可能存在多少这样的数据，而开发人员直到发生泄漏才意识到潜在的泄漏。

解决方案：立即检查你的项目

如果您已经有一个项目，现在担心代码中的机密，那么有一些方便的解决方案可以让您高枕无忧。手动检查可能很耗时，因此自动化是关键。有用的工具包括：

松露猪：通过扫描 API 密钥和其他敏感数据的提交历史记录来搜索 Git 存储库中的秘密。
GitLeaks ：检测 git 存储库中的密码、API 密钥和令牌等硬编码秘密。
GitGuardian ：在您的本地或 CI 环境中运行，以查找 350 多种类型的秘密和其他安全漏洞。
GitHub 高级安全：自动扫描存储库中已知类型的秘密，如果发现任何秘密，则会发出警报。

这些工具只是几个例子；其他流行的选择包括SonarQube和查克马克。两者都提供付费和免费解决方案，以满足各种需求和预算。这里的目标不是列出所有可用的工具，而是强调这些问题的存在和潜在的解决方案。认识到问题是成功的一半。现在，重要的是分配时间来解决问题并选择适合您需求的工具。

2. 您对图书馆许可证了解多少？

令人惊讶的是，这个话题很少被讨论，一些开发人员甚至没有意识到使用第三方解决方案可能会给他们的公司带来法律问题和重大问题。不相信我？想象一下这种情况：一家小公司的开发人员在GNU Affero 通用公共许可证 (AGPL)在商业网络产品中。作为版权左派许可证，AGPL 要求使用根据该许可证发布的代码的任何软件都必须按照相同的条款分发。这意味着您的所有网络应用程序的代码（包括独特的开发）都必须是开放的，并且可以免费使用和修改。由于我们的示例产品是商业产品，因此公开其源代码可能会严重损害公司的竞争优势和商业模式。

如果项目使用的库的许可证明确禁止商业使用，也会出现严重问题。如果根本没有许可证，情况也不会好转：事实上，没有许可证会带来严重问题，因为任何代码都默认受版权保护。许可证授予用户在特定条件下使用代码的权利，但如果没有许可证，即使代码是公开的，也没有法律依据使用该代码。

值得注意的是，许可问题可能会根据您所在的司法管辖区以不同的方式影响您：这个问题对于签署了国际版权协议的国家尤其重要。例如，伯尔尼保护文学和艺术作品公约是该领域的主要国际条约之一，目前有大约 180 个成员国。因此，未经明确许可使用代码将意味着违反版权法，并可能在世界许多地方引发法律纠纷。然而，这并不意味着你应该搬到一个“舒适”的国家，只是为了违反所有书面和不成文的规定。让我们互相尊重，如果有人不希望他们的开发被用于某些目的，那么最好不要这样做，即使从人性的角度来看也是如此。

解决方案：使用自动检查和更新

如您所见，许可和版权问题很复杂。为了提前保护您自己和您的公司，最好检查您使用的库和软件的许可证。对于库来说，这并不太难；现代包管理器已经有了用于此目的的工具。例如，在 PHP composer 中，您可以使用命令 `作曲家执照`，在 Python pip 中通过 ` pip 许可证`，而在 Golang 中你可以通过 `去执照`。

并且，在更新依赖项时不要忘记调用这些命令（最好自动执行这些检查），因为连接库的许可证可能会在新版本中发生变化。

3. 你们的开发版本访问有限制吗？

在 Web 开发中，一个项目通常有多个版本，例如开发 (dev)、质量保证 (QA)、准备和生产。我经常遇到这样的情况：互联网上的任何人都可以访问网站或 Web 项目的开发/QA 和准备版本。令人担忧的是，测试版本有时比主版本更能被搜索引擎索引，这通常会损害产品。

这里的主要问题是测试版本可能包含错误或敏感信息，甚至可能泄露信息。此外，测试版通常比最终产品更容易受到黑客攻击。这意味着它们的可用性增加了攻击者获得敏感数据、内部代码甚至服务器本身访问权限的风险。如果您正在为移动应用程序之类的东西开发后端，情况尤其如此，因为未经授权访问 API 的测试版本可能非常危险。

除了安全风险之外，重复网页还会对搜索引擎排名产生负面影响。Google 等搜索引擎可能会将这些重复内容视为不良内容，从而可能降低项目原始网页的排名，甚至将其从索引中完全删除。

解决方案：从一开始就制定安全策略

不要吝惜域名。如果您需要可在线访问的测试版本，请为其购买单独的域名。这种简单但有效的措施可以降低安全风险，因为攻击者通常会先检查子域名。将您的测试版本托管在主资源的任何子域名上会使其成为一个容易攻击的目标。

限制对所有测试版本的访问。确保开发、QA、暂存和其他版本不可公开访问。例如，将它们配置为仅通过 VPN 访问。这可以降低未经授权访问的可能性，即使测试域被恶意行为者知道。

保护测试版本不被索引。即使您的测试版本只能通过 VPN 访问并托管在单独的秘密域中，也要使用“robots.txt”文件或“noindex”元标记保护它们不被搜索引擎索引。这一步至关重要，因为搜索引擎有时会以意想不到的方式找到并索引这些页面。

4. 你的真实 IP 地址是否被隐藏？你未使用的端口是否被关闭？

很多开发人员往往会忽略一些安全规则，尽管这些规则至关重要，而且是通过艰苦的教训建立起来的。其中一条规则就是始终隐藏项目的真实 IP 地址。如果可以通过域名确定服务器的 IP 地址，则可能导致以下几个问题：

DDoS 攻击：攻击者知道您项目的真实 IP 地址，可以对您的服务器发起分布式拒绝服务 (DDoS) 攻击。例如， DNS 反射放大攻击可能会因公共 DNS 服务器的大量响应而使您的服务器不堪重负，导致用户无法使用您的服务并造成重大的财务损失。
识别潜在漏洞：除了业余黑客，真正的黑客也可以扫描开放端口和网络暴露的软件来发现和利用漏洞。即使是像 MongoDB 这样的知名服务也曾因配置错误而发生过重大数据泄露。只需隐藏真实 IP 地址，就可以避免许多此类问题。

解决方案：让潜在攻击者的生活更加复杂

通过隐藏服务器的真实 IP 地址，攻击者可以更难攻击您的系统。使用内容分发网络 (CDN) 或 DDoS 保护服务可以非常有效。热门选项包括云Flare该公司免费提供 CDN 功能和 DDoS 保护，以及以下服务：因帕瓦（原名 Incapsula）提供类似的功能，问答网，该公司专门使用 Web 应用程序防火墙保护 Web 应用程序，但这可能会产生成本。

虽然这些工具可以显著增强安全性，但还需要牢记以下几点注意事项：

电子邮件标头 IP 泄露：如果您使用主服务器发送电子邮件，真实 IP 地址可能会暴露在电子邮件标头中，从而使您的安全努力付诸东流。
IP 历史记录和 Whois 请求：类似以下服务DNS 历史记录或者Whois 请求可以显示与域名关联的历史 IP 地址。如果您的真实 IP 曾链接到您的工作域名，则应更改它。
DDoS 保护和 API 端点：对用作 API 端点的域使用 DDoS 保护时要小心谨慎。保护系统可能会引入用户验证步骤，这些步骤可能会通过将 JSON/XML 响应替换为 HTML 代码来破坏客户端应用程序的运行。
传出 API 请求：当您的服务器向第三方 API 发送请求时，可能会无意中泄露其 IP 地址。使用代理服务器处理此类请求会有所帮助，因为更改代理比处理攻击后果更容易。

重要的是要记住，隐藏项目的真实 IP 地址并不是万能的。尽可能关闭软件从外部网络使用的端口至关重要。更改标准端口是一种有争议的做法；一些专家认为，它会使您的设置复杂化而没有显著的好处。通常，将软件配置为通过 Unix 套接字而不是网络 TCP 连接进行交互是更好的选择（如果您的项目和软件都在同一台服务器上运行）。这种方法不仅可以提高交互速度，还可以通过消除对开放端口的需求来增强安全性。

对于位于独立服务器上的数据库管理系统 (DBMS) 或其他内部服务，请确保访问仅限于您严格控制的特定 IP 地址。此设置可防止未经授权访问关键系统，增加额外的安全层，并最大限度地降低外部攻击和数据泄露的风险。