【译文】每个开发人员都需要问自己的一个问题
我最近完成了一个旨在为我们的安全团队实现任务自动化的项目。
目的是简化他们的工作量,加强我们的威胁检测能力。这反过来将帮助我们进一步保护客户的安全。
这个项目涉及在 Slack 中创建一个斜线命令来执行代码。
为了降低成本,我最初的想法是创建一个可以在 AWS Lambda 函数中执行代码的slash命令。
我最初的问题围绕可行性和现有解决方案展开。
能做到吗?如果可以,以前是否有人做过?
大多数情况下,如果可以做到,那么以前就已经做过了。这就引出了我的下一个问题。
有没有关于如何完成的指南?
如果以前有人做过,那么很可能已经有人写了一份简单的分步指南,说明他们是如何做的。
最初,我在谷歌上搜索了 “slack slash command lambda function”。
大约有 137 万个结果。我想我可以马上就有东西运行起来。
但当我开始阅读一些指南时,有一个问题不断出现。
每个开发人员都需要问自己的一个问题。
这样做安全吗?
许多指南中的实现并不安全。
如果将身份验证设置为 “NONE”,您的 lambda 函数就会暴露在互联网上。
有人可能会运行类似下面的脚本。这有可能导致您的 AWS 账户出现拒绝服务和/或账单暴涨!
while true; do curl -v 'https://your.lambda-url.us-east-1.on.aws'; done
现在,公平地说,演示功能可能是许多此类指南的目的。尽管如此,开发人员在实现某些功能时还是应该优先考虑安全性。
以下是一些提高项目安全性的技巧
阅读官方文档
通过阅读官方文档,你可能更有机会实施更安全的项目。
例如,在我的案例中,Slack 的文档讨论了套接字模式(Socket Mode)–一种使用事件 API 的方法……无需公开 HTTP 请求 URL。
仅将在线指南作为起点
如果你觉得直接进入官方文档会让你感到困惑,有时你可以使用分步指南作为起点,帮助你缩小关注范围。
例如,假设你在分步指南中看到了这段代码(如下)。
from someApi import someClass
some_class: someClass = someClass("some_input_arg")
您要使用的是 someAPI 中的 someClass。
指南向你展示了 API 的工作方式,而文档并不总能做到这一点。
现在,您可以在官方文档中搜索这些术语,从而缩小关注范围,并希望能帮助您减少不知所措的感觉。
在搜索中添加 “安全 “一词的变体
如果指南没有提到安全问题,或者只是简单提及,请查找其他提到安全问题的指南。
例如,这份 Slackbot 指南在第一句就提到了安全问题。
有时,找到正确的问题是成功的一半!
与其他开发人员合作
征求其他开发人员的反馈意见,特别是关于如何安全地实现某些功能的反馈意见。
这有可能帮助你解决任何可能存在的盲点,而且还能在你的组织中营造一种将安全放在首位的文化氛围。
同样,查看其他论坛,看看能否就某项功能达成共识。例如,在研究 AWS Lambda 函数 URL 的安全性时,我在 Reddit 上发现了这条评论,它帮助我找到了其他解决方案。
按最新日期对指南进行排序
分步指南很快就会过时。去年出版的指南可能不如今年出版的安全。
与旧版指南相比,近期出版的指南更有可能是安全的。
考虑一下别人会如何滥用您构建的内容
您创建的内容可以以一种方式使用,但是否也可以以另一种方式利用?
例如,这段代码(如下)只是从一个目录中读取文件并返回其内容。但请注意,它没有对哪些目录可以访问、哪些不能访问进行输入验证。
import os
def read_files_from_directory(dir_path):
"""
Read files from a directory path and return their contents.
"""
file_contents = []
for filename in os.listdir(dir_path):
if os.path.isfile(os.path.join(dir_path, filename)):
with open(os.path.join(dir_path, filename), 'r') as file:
file_contents.append((filename, file.read()))
return file_contents
假设有人可以在你的主目录或系统目录下运行此功能。它会返回哪些敏感信息?
在线指南和教程很多,也很有帮助,但开发人员必须在开发生命周期的每个阶段优先考虑安全性。通过将安全性纳入开发流程,您可以强化解决方案,抵御威胁,增强其弹性和可靠性。
本文文字及图片出自 The one question every developer needs to ask themselves
你也许感兴趣的:
- 【外评】80% 的开发人员不开心
- 【外评】如何判断自己已成为高级程序员
- 【外评】如何成为最优秀的程序员
- 【外评】程序员大神每天什么都是时候工作?
- 【译文】在 Meta 工作 12 年:回顾我参与的所有项目
- 【译文】程序员工作很累,但 70% 的程序员在周末休息时以写代码为乐
- 【译文】我是一个糟糕的程序员
- 在技术圈逢凶化吉,靠的居然不是技术?Altman 晒出17条年终总结,人际关系占首位
- 【译文】加密货币交易平台FTX审判,第四天:欺诈在代码中
- 【译文】给程序员的一些额外建议
你对本文的反应是: