最新

听音乐时，我通常不会播放整张专辑，而是会根据我当下的心情串联歌曲。过去，我曾编写了一个工具来记录我的听歌历史，并根据我平时的听歌模式生成推荐[1]，然后将其与一些围绕 mpd 的脚本一起使用。这让我的听歌方式变得更便捷，效果也还不错，但我希望也能将此同步到手机上使用。 最近我发现了 Subsonic，这是一个用于音乐服务器和播放器的协议。它吸引了我的注意，因为它支持“scrobbling”（听歌记录的常用术语）和生成相似歌曲列表。这几乎正是我一直在做的事情，而且许多音乐播放器都支持此功能来创建“即时播放列表”。通过一些修改[2]，很容易将我现有的、收集的听歌模式集成到 Subsonic 服务器中。 虽然我为手机找到了一个不错的 Subsonic 客户端，但我没有找到适合我听歌风格的终端音乐播放器。于是我编写了 rmp；它非常精简，但能完成我需要的功能：它允许我快速模糊搜索我的整个音乐库，然后将已排队的歌曲的推荐添加到队列中，同时还会记录听过的歌曲。 [1] https://github.com/codesoap/songmem [2] https://github.com/sentriz/gonic/compare/master...codesoap:gonic:similar_songmem

大家好， 我被要求帮助一个全栈开发团队（Spring+Angular）提升安全技能。 我对全栈开发者的能力持怀疑态度，有多少全栈开发者能同时深入理解 `display: flex` 和事务隔离级别？ 因此，虽然全栈开发者不应该成为公司里的网络安全专家，但由于公司没有网络安全专家，他们必须提升技能，以免公司面临风险。即使公司聘请了网络安全专家，他们也必须了解所有与开发相关的基础知识，以便能够遵循网络安全专家的建议。他们不是新手，例如，他们了解 SQL 注入。 这是我的培训清单（我将帮助他们学习所有这些内容），你们觉得怎么样？培训将包含一半理论和一半实践。 **引言** * 密码学与安全：两个不同的领域。 * 术语：哈希、加密、密钥、证书、签名、前向保密、CVC、零信任。 * OWASP Top Ten 2025 和 CWC Top 25 2025。 * 网络层安全，应用层安全； * 漏洞检测工具：SAST、DAST 和 IAST； * 一些算法：SHA、AES、RSA、椭圆曲线加密。用例和性能； * “像黑客一样思考”，案例研究：Spring4Shell (CVE-2022-22965)。 **保护 REST API** * 嵌入式 Web 服务器配置： * TLS 激活（密钥生成、证书、服务器配置、握手步骤） * HTTP 请求限制（请求头大小、参数、请求体大小、分块） * 不公平使用缓解（速率限制、超时、虚拟线程使用）； * 日志管理 * 身份验证： * 密码保护：哈希、加盐、成本、算法（Bcrypt、Scrypt、Argon、Pbkdf2） * Cookie 身份验证 * Token 身份验证（生成、签名、验证、撤销）； * 混合身份验证（Cookie + JWT）及 Token 中继； * 攻击（XSS、CSRF、日志注入、SQL 注入、授权绕过…）及如何缓解； * CORS 策略定义； * API 之间内部调用（东西向流量）的 mTLS 介绍。 **加密数据** * 加密术语：机密性、真实性、完整性、不可否认性； * 公钥基础设施的描述，有或无 KMS，有或无 HSM。 * 鸡生蛋蛋生鸡问题，使用 Diffie Hellman 进行密钥交换； * 使用 CMS（加密消息语法）交换加密数据； * 数据库加密：文件加密或行级加密。 **应用 CI/CD 最佳实践** * SBOM 生成并上传至 DependencyTrack； * 将扫描作为 CI 流水线的一个步骤； * 生产环境中的密钥管理 * Vault (Hashicorp Vault) 和/或 Spring Cloud Config 服务器； * 在应用程序启动时使用 Jasypt 进行解密； * Kubernetes 密钥管理介绍。 **保护 Angular SPA** * 脚本包含的 SRI 哈希和内容安全策略 (CSP)； * 严格的模板检查； * 数据清理； * CSRF 缓解（涉及 API 和 Angular 客户端）； * 守卫（Guards）配置； * JWT 的保护、使用和续订。 * 确保 HTTP Client 的完整性。 我还考虑了一些不会导致系统崩溃但会增加后端负载的微妙攻击。例如：如果 SQL 分页是使用 `offset` 和 `limit`（而不是基于键的分页）完成的，那么一个有效的 HTTP 请求 `GET /items?offset=100000000&limit=10`，如果频繁重复，将给数据库服务器带来意想不到的负载。此外，还会浪费时间去理解这种高负载的原因。这个例子中重要的是：1）使用基于键的分页，2）检测可疑活动（多个具有非常高 `offset` 的 HTTP 请求是可疑的）。 你们觉得我还有什么遗漏的吗？感谢您的反馈！