보안 코드에 대한 통찰

精明的组织正在接受基础设施即代码的概念，正是像你这样的开发人员可以在编写安全代码方面做出重大贡献，即使在构建应用程序之外也是如此。起初这似乎是一条漫长的旅程，但要在同行中脱颖而出，这段旅程是值得的。

在我们开始最新的 Coders Conquer Security 系列的下一章之前，我想邀请你来玩一场敏感数据存储漏洞的游戏化挑战赛；立即玩游戏并从 Kubernetes、Terraform、Ansible、Docker 或 CloudFormation 中进行选择：

那怎么样？如果你的知识需要一些研究，请继续阅读：

如今，对密码、个人信息和财务记录等关键数据进行哈希处理是任何网络安全防御的基石。在很多方面，它既是最后的防线，也是最好的保护方式之一。这是因为即使攻击者能够突破其他防御措施并获得关键文件，只要对它们进行了适当的哈希处理和存储，也不会对它们产生多大好处。

这也可以作为抵御恶意内部人员的可靠二级保护，因为加密文件可以与网络的其余部分使用不同的密钥或密码。在这种情况下，系统管理员或黑客等泄露了管理员凭据的人也许能够浏览受保护的目录，但如果加密密钥保存在其他地方，他们仍然无法解锁在那里找到的加密文件。

当然，所有加密保护方法都依赖于强大的加密标准，即使是最强大的计算机也无法打破这些标准。

为什么不安全的密码学很危险？

在计算机技术方面，能够创建强大的加密算法以及破解这些算法的能力已经竞争了很长时间。早在1977年，美国联邦政府就制定了数据加密标准（DES），这是一种56位算法，考虑到计算机的相对强大功能，该算法在当时被认为是安全的。

但是计算机不断发展，人们找到了将它们协作联网的方法，以进一步增强其能力。1999年，电子前沿基金会与Distributed.net共同努力，在短短22小时内公开破解了对受DES保护的文档的加密。突然之间，任何受 DES 加密保护的文档都不再安全了。

信不信由你，一些组织仍然使用DES算法或类似的弱加密保护来保护他们的关键文件。尽管分布式网络在 1999 年打破了 56 位加密，但如今，只要有一点时间，几乎任何足够强大的独立计算机都能做到这一点。黑客还创建了由图形处理器单元（GPU）库构建的专用破解机。这些 GPU 非常擅长这项任务，购买和在本地联网的费用相对较低。

如果您现在选择使用不安全或较弱的加密算法保护您的关键文件，那么不久之后，大多数黑客就可以分解这些文件并使其可读。如果你遭受数据泄露的困扰，那么你必须假设如果文件没有得到足够的保护，它们最终会遭到破坏。

例如，以下 Kubernetes 代码片段使用弱密码算法在 NGINX 入口控制器级别保护信息：

API 版本：v1
种类：ConfigMap
元数据：
名称：nginx-load-balancer-conf
命名空间：kube-系统
数据：
ssl 密码：DES-CBC3-SHA
ssl 协议：“TLSv1.2”

在该示例中，使用了 DES 密码套件来保护信息。但是，攻击者可以轻松解密它并访问敏感信息。

建议使用强密码算法。在以下 Kubernetes 示例中，已使用强密码套件在 NGINX 入口控制器级别保护信息：

API 版本：v1
种类：ConfigMap
元数据：
名称：nginx-load-balancer-conf
命名空间：kube-系统
数据：
ssl 密码:|
ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384：
ECDHE-ECDSA-CHACHA20-POLY1305: ECHE-RSA-CHACHA20-POLY1305：
ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256：
ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECHE-ECDSA-AES256:ECHE-ECDSA-AES128-SHA256: ECHE-ECDSA-AES128-SHA256：
ECDHE-RSA-AES128-SHA256
ssl 协议：“TLSv1.2”

在该示例中，使用了一套强大的密码来避免攻击者获得潜在的敏感信息。

使用高度加密保护关键信息

当今可用的高度加密几乎是牢不可破的。2001 年，美国国家标准与技术研究所 (NIST) 创建了一种新的加密技术来取代 DES。它被称为高级加密标准 (AES)，使用三种不同的密钥长度，分别是 128、192 或 256 位。256 位 AES 加密是最安全的，尽管考虑到当今的技术，这三种加密都被认为几乎完全牢不可破。使用超级计算机进行的测试发现，破解大多数受AES保护的文档需要数千年的不懈努力。

为了正确保护关键文件，开发人员应首先识别它们。无需对网络上的所有内容进行加密，因为持续的加密和解密过程可能会减慢操作速度。但是，人事记录、客户数据和财务信息等关键文件需要足够的保护。从本质上讲，这是在安全与拥有可行系统之间取得的平衡。

而且，这些数据应该按照AES标准之一进行加密，甚至可以对不应该落入坏人之手的真正关键信息进行256位加密。

要考虑的另一件事是，添加加密就像向站点添加更多密码一样。这意味着授权用户需要跟踪加密密钥。为防止这成为工作流程瓶颈，可以考虑实施密钥管理平台来跟踪这些密钥并确保其安全。而且，即使你最终没有使用集中式密钥管理，也要确保所有密钥和密码都受到保护，以确保未经授权的用户无法进入你最安全的数据库。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试 iaC 挑战赛的演示 在 Secure Code Warrior 培训平台中，让您的所有网络安全技能不断磨练并保持最新状态。

실패한 모든 인증 시도, 액세스 거부 및 입력 유효성 검사 오류로 인해 실패한 사이버 보안 계획의 결과로 로깅 및 모니터링 결함이 부족합니다. 프로덕션 환경의 다른 지점에서 발생할 수 있지만 잘못된 로그인 시도를 중지하지 못한 것과 가장 관련이 있습니다.

사이버 보안 팀이 공격에 대해 알지 못하기 때문에 공격에 대응하지 않는다는 것을 의미하기 때문에 위험한 취약점입니다. 이를 통해 공격자는 시스템을 더 관통하거나 자격 증명을 업그레이드하는 동안 눈에 띄지 않게 유지될 수 있습니다. 사실 적절한 로깅 및 모니터링이 없으면 공격을 감지하고 중지하는 것이 매우 어렵거나 불가능해집니다.

지금 도전으로 기술을 테스트 할 준비가 되셨습니까? 이것 좀 확인해 주세요:

공격자는 부족한 로깅 및 모니터링을 어떻게 악용합니까?

모든 API는 로깅 수준이 올바르게 설정되지 않은 경우, 너무 낮게 설정된 경우, 오류 메시지에 충분한 세부 정보를 포함하지 않거나 로깅 기능이 전혀 없는 경우 부족한 로깅 및 모니터링에 취약합니다.

흥미로운 예는 해커가 웹 사이트 또는 서비스에 대한 손상된 사용자 이름의 큰 목록을 얻은 경우입니다. 실험을 통해 시스템을 잠그기 전에 세 번의 로그인 시도가 필요하고 사이버 보안 담당자에게 통보되기 전에 세 번의 로그인 시도가 필요하다는 것을 알 수 있습니다.

이 정보로 무장한 그들은 대신 단일 계정을 무력화하는 대신 "123456" 또는 "암호"와 같은 일반적인 암호를 사용하여 손상된 목록의 모든 이름으로 로그인하기 위해 스크립트를 작성할 수 있습니다. 트릭은 잠금 및 경고에 대한 임계값 이하로 유지, 한 번, 또는 두 번 각 사용자 이름을 시도한다는 것입니다. 운이 좋다면 박쥐에서 적어도 몇 개의 암호를 손상시킬 수 있습니다. 그 후, 그들은 단순히 재설정 하 고 "qwerty" 또는 "신"과 같은 다른 암호를 사용 하 여 프로세스를 다시 실행 하는 로그인 카운터에 대 한 하루를 기다립니다. 관리자가 자신이 하는 일을 감지하지 못하면 공격자는 목록을 여러 번 살펴보고 결국 대부분의 계정을 약한 암호로 손상시킬 수 있습니다.

OWASP제공 예에서 비디오 공유 플랫폼이 부족한 로깅 및 모니터링 취약점을 악용하는 자격 증명 스터핑 공격을 사용하여 공격을 받은 예에서 발생했습니다. 회사가 사용자 불만을 제기하기 시작하기 전까지는 공격이 일어나고 있다는 것을 전혀 알지 못했습니다. 결국, 그들은 API 로그에서 증거를 발견하고 모든 사용자에게 강제 암호 변경 알림을 발행하고 규제 당국에 공격을보고해야했습니다.  

부족한 로깅 및 모니터링 취약점 제거

자동화 및 지속적인 모니터링은 이 취약점을 종식시키는 데 도움이 될 수 있습니다. 시작하려면 실패한 모든 인증 시도를 기록해야 합니다. 또한 이 로그는 STIX 및 TAXII와 같이 기계가 읽을 수 있는 형식으로 넣어 사용 임계값에 관계없이 공격을 검색하도록 훈련된 SIEM(보안 정보 및 이벤트 관리) 시스템으로 수집할 수 있어야 합니다.

또한 로그 파일을 보호해야 합니다. 중요한 정보로 취급하고 공격자의 삭제 또는 수정으로부터 보호합니다. 좋은 정책은 로그 파일을 백업하고 암호화하는 것입니다.

마지막으로 의심스러운 활동을 가능한 한 빨리 감지하고 응답할 수 있도록 사용자 지정 대시보드 및 경고를 만듭니다. 시스템에서 공격자의 시간을 제거하면 낮고 느린 공격 기술을 사용하여 탐지되지 않은 상태로 유지하는 기능을 제거합니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

过度数据泄露漏洞与OWASP清单上的其他API问题不同，因为它涉及一种非常特殊的数据。漏洞背后的实际机制与其他漏洞相似，但在这种情况下，过度数据泄露被定义为涉及受法律保护或高度敏感的数据。这可能包括任何个人身份信息，通常被称为 PII。或者它可能涉及支付卡行业信息或PCI。最后，过度的数据泄露可能包括受隐私法约束的任何信息，例如欧洲的《通用数据保护条例》（GDPR）或美国的《健康保险流通与责任法案》（HIPAA）。

正如你可能想象的那样，这令人深感担忧，精明的开发人员必须学会如何尽可能地消除这些错误。如果你已经准备好对抗数据暴露巨龙，那就去参加我们的游戏化挑战赛吧：

你的分数是多少？继续阅读并了解更多：

有哪些过度数据泄露的例子？

发生过度数据泄露的主要原因之一是开发人员和程序员对他们的应用程序将使用的数据类型没有足够的洞察力。因此，开发人员倾向于使用通用流程，将所有对象属性暴露给最终用户。

开发人员有时还会假设前端组件会在向用户显示任何信息之前执行数据过滤。对于大多数通用数据来说，这很少成为问题。但是，例如，将受法律保护或敏感的数据作为会话ID的一部分暴露给用户，从安全和法律的角度来看，可能会导致重大问题。

OWASP报告设想了一个场景，即保安人员有权访问设施中基于物联网的特定摄像机，以此举例说明敏感数据很容易被意外共享。也许这些摄像机正在监视封闭和安全的区域，而其他监视人员的摄像机本应仅限于具有更高权限的警卫或监督人员。

为了向警卫提供访问授权摄像机的权限，开发人员可以使用如下所示的 API 调用。

/api/sites/111/相机

作为回应，该应用程序将以以下格式发送警卫能够看到的摄像机的详细信息：

{“id”: “xxx”，“live_access_token”: “xxxxbbbb”，“building_id”: “yyy”}

从表面上看，这似乎效果很好。警卫在应用程序上使用图形用户界面，只能看到他们有权查看的摄像机画面。问题在于，由于使用的通用代码，实际的API响应将包含整个设施中所有摄像机的完整列表。任何在网络中窃取数据或泄露警卫账户的人都能够发现网络中每台摄像机的位置和命名法。然后，他们可以不受限制地访问这些数据。

消除过多的数据泄露

防止过度数据泄露的最大关键是了解数据及其周围的保护措施。创建通用 API 并让客户端在向用户显示数据之前对数据进行排序是一个危险的选择，它会导致许多可预防的安全漏洞。

除了了解相关的数据保护外，停止使用通用 API 向用户发送所有内容的过程也很重要。例如，必须避免使用诸如 to_json () 和 to_string () 之类的代码。取而代之的是，该代码应专门选择需要归还给授权用户的属性，并专门发送这些信息。

为了确保没有意外过度共享受保护的数据，组织应考虑实施基于架构的响应验证机制作为额外的安全层。它应该定义和强制所有API方法返回的数据，包括错误报告规则。

最后，所有归类为包含 PII 或 PCI 的数据，或受 GDPR 或 HIPAA 等法规保护的信息，都应使用高度加密进行保护。这样，即使这些数据的位置作为过度数据泄露漏洞的一部分泄露了，也有一道良好的次要防线，即使数据落入恶意用户或威胁行为者手中，也应该保护数据。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。

现在是我们的 “基础设施即代码” 系列的下一期的时候了，这些博客将带领像您这样的开发人员在自己的组织中部署安全基础架构时提高到一个全新的安全意识水平。

哦，顺便说一句... 你对前一篇博客中的安全配置错误挑战的表现如何？如果你想立即解决缺失的功能级别访问控制漏洞，请前往该平台：

（上面的链接将带你进入Kubernetes挑战赛，但进入平台后，也可以使用下拉菜单从Ansible、CloudFormation、Terraform或Docker中进行选择。你的选择。）

当今部署的几乎每个应用程序都有某种访问控制机制，该机制可以检查用户是否有权执行所请求的功能。在创建应用程序时，它几乎是良好安全性和功能性的基石。实际上，所有 Web 应用程序都需要访问控制才能允许具有不同权限的用户使用该程序。

但是，当没有在基础架构级别执行相同的访问控制验证功能或配置错误时，可能会出现问题。如果基础设施级别的访问控制不完善，整个企业就会向黑客敞开大门，黑客可以利用该漏洞作为进行未经授权的窥探或全面攻击的门户。

实际上，利用缺失或配置错误的功能访问控制漏洞非常容易。攻击者甚至不需要过于熟练。他们只需要知道哪些命令在支持应用程序的框架内执行功能。如果他们这样做了，那只是反复试验的问题。他们可以持续提交不应允许的请求，一旦成功，目标网站、应用程序、服务器甚至整个网络都可能被暴露。

缺失的功能级别访问控制漏洞如何运作？

职能级别访问控制可以通过多种方式渗透到组织中。例如，功能级别的访问权限可以留给应用程序，而不由底层基础设施进行验证。或者，基础设施级别的访问控制可能配置不正确。在某些情况下，管理员假设未经授权的用户不知道如何获得只有更高级别的用户才能看到的基础架构资源，并使用很少起作用的 “隐蔽安全” 模型。

举一个通过隐蔽性实现安全的示例，以下 URL 可能容易受到攻击：

http://companywebsite.com/app/NormalUserHomepage

如果经过身份验证的用户使用一种名为 “强制 URL 浏览” 的技术，他们可能会尝试访问仅向管理员显示的页面。一个例子可能是：

http://companywebsite.com/app/AdminPages

如果不存在服务器端验证，他们将只显示管理页面（如果其名称与请求相符），然后就可以访问管理员在新页面上执行的任何其他功能。如果服务器向攻击者返回 “页面未找到” 错误，他们可以继续尝试，直到找出管理页面的名称。

对于攻击者来说，利用 缺少功能级别访问控制 是一个类似的过程。他们不是尝试浏览未经授权的页面，而是发送函数请求。例如，他们可能会尝试创建一个具有管理员权限的新用户。因此，根据框架的不同，他们的请求看起来像这样：

