请收下这 10 个安全相关的开源项目

Posted 2023-04-05 削微寒

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了请收下这 10 个安全相关的开源项目相关的知识，希望对你有一定的参考价值。

开源为我们的开发带来了极大便利，但这些便利也伴随着一些安全隐患。每当项目引入一个库、框架、服务时，随之而来的安全风险也不可忽视。

所以，当开源吞噬世界的时候，代码安全就更得重视了。今天 HelloGitHub 就给大家带来了 10 款关于安全主题的开源项目，涵盖了编码安全、Web 安全、工具三个方面，虽不能做到面面俱到，但希望它可以抛砖引玉，借此唤起大家的安全意识。

如果你早就认识到代码安全的重要性，那这些开源项目中肯定也有适合你的一款，话不多说，下面就开始今天的“安全教育”。

一、编码安全

从编码习惯入手，提高安全意识。

1、secguide

腾讯开源的代码安全指南。该项目包含：C/C++、Python、javascript、Java、Go 等语言的安全编码指南，内容简单易懂能够帮助开发者，在代码源头规避安全风险、减少漏洞。

地址：https://github.com/Tencent/secguide

2、safe-rules

由 360 质量工程部开源的《代码安全规则集合》。一份全面详细的 C/C++ 编程规范指南，适用于桌面、服务端以及嵌入式等软件开发。

地址：https://github.com/Qihoo360/safe-rules

二、Web 安全

通过检查容易出错的地方，从而保证 Web 服务的安全性。

3、security-guide-for-developers

实用的 Web 开发人员安全须知。作为一个 Web 开发者，你应该在实际工作中认真、经常地使用这套列表，能够有效地减少安全隐患。

地址：https://github.com/FallibleInc/security-guide-for-developers

4、Learn-Web-Hacking

一份很全面的 Web 安全学习笔记，内容包括网络协议、信息收集、常见漏洞攻防、内网渗透等。

地址：https://github.com/LyleMi/Learn-Web-Hacking

5、Top10

该项目由 OWASP 社区（开放式 Web 应用程序安全项目）一个致力于提高软件安全性的非盈利基金会维护，OWASP Top 10 是针对 Web 应用程序的 10 大安全风险提示。

地址：https://github.com/OWASP/Top10

6、API-Security-Checklist

开发安全的 API 所需要核对的清单。在设计、测试和发布 API 的时候，需要核对的重要安全措施。

地址：https://github.com/shieldfy/API-Security-Checklist

三、工具

代码千万行，安全第一行。代码量多了，就得借助工具来发现安全隐患啦。

7、nuclei

基于 YAML 语法模板的定制化快速漏洞扫描器，工程师可以轻松地使用它创建一套自定义的检查方式。

支持多种协议：TCP、DNS、HTTP 等
通过工作流和动态请求实现复杂的漏洞扫描
易于集成到 CI/CD，可以轻松的集成到发布流程上

地址：https://github.com/projectdiscovery/nuclei

8、gitleaks

一款静态应用程序安全测试(SAST)工具。它可以检测 Git 项目中是否包含密码、API Key、token 等敏感信息，还能够轻松整合到 Git Hook 和 GitHub Action，实现提交代码时自动检测，通过告警和阻止 push 等方式，有效地防止敏感信息泄漏。

地址：https://github.com/zricethezav/gitleaks

9、trivy

一款全面的容器安全扫描工具。当下最流行的开源容器镜像漏洞扫描工具，拥有速度快、精准度高、依赖检测、机密检查、对 CI 友好等特点。它不仅安装简单而且容易上手，仅需一条命令，即可发现镜像存在的安全漏洞。

地址：https://github.com/aquasecurity/trivy

10、vulhub

一个面向大众的开源漏洞环境集合。无需 Docker 知识，仅需通过一条简单的命令，就能跑起来一个存在某个漏洞的完整应用。使得安全研究人员能够方便地复现与研究漏洞，省去了学习复杂的部署知识、寻找有漏洞的旧版本应用、搭建依赖的服务等麻烦。

地址：https://github.com/vulhub/vulhub

最后

本期的项目虽然没有太多的趣味性，但都是良心之作“苦口婆心”。代码安全无小事，只有不出事和事故两种情况，嘴上喊一万遍“安全第一”(我都懂，空了就改)，不如立马带上个“安全帽”(跑个安全扫描器)来得实在。

好了，以上就是本期的所有内容，如果您觉得这期内容还不错：求赞、求收藏、求转发，您的支持就是对我最大的鼓励！❤️

👆 点击查看更多内容👆

Redis 使用 10 个小技巧，请收下！

Redis 在当前的技术社区里是非常热门的。从来自 Antirez 一个小小的个人项目到成为内存数据存储行业的标准，Redis已经走过了很长的一段路。

随之而来的一系列最佳实践，使得大多数人可以正确地使用 Redis。

下面我们将探索正确使用 Redis 的10个技巧。

1、停止使用 KEYS

