最新

我开发了一个小型命令行工具，可以回答“是什么在使用我的端口？”这个问题，而无需使用 lsof/ss/netstat 的繁琐命令。

大多数允许用户部署代码的平台处理机密的方式都是一样的：把它们放在环境变量中，然后祝大家好运。我正在构建一个用于发布和重混可运行网页应用的小型社交平台（Vibecodr），当人们能够部署服务器端代码时，第一个请求是可以预见的：“让我用我的秘密调用一个外部API。” 环境变量的方法一直让我感到困扰。一旦你将明文交给用户代码，它就会存在于内存中，可能被记录、意外地在响应中回显，或者通过某个你没有审计的依赖悄悄泄露。当出现问题时，祝你好运找出秘密泄露的地方。 因此，我尝试设计一个更严格的约束：明文秘密绝不应存在于用户的工作内存中。无论是作为环境变量、帮助函数的返回值，还是在日志中。理想情况下，甚至连毫秒都不应存在。 以下是它的工作原理。 **调度层** 一个由平台控制的代理位于用户代码和外部世界之间。用户代码不会直接获取秘密。相反，它调用一个像fetch-with-secret的包装器，并传递： - 使用哪个秘密（密钥名称，而不是值） - 出站请求的详细信息 - 在哪里注入秘密（头部、查询参数、正文） 调度层负责敏感的工作：在服务器端解密秘密，验证出站URL（仅限HTTPS、可选的每个秘密的白名单、基础设施主机阻止、基于DNS的SSRF检查），以严格的超时发起上游请求，手动处理重定向并在每个跳转时重新验证，从文本响应中删除秘密，并强制执行配额。 **不透明令牌模式** 显式的fetch-with-secret API是安全的，但有时会显得笨拙——开发者喜欢正常地组合请求。因此还有第二种模式：用户代码请求一个短期的不透明令牌，用于给定的秘密密钥（仍然从未看到实际值）。如果该令牌出现在fetch的URL、头部或正文中，包装器会拦截它并通过调度进行真实的注入。令牌是每个请求的、短期的，只有在同一请求上下文中铸造的情况下才会解析。其他情况则会失败并关闭。 **密钥管理** 我对加密秘密负载格式进行版本控制，以便未来的迁移和密钥轮换不会产生歧义。支持多个候选解密密钥同时存在——可以在不破坏现有加密值的情况下进行轮换，并保持跨组件共享的加密逻辑，以避免实现之间的漂移。 **我实际遇到的陷阱** 重定向是一个安全陷阱。大多数HTTP客户端默认会跟随重定向，这可能会悄悄地将“允许的主机”转变为重定向到内部IP。每个跳转都必须手动处理重定向并重新验证，这是不可谈判的。如果我发布了天真的版本，这将会给我带来严重的问题。 删除机密比听起来要复杂得多。秘密可能以原始、URL编码或base64编码的形式出现在响应中。你希望实现深度防御，而不是让每个响应变得一团糟。短秘密会导致误报的删除——我选择了删除并发出警告，而不是跳过它们，因为“哎呀，泄露了”比“哎呀，损坏了”要糟糕得多。 你需要对所有内容设定严格的上限。请求正文大小、扫描的响应正文大小、超时上限。没有它们，每个“有用的功能”都可能成为拒绝服务攻击的向量。 **我希望得到的反馈** 我发布这个是因为我希望得到那些构建过类似系统或发现其漏洞的人的批评： - 你在安全处理二进制响应时，注入秘密的请求有什么首选策略？ - 你是否在边缘/无服务器环境中见过与基于DNS的SSRF验证相关的失败模式？ - 对于删除机密与如果可能包含秘密就完全阻止响应，你有什么强烈的看法？ 如果你想在真实产品上下文中看到这个项目，可以访问 https://Vibecodr.space——但我在这里是为了获取关于架构和威胁模型的反馈，而不是进行发布。

该平台提供关于您商业想法可行性的判定，以及其他因素，如竞争对手和市场研究、定价策略、90天计划等。我在这个平台上花了几个月的时间，以确保它不仅仅是另一个AI生成的粗糙产品。它遵循严格的结构化程序，且AI经过大量商业和公司数据、失败创业公司数据库等的训练。您可以免费试用，亲自体验一下:)

更改内容如下：<p>1) 更快的代理：现在在一个进程中创建多个TCP和UDP服务器实例（适用于Linux和Android）<p>2) 更好的数据包解析：DNS流量变得更加详细和稳健<p>3) 增加了更多的自动配置优化，并能够忽略某些端口<p>4) 许可证变更：从MIT迁移到GPLv3