帖子/操作/创建用户名=hacker&pw=密码&角色=管理员

如果不存在功能级别的访问控制，则上面的示例将成功创建新的管理员帐户。一旦攻击者以新管理员身份重新登录，他们将拥有与该网络或服务器上的任何其他管理员相同的访问权限和权限。

修复缺少功能级别访问控制的问题

由于攻击者很容易利用缺失的功能级别访问控制漏洞，因此发现、修复和预防这些漏洞至关重要。值得庆幸的是，有了一些专业知识和基本的基础设施，这并不难 代码安全培训。

主要的保护措施将来自于在基础架构级别实现基于角色的授权。永远不要相信应用程序可以处理该功能。即使他们这样做了，获得基础设施方面的授权也能确保不会遗漏任何东西。理想情况下，授权应来自一个集中位置（例如 AWS IAM、Azure IAM 等），该位置内置于组织的例程中并应用于每个新应用程序。这些授权过程可以来自框架本身，也可以来自任意数量的易于使用的外部模块。

最后，您的组织应采用最低权限的概念。默认情况下，所有操作和功能都应被拒绝，授权过程用于授予有效用户执行所需操作的权限。他们只应获得足够的权限来执行所需的功能，并且只能在需要的时间内有效。

缺少功能级别访问控制可能会造成灾难性的后果。但值得庆幸的是，通过在组织中建立良好的基础架构级授权实践，您可以轻松防止此问题发生。

认为你已经准备好在野外发现访问控制错误了吗？比较这些 Docker 代码片段；一个易受攻击，一个安全：

취약점:

来自 quay.io/prometheus/busybox: latest
ARG 版本=0.12.1
ARG 文件名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL = https://github.com/prometheus/mysqld_exporter/releases/download/v
运行 wget $url$version/$filename.tar.gz &&\
tar-xvf $fileName.tar.gz &&\
mv $文件名/mysqld_exporter /bin/mysqld_exporter
复制 .my.cnf /home/.my.cnf
复制。/scripts/entrypoint.sh ~/entrypoint.sh
用户 root
暴露 9104
入口点 [“sh”，“~/entrypoint.sh”]
CMD [“/bin/mysqld_exporter”]

안전：

来自 quay.io/prometheus/busybox: latest
ARG 版本=0.12.1
ARG 文件名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL = https://github.com/prometheus/mysqld_exporter/releases/download/v
运行 wget $url$version/$filename.tar.gz &&\
tar-xvf $fileName.tar.gz &&\
mv $文件名/mysqld_exporter /bin/mysqld_exporter
复制 .my.cnf /home/.my.cnf
复制。/scripts/entrypoint.sh ~/entrypoint.sh
用户没人
暴露 9104
入口点 [“sh”，“~/entrypoint.sh”]
CMD [“/bin/mysqld_exporter”]

了解更多，挑战自我

보안 코드 워리어 블로그 페이지를 방문하여 이 취약점에 대한 자세한 내용을 확인하고, 조직과 고객을 다른 보안 취약점 및 결함으로부터 보호하는 방법을 알아보세요.

如果你之前错过了，你可以 试试 iaC 游戏化安全挑战 在 Secure Code Warrior 平台上，让您的所有网络安全技能不断磨练并保持最新状态。

敬请关注下一章！

由于缺乏资源和速率限制，API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限，具体取决于其环境。大多数人还必须回答用户或其他程序的请求，要求其执行所需的功能。当同时传入的请求过多，且 API 没有足够的计算资源来处理这些请求时，就会出现此漏洞。然后，该 API 可能变得不可用或无法响应新请求。

如果 API 的速率或资源限制设置不正确，或者代码中未定义限制，则容易受到此问题的影响。例如，如果企业遇到特别繁忙的时期，则API可能会过载。但这也是一个安全漏洞，因为威胁行为者可以故意使用请求使未受保护的 API 过载，以执行拒绝服务 (DDoS) 攻击。

顺便问一下，到目前为止，你在 API 游戏化挑战中表现如何？如果你想立即尝试处理速率限制漏洞的技能，那就进入竞技场：

现在，让我们更深入地了解一下。

缺乏资源和速率限制 API 漏洞的一些例子有哪些？

此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置，但依赖它并不是一个好政策。相反，每个 API 都应单独设置其费率。尤其如此，因为 API 可能具有截然不同的功能和可用资源。

例如，设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是，作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下，节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。

为了最大限度地提高性能，将速率设置为无限可能会很诱人，尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成（例如，我们将使用 Python Django REST框架):