Okay，以挑战这个命令开始这篇文章，或许并不是一个好的方式，但其确实可能是最重要的一点。

很多时候当我们关注一个redis实例的统计数据，我们会快速地输入”KEYS *”命令，这样key的信息会很明显地展示出来。平心而论，从程序化的角度出发往往倾向于写出下面这样的伪代码：

for?key?in?'keys *':  
?doAllTheThings()

但是当你有1300万个key时，执行速度将会变慢。因为KEYS命令的时间复杂度是O(n)，其中n是要返回的keys的个数，这样这个命令的复杂度就取决于数据库的大小了。并且在这个操作执行期间，其它任何命令在你的实例中都无法执行。

作为一个替代命令，看一下 SCAN 吧，其允许你以一种更友好的方式来执行… SCAN 通过增量迭代的方式来扫描数据库。这一操作基于游标的迭代器来完成的，因此只要你觉得合适，你可以随时停止或继续。

推荐：一个致命的 Redis 命令，损失 400 万！

2、找出拖慢 Redis 的罪魁祸首

由于 Redis 没有非常详细的日志，要想知道在 Redis 实例内部都做了些什么是非常困难的。幸运的是 Redis 提供了一个下面这样的命令统计工具：

127.0.0.1:6379>?INFO commandstats  
# Commandstats  
cmdstat_get:calls=78,usec=608,usec_per_call=7.79?  
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20?  
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00?  
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

通过这个工具可以查看所有命令统计的快照，比如命令执行了多少次，执行命令所耗费的毫秒数(每个命令的总时间和平均时间)

只需要简单地执行 CONFIG RESETSTAT 命令就可以重置，这样你就可以得到一个全新的统计结果。

3、将 Redis-Benchmark 结果作为参考，而不要一概而论

Redis 之父 Salvatore 就说过：“通过执行GET/SET命令来测试Redis就像在雨天检测法拉利的雨刷清洁镜子的效果”。很多时候人们跑到我这里，他们想知道为什么自己的Redis-Benchmark统计的结果低于最优结果。但我们必须要把各种不同的真实情况考虑进来，例如：

可能受到哪些客户端运行环境的限制？
是同一个版本号吗？
测试环境中的表现与应用将要运行的环境是否一致？

Redis-Benchmark的测试结果提供了一个保证你的 Redis-Server 不会运行在非正常状态下的基准点，但是你永远不要把它作为一个真实的“压力测试”。压力测试需要反应出应用的运行方式，并且需要一个尽可能的和生产相似的环境。

4、Hashes 是你的最佳选择

以一种优雅的方式引入 hashes 吧。hashes 将会带给你一种前所未有的体验。之前我曾看到过许多类似于下面这样的key结构：

foo:first_name  
foo:last_name  
foo:address

上面的例子中，foo 可能是一个用户的用户名，其中的每一项都是一个单独的 key。这就增加了犯错的空间，和一些不必要的 key。使用 hash 代替吧，你会惊奇地发现竟然只需要一个 key ：

127.0.0.1:6379>?HSET foo first_name?"Joe"?  
(integer)?1?  
127.0.0.1:6379>?HSET foo last_name?"Engel"?  
(integer)?1?  
127.0.0.1:6379>?HSET foo address?"1 Fanatical Pl"?  
(integer)?1?  
127.0.0.1:6379>?HGETALL foo  
1)?"first_name"?  
2)?"Joe"?  
3)?"last_name"?  
4)?"Engel"?  
5)?"address"?  
6)?"1 Fanatical Pl"?  
127.0.0.1:6379>?HGET foo first_name  
"Joe"

5、设置 key 值的存活时间

无论什么时候，只要有可能就利用key超时的优势。一个很好的例子就是储存一些诸如临时认证key之类的东西。

当你去查找一个授权key时——以OAUTH为例——通常会得到一个超时时间。这样在设置key的时候，设成同样的超时时间，Redis就会自动为你清除！而不再需要使用KEYS *来遍历所有的key了，怎么样很方便吧？

6、选择合适的回收策略

既然谈到了清除key这个话题，那我们就来聊聊回收策略。当 Redis 的实例空间被填满了之后，将会尝试回收一部分key。根据你的使用方式，我强烈建议使用 volatile-lru 策略——前提是你对key已经设置了超时。

但如果你运行的是一些类似于 cache 的东西，并且没有对 key 设置超时机制，可以考虑使用 allkeys-lru 回收机制。我的建议是先在这里查看一下可行的方案。

7、如果你的数据很重要，请使用 Try/Except

如果必须确保关键性的数据可以被放入到 Redis 的实例中，我强烈建议将其放入 try/except 块中。几乎所有的Redis客户端采用的都是“发送即忘”策略，因此经常需要考虑一个 key 是否真正被放到 Redis 数据库中了。至于将 try/expect 放到 Redis 命令中的复杂性并不是本文要讲的，你只需要知道这样做可以确保重要的数据放到该放的地方就可以了。