“默认节流速率：{
“不知道：没有，
“用户：无

在该示例中，匿名用户和系统已知用户都可以无限次地联系 API，而不考虑一段时间内的请求数量。这是个坏主意，因为无论API有多少可用的计算资源，攻击者都可以部署僵尸网络之类的东西，从而最终减慢其爬行速度，或者可能将其完全下线。发生这种情况时，有效用户将被拒绝访问，攻击将成功。

消除资源短缺和速率限制问题

组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。

从上面的示例中可以看出，与其完全开放限制速率，不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。

“默认节流速率：{
“匿名：配置（“THROTTLE_ANON，默认值 = 200/小时），
“用户：配置（“THROTTLE_USER，默认值 = 5000/小时）

在新示例中，API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地，每小时 5,000 个请求。但是，即使它们也仅限于防止高峰时段意外过载，或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。

作为最后要考虑的良好做法，最好在用户达到限制时向他们显示通知，并解释何时重置这些限制。这样，有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API，这也会很有用，因为它可以向操作人员发出信号，表明需要加强限制。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。

인증이 깨진 경우 API 문제에 대한 OWASP 목록이 올바르게 구현하기 어려운 것으로 악명이 높습니다. 또한 공격자는 본질적으로 대부분의 인증 문제를 사용자에게 노출해야 하므로 공격자가 이를 연구하고 악용할 수 있는 패턴이나 취약점을 찾을 수 있는 기회를 제공해야 하기 때문에 약간의 이점이 있습니다.

마지막으로 인증은 응용 프로그램 과 네트워크의 나머지 부분에 대한 게이트웨이 역할을 하는 경우가 많기 때문에 공격자에 대한 대상을 유혹하고 있습니다. 인증 프로세스가 깨지거나 취약하면 공격자가 약점을 발견하고 악용할 가능성이 높습니다.

그래서, 이 장에서, 우리는 인증 문제에 관해서 나쁜 사람을 종료하는 방법을 배울 거 야. 먼저 기술을 테스트하려면 머리를 숙이고 게임화 된 도전을 플레이하십시오.

점수를 향상시키고 싶으신가요? 우리가 그것을 무너뜨리는 동안 나와 함께 있어.

손상되거나 잘못 구성된 인증의 예로는 어떤 예가 있습니까?

인증 방법이 자격 증명 스터핑에 취약하거나 알려진 사용자 이름과 암호 목록을 사용하여 보안을 끊을 수 있는 경우문제가 명확하지 않을 수 있습니다. 요청이 제한되거나 제한되거나 모니터링되지 않는 경우 다단계 인증과 같은 일반적으로 매우 안전한 권한 부여 방법조차도 취약할 수 있습니다.

예를 들어 공격자는 POST 요청을/api/system/확인 코드로 보내고 요청 본문에 사용자 이름을 제공하여 암호 복구 요청을 트리거할 수 있습니다. 앱이 6자리 코드가 사용자의 휴대폰으로 전송되지만 입력 필드가 제한되지 않는 SMS 문자 메시지 챌린지를 사용하는 경우 응용 프로그램이 단 몇 분 만에 끊어질 수 있습니다. 공격자는 올바른 조합을 칠 때까지 가능한 모든 6자리 조합을 응용 프로그램에 보내야 합니다.

이 시나리오에서는 표면에서 이중 인증을 사용하면 응용 프로그램을 안전하게 유지하는 것처럼 보입니다. 그러나 사용자 입력속도가 제한되지 않으므로 인증이 끊어지고 취약합니다.

또 다른 예에서 응용 프로그램은 인코딩된 사용자 개체를 인증 쿠키로 사용할 수 있습니다. 그러나 수준이 낮은 사용자 액세스가 있는 공격자가 Base64를 사용하여 쿠키를 디코딩하는 경우 쿠키가 세션과 사용자를 응용 프로그램에 정의하는 방법을 발견할 수 있습니다. 예를 들어, 그들은 다음 JSON을 볼 수 있습니다 한 번 디코딩:

{
"username" : "ShadyGuy",
"role" : "user"
{

이 시점에서 악의적인 사용자가 사용자 이름, 역할 또는 둘 다 변경할 수 있습니다. 몇 가지 값을 변경하여 권한 수준이 높은 다른 사용자가 될 수 있습니다.

{
"username" : "GoodGuy",
"role" : "admin"
{

이 시점에서 공격자가 정보를 다시 코딩하고 쿠키 값으로 설정하면 기본적으로 더 높은 권한 수준을 가진 새 사용자가 됩니다. 이러한 변경을 방지하기 위한 방법이 마련되지 않는 한 응용 프로그램이 변환을 수락할 가능성이 높습니다.

잘못되었거나 잘못 구성된 인증 제거

인증에 실패하면 전반적으로 보안이 손상될 가능성이 큽분입니다. 그러나 코딩 응용 프로그램이 모든 것을 안전하게 유지하는 데 도움이 될 수 있지만 몇 가지 중요한 지침을 따르면 모든 것을 안전하게 유지하는 데 도움이 될 수 있습니다.

먼저 사용자가 프로그램 기능에 액세스할 수 있도록 모든 곳에서 인증 검사를 포함해야 합니다. 인증 검사가 전혀 존재하지 않으면 처음부터 전투가 손실됩니다.

모범 사례의 관점에서 볼 때 사용자가 액세스할 수 있는 URL에 세션 ID가 노출되지 않도록 하는 것이 좋습니다. 깨진 인증과 관련하여 위의 두 번째 예에서는 공격자가 세션 쿠키에 노출되지 않으면 세션 쿠키를 디코딩하지 않도록 하는 것이 훨씬 쉽습니다.

다단계 인증을 구현하는 것도 좋습니다. 이 작업은 촉박한 일정에 따라 알고리즘적으로 암호를 생성하는 하드웨어 토큰을 사용하여 안전하게 수행할 수 있습니다. 사용자에게 이러한 장치를 제공할 수 없는 경우 SMS 문자 메시지도 작동할 수 있습니다. 그러나 사용자 요청이 30초 동안 3~4회 시도와 같은 합리적인 것으로 제한되고 코드가 단 몇 분 만에 모두 함께 만료되는지 확인해야 합니다. 거상 코드를 사용하면 잠재적인 암호에 문자와 번호를 추가하여 보안을 향상시킬 수도 있습니다.

마지막으로 가능하면 사용자 이름 또는 세션 ID로 예측 가능한 순차적 값에 따라 달라지 마십시오. 대신 매번 임의의 세션 ID를 생성하는 보안 서버 측 세션 관리자를 사용합니다.

보안 인증 방법을 구현하는 것은 평균 취약점에 대처하는 것보다 조금 더 까다롭습니다. 그러나 권한 부여는 모든 응용 프로그램, 프로그램 및 API에 매우 중요하기 때문에 올바른 것을 얻기 위해 여분의 시간을 할애할 가치가 있습니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

如今，网络安全威胁无处不在，持续不断。情况变得如此糟糕，以至于在部署程序后试图跟上他们的步伐几乎是不可能的。但是，在这个DevSecOps、持续交付和比以往任何时候都更多的数据收益的时代，精明的组织正在帮助他们的开发人员提升技能成为具有安全意识的超级巨星，帮助他们在常见漏洞投入生产之前就将其消除。我们已经解决了 网络漏洞，再加上我们自己的 排名前 8 位的基础设施即代码 错误，现在是时候熟悉下一个重大软件安全挑战了。你准备好了吗？

下一系列博客将重点介绍与应用程序编程接口 (API) 有关的一些最严重的安全漏洞。这些都太糟糕了，以至于他们创建了开放 Web 应用程序安全项目 (OWASP) 主要的 API 漏洞列表。鉴于 API 对现代计算基础架构的重要性，您需要不惜一切代价将这些关键问题排除在应用程序和程序之外。

在对损坏的对象级授权漏洞的检查中，可以找到一个很好的例子，说明为什么必须使用代码来加强安全性。当程序员未能明确定义哪些用户能够查看对象和数据，或提供任何形式的验证来查看、更改或提出其他操作或访问对象的请求，从而允许他们通过 API 端点修改和访问对象和数据时，就会发生这种情况。API 端点是一个接触点，通常是 URL，用于 API 本身与其他系统之间的通信。应用程序之间的连接能力提升了世界上一些最受欢迎的软件的地位，但如果多个端点不密封，则有暴露多个端点的风险。

当程序员忘记或继承父类的属性时，也可能发生这种情况，却没有意识到这样做还会遗漏代码中的关键验证过程。通常，对于使用用户输入访问数据源的每个函数，都应包括对象级授权检查。

认为你已经熟悉这些漏洞了，现在能找到、修复和消除访问控制错误吗？玩游戏化挑战赛：

你过得怎么样？如果你想努力提高自己的分数，请继续阅读！

损坏的对象级授权漏洞的例子有哪些？

对象级访问控制漏洞允许攻击者采取不应允许的操作。这可能是应留给管理员的操作，例如访问或查看敏感数据或销毁记录。在高度安全的环境中，这甚至可能意味着阻止任何人查看记录，除非他们获得特别授权。
定义对象级授权时，应牢记所有可能的操作。例如，在 Java Spring API 中，存在潜在问题的端点可能如下所示：

公共布尔值 deleteOrder（长 ID）{
订单订单 = orderRepository.getOne (id);
if（订单 == 空）{
log.info（“未找到订单”）；
返回 false；
}
用户用户 = order.getUser ();
orderRepository.delete（订购）；
log.info（“删除用户 {} 的订单”，user.getId ()）；
返回真值；

API 端点按 ID 删除订单，但不验证此订单是否由当前登录的用户下达。这为攻击者提供了利用此漏洞并删除其他用户的订单的机会。

为了正确实施安全访问限制，代码将更像这样：

公共布尔值 deleteOrder（长 ID）{
用户用户 = userService.getUserbyContext ();
布尔值 orderExist = getUserOrders () .stream ()
.anyMatch（订单->（order.getId () == id））；
if (orderExist) {
orderRepository.deleteById (id);
log.info（“删除用户 {} 的订单”，user.getId ()）；
返回真值；
} 其他 {
log.info（“未找到订单”）；
返回 false；

消除损坏的对象级授权漏洞

访问控制代码不必过于复杂。就我们的 Java Spring API 环境示例而言，可以通过严格定义谁可以访问对象来修复这个问题。

首先，必须实施验证程序，以确定谁在提出请求：

用户用户 = userService.getUserbyContext ();

接下来，我们必须确保对象 ID 存在且属于发出请求的用户：

布尔值 orderExist = getUserOrders () .stream ()
.anyMatch（订单->（order.getId () == id））；

最后，我们继续删除该对象：

orderRepository.deleteById (id);

请记住，您需要确保代码中的授权方法与组织的用户政策和数据访问控制保持一致。为了确保您的代码完全安全，您应该进行检查，以验证具有不同权限级别的用户是否有权访问他们执行任务所需的数据，但不能查看或更改任何本应限于他们的内容。这样做可能会发现意外忽视的丢失的对象控制漏洞。

这些示例的主要启示是，首先定义用户可以对对象执行的所有操作，然后直接向代码添加强大的访问控制。最后，永远不要相信继承的父财产可以完成这项工作或在其他地方委托这种权力。取而代之的是，在代码中为需要保护的每种对象类型明确定义用户权限和操作。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。

坦率地说，在最近的一次长途飞行中，我借此机会吞噬了大量疯狂的播客节目。时刻关注这么多不同的系列节目，这意味着我从不缺少什么好听的东西，只要触摸手机屏幕，就能看到引人入胜的（尽管是片面的）对话。

最后我看了一集《真实犯罪》播客， 案例档案。这部戏剧性的、无拘无束的剧集（包括一位声音不祥且不愿透露姓名的主持人）深入探讨了一个即使是最知识渊博、最精明的技术专家也着迷的话题：深层网络，以及违禁品贸易网站丝绸之路的灾难性崛起。分为两部分，熟悉丝绸之路兴衰的人无疑会关注有关此案的消息，但该播客以美味的边缘叙事泄露了每一个小细节。

丝绸之路：深网地牢的教训

如果你对丝绸之路的来龙去脉不甚了解，那么TL; DR的总结是，一个人在深层网络上建立了一个贸易网站，隐藏在公众的窥视之下，如果不使用特殊软件——确切地说是Tor浏览器——就无法查看。该网站最初只提供他本土种植的魔法蘑菇，但几乎在一夜之间，供应商爆炸式增长，从硬核毒品到非法武器以及被盗的信用卡详细信息，应有尽有。 你可以在这里加快速度。创作者和网站管理员使用了受新娘公主启发的笔名 Dread Pirate Roberts。他是所有人，他不是任何人。所有用户都交易了名副其实的非法物品赏金，而且他们完全匿名地进行了交易（在此过程中，比特币被誉为毒贩首选货币；这个绰号才刚刚开始动摇）。

但是，恐惧海盗罗伯茨的反建制实验本身就是一只野兽。很快，杀手们开始宣传他们的服务。坏人正在做坏事... 他被新发现的深不可测的财富所陶醉。他甚至试图利用广告中的杀手的服务来处置一名前雇员。长话短说，这是导致他失败的众多愚蠢决定之一。他被揭露为罗斯·乌尔布里希特的面具，目前他正在美国牢房里腐烂，服两次无期徒刑外加四十年，不得假释。

但是，如果一切都是完全私密和匿名的，他是怎么被抓到的？

好吧，坦率地说： 他是个很烂的程序员。丝绸之路遗址本身就像一艘被困在海里的漏水的旧驳船。考虑到它是非法活动的中心（以及该活动背后的所有数据），它根本不安全；它是一个等待机会主义黑客利用的坐视目标。公平地说，当你是一个庞大的非法贩毒企业的策划者时，要找到愿意参与你业务的有能力的员工可能并不容易。他也毫不掩饰自己的技能差距- 他甚至用自己的真实姓名发帖 上 堆栈溢出 （是的，这是他的用户帐户），他请求帮助他正确配置站点代码，以便在 PHP 中使用 Curl 与 Tor 连接。在发帖不到一分钟后，他将自己的真实姓名改为 “frosty” 的账号，但这显然无济于事... 事实上，这可能造成了进一步的损害：丝绸之路服务器上的加密密钥以子字符串 “frosty @frosty” 结尾，因此，一旦联邦调查局得知他的气味，他就会进一步受到牵连。

尽管大力推动隐私，通过加密消息、货币和明确的指示，确保违禁品本身在运输和交付过程中的安全，但该网站并不是乌尔布里希特可能设想的自由主义幻想中坚不可摧的堡垒。那些拥有这些技能的人（阅读：联邦调查局雇用的程序员）缓慢但肯定地将其解开，以揭露所有内容... 包括成千上万在该网站上进行交易的人的身份。那些多年前购买了顽皮商品的人有可能在某个时候还会被执法部门敲门。

联邦调查局发布了 文档 概述了他们是如何穿透丝绸之路的，一般的解释是利用IP地址泄露。丝绸之路登录页面的错误配置泄露了其服务器的IP地址，从而暴露了其服务器的物理位置，无需进行任何恶意的黑客攻击。当然，这是一个菜鸟错误，最终导致联邦调查局直接找到了罗斯·乌尔布里希特。

有人猜测，监视该网站的众多安全专业人员中的一位早在这一刻之前就发现了这个漏洞，如果确实存在的话。澳大利亚安全顾问尼克·库布里洛维奇声称根本不存在 在接受《连线》采访时:

“你不可能连接到 Tor 站点并看到不是 Tor 节点的服务器的地址。从技术上讲，他们试图让陪审团或法官相信事情发生的方式是没有意义的。”

然后，库布里洛维奇接着暗示这些信息可能是通过非法黑客行为获得的。这种做法似乎是 SQL 注入，这是一个未经证实的谣言，已被讨论为 从那以后，在许多地方都采用了合理的提取方法。

联邦调查局策略的合法性完全是单独的讨论。尽管一般用户都认为丝绸之路是 “私密的” 网站，但完全可以获得这些信息的事实表明，丝绸之路的安全措施不佳。当隐私与安全性混淆时，漏洞暴露的可能性肯定会增加。

如果罗斯·乌尔布里希特在隐私和安全之间做出区分，在它发展成巨型加热灯之前积极努力确保两者，吸引地球上所有技术知识略高于平均水平的不愉快骗子，那么该网站也有可能继续运行（无论如何，它已经复活了好几次，甚至还有像现在一样运营的更大的网站）。取而代之的是，当有人找到开门的方法时，私人俱乐部及其所有秘密就被揭露了。

你不是毒枭，那你为什么要关心呢？

丝绸之路的逝世及其创始人被监禁并不是一个悲惨而富有同情心的故事，但它是一个引人入胜的案例研究，探讨了隐私与真实、强大的网站安全之间的细微差别。有许多合法的业务要求交易和信息保密——比如数字化的医疗记录，甚至是大型银行持有的数百万张信用卡号——但如果没有铁杆软件开发的保护，这些信息可能会被攻击者精心挑选（具有讽刺意味的是，最终会出现在丝绸之路这样的网站上）。没有安全性，隐私就不存在。

像你这样的好人可能拥有容易受到 SQL 注入攻击和其他漏洞的软件 OWASP 前 10 名，因此，为这些问题做好准备并有效缓解至关重要。如果开发人员从一开始就接受过安全编码的培训，那么这些缺陷就不会浮出水面。组织必须以安全思维为重点，赋予其开发团队安全编码的能力。我们可以向您展示如何以有趣、可衡量和游戏化的方式来做到这一点。你准备好了吗？

好吧，就是这样（目前）。我们的 “基础设施即代码” 系列已经走到了尽头。我们希望你在克服 Docker、Ansible、Kubernetes、Terraform 和 CloudFormation 中的安全问题时玩得开心。但是，在我们注销之前，我们还有一个漏洞需要你掌握：业务逻辑错误。

认为你现在准备好测试自己的技能了吗？试试最后的游戏化挑战：

如果你仍然不清楚一些事情，请继续阅读：

我们今天要重点关注的漏洞是 商业逻辑 缺陷。当程序员无法正确实现业务逻辑规则时，就会发生这种情况，如果恶意用户选择利用这些规则，他们的应用程序可能容易受到不同类型的攻击。根据每个应用程序中实现的目的和功能，业务逻辑缺陷可能允许权限升级、不当使用资源或执行任意数量的意外业务流程。

与许多漏洞不同，业务逻辑规则的错误实现可能出人意料地微妙。他们需要特别警惕，以确保他们不会潜入应用程序和代码。

有哪些业务逻辑缺陷的例子？

举例说明诱发业务逻辑缺陷有多么容易，可以考虑以下使用 Docker Compose 文件定义的 Docker 环境中的示例。为了准备容器以执行功能，开发人员可以使用在 Docker Compose 文件中定义的标准资源策略，例如以下示例：

部署：
资源：
极限：
中央处理器：“0.5”
预订：
中央处理器：“0.5”

虽然表面上看起来不错，但这种容器资源策略并未正确限制资源的使用。攻击者可以利用业务逻辑缺陷实施拒绝服务 (DoS) 攻击。

为了限制用户占用太多资源，开发人员可能会尝试更好地定义每个容器可以支持的内容。因此，新代码可能包含放置限制：

部署：
资源：
极限：
中央处理器：“0.5”
预订：
中央处理器：“0.5”
放置：
限制：
-“node.labels.limit_cpu == 100M”
-“node.labels.limit_memory == 0.5"

乍一看，这似乎可以解决 商业逻辑 缺陷。但是，新的放置限制不会影响 Docker 容器服务的资源使用限制。它仅用于选择一个节点来调度容器。在这种情况下，DoS 攻击仍然是可能的。攻击者需要先入侵 Docker 容器，但之后可以无限制地消耗资源。

如您所见，考虑业务逻辑缺陷并编程消除这些缺陷可能是一项棘手的任务。

消除业务逻辑缺陷

由于业务逻辑缺陷，关键是要知道它们的存在。在编写新代码时，你需要保持警惕，不要让它们进入你的环境。在应用程序开发过程的所有阶段，包括设计、实施和测试，都应明确定义和检查业务规则和最佳实践。

例如，为了防止业务逻辑缺陷引发上例中的 DoS 攻击，最佳做法是限制您创建的每个 Docker 容器可以使用的资源量。具体而言，限制部分必须指定 CPU 的数量和 Docker 容器可以使用的内存量。一个例子是：

部署：
资源：
极限：
中央处理器：“0.5”
内存：100M
预订：
中央处理器：“0.5”
内存：50M

使用上面示例的代码作为策略可以消除环境中的主要业务逻辑缺陷并防止 DoS 攻击。即使攻击者入侵了其中一个 Docker 容器，这也能起作用。在这种情况下，攻击者仍然无法利用其立足点消耗资源。

威胁建模可以通过定义不同攻击的发生方式并确保使用业务逻辑规则来预防和限制攻击来提供帮助。基于合规规则和已知滥用案例的测试也可能有助于发现漏洞的业务逻辑缺陷。

业务逻辑缺陷是一些最微妙的漏洞，可以潜入应用程序，但其危险性不亚于其他更引人注目的风险。了解它们是如何发生的并使用最佳实践可以使它们在应用程序开发期间远离您的环境，从而确保它们永远不会进入生产环境，在那里它们会被非常熟悉如何利用它们的攻击者滥用。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 在 Secure Code Warrior 培训平台上进行这项 IaC 挑战赛，让您的所有网络安全技能不断磨练并保持最新状态。