牢记昨天的教训_请牢记5条安全的编码准则

牢记昨天的教训

Often as developers when we think about secure coding we’re thinking of security with a very limited mindset. We’re taught to be sure to sanitize input avoid storing passwords in the clear, etc. We may even be aware of XSS and SQL injection and what these attacks look like, but when it comes to coding and building secure apps, we may be prone to trust intuition or take our chances.

作为开发人员，当我们考虑安全编码时，我们通常会以非常有限的思维方式来考虑安全性。 我们被教导要确保清理输入内容，避免以明文形式存储密码，等等。我们甚至可能知道XSS和SQL注入以及这些攻击的模样，但是当涉及到编码和构建安全应用程序时，我们可能会容易相信直觉或抓住机会。

It doesn’t need to be this way. In fact, I believe in many cases considering security when you’re designing systems and coding can actually enhance the quality of your code. In traditional InfoSec training, security practitioners are introduced to the CIA Triad. The CIA Triad defines the overall goals of security in an enterprise: Confidentiality, Integrity, and Availability. I’ll look at each of these and how they relate to writing code.

不需要这样。 实际上，我相信在设计系统和编码时，在很多情况下考虑安全性实际上可以提高代码质量。 在传统的InfoSec培训中，安全从业人员被介绍给CIA Triad 。 中情局三合会定义安全在企业的总体目标：C onfidentiality， 我 ntegrity和A vailability。 我将研究其中的每一个以及它们与编写代码的关系。

Confidentiality

保密

Confidentiality is best embodied by the principal of least privilege. Basically, it means that only those who have need to access the data, and have sufficient privileges should be allowed to access it. Confidentiality is an entire field in itself that includes many different ideas, implementations, and principals. Generally, when we consider confidentiality we are talking about encryption of data in any of its states (process/transport/rest) or about access controls.

保密性最好由最小特权的主体体现。 基本上，这意味着只有那些需要访问数据并具有足够特权的用户才应被允许访问。 机密性本身就是一个完整的领域，包括许多不同的想法，实现和主体。 通常，当我们考虑机密性时，我们所谈论的是处于任何状态(过程/传输/休止)的数据加密或访问控制。

Integrity

廉洁

Integrity is the point of the triad that ensures that information is consistent, trusted, accurate, and not manipulated. Data integrity should ensure that data is only modified by authorized parties and that controls are in place to detect any unauthorized modifications.

完整性是三合会的重点，可确保信息一致，可信，准确且不受人为操纵。 数据完整性应确保只有授权方才能修改数据，并且要有控制措施来检测任何未经授权的修改。

Availability

可用性

In a world where SLAs are measured by the number of 9’s you can put after a decimal point, Developers and Ops personnel are already acutely aware of the importance of high availability. Whether it’s a DDOS attack, or an attacker leveraging expensive API calls to slow down an application — these attacks impact an application’s ability to function as expected for their anticipated users.

在您可以用小数点后的9来衡量SLA的世界中，开发人员和操作人员已经敏锐地意识到了高可用性的重要性。 无论是DDOS攻击，还是利用昂贵的API调用来减慢应用程序速度的攻击者，这些攻击都会影响应用程序按预期用户的预期运行的能力。

安全编码技巧 (Secure Coding Tips)

#1 Input validation

＃1输入验证

Often the first security guideline presented is input validation, and my opinion is no different. You should always include input validation as an item when design, implementing, and testing a new application.

提出的第一个安全性指南通常是输入验证，我的看法没有什么不同。 在设计，实施和测试新应用程序时，应始终将输入验证作为一项内容包括在内。

When designing a service, you should be asking the question, what kind of input in valid and look for the smallest set of possibilities (accept JSON, or XML, but not both). For specific fields, like a number for example, do you expect integers, floats, positive only, min/max — you should figure all of this out ahead of time so you aren’t making decisions about valid input at implementation time. Plan to do validation at all interfaces, not just the one’s open to the public — you should limit your trust perimeter as much as possible.

在设计服务时，您应该问一个问题：有效的输入类型是什么，并寻找最小的可能性(接受JSON或XML，但不能同时使用两者)。 对于特定的字段(例如数字)，您是否期望整数，浮点数，仅正数，最小值/最大值-您应该提前弄清所有这些内容，以免在执行时就有效输入做出决策。 计划在所有接口上进行验证，而不仅仅是对公众开放-您应尽可能限制信任范围。

When implementing, try to stay as strict as possible and look to adopt a well-know library for validation if possible (I like joi or tv4 for node projects). Also be aware of validation on the contents of files. Be wary of DoS type attacks like the Billion Laugh Attack which is often implemented as an XML bomb, but can also use YAML, or other attacks like a zip bomb.

在实现时，尽量保持尽可能严格和看如果可能的话采用众所周知的库进行验证(我喜欢穰或TV4节点项目)。 也要注意对文件内容的验证。 警惕DoS类型的攻击，例如Billion Laugh Attack (通常被实现为XML炸弹，但是也可以使用YAML)或其他攻击(例如zip炸弹) 。

Finally, when testing an application be sure to include tests against unexpected inputs. Fuzzing is often the term used for this type of testing and there are numerous tools for doing this kind of testing.

最后，在测试应用程序时，请确保包括针对意外输入的测试。 模糊测试通常是用于此类测试的术语，并且有许多工具可以进行此类测试。

#2 Implicit deny

＃2隐式否认

Similar to the more well known firewall rule, you should treat all input/actions as suspicious until you’ve done validation to show otherwise. This applies both to the way you write logical code, as well as how you treat clients calling your applications.

与更著名的防火墙规则类似，您应该将所有输入/操作视为可疑，直到您完成验证以示其他方式为止。 这既适用于编写逻辑代码的方式，也适用于如何对待调用应用程序的客户端。

For example, in a micro-service environment, you should not assume just because another service within your platform is making a request to your service means that the client’s request is safe. You should always maintain a very small trust boundary, and do authentication and validation on all requests, regardless of their source.

例如，在微服务环境中，您不应该仅仅因为平台内的另一服务向您的服务发出请求就意味着客户端的请求是安全的。 您应该始终保持很小的信任边界，并对所有请求进行身份验证和验证，无论其来源如何。

This principal can also be applied to coding. You should always return false by default when authorizing actions or validating input rather than returning true unless the request is proven to be malformed or malicious.

该原理也可以应用于编码。 在授权操作或验证输入时，默认情况下始终应始终返回false ，而不是返回true除非事实证明该请求格式不正确或恶意。

#3 Use known good libraries and keep up-to-date

＃3使用已知良好的库并保持最新

Whenever possible, use the latest stable version of your language of choice. Many developers have worked hard to fix security bugs in languages and so it’s always recommended to use the latest stable version.

尽可能使用您选择的语言的最新稳定版本。 许多开发人员都在努力修复语言安全漏洞，因此始终建议使用最新的稳定版本。

Similarly, when it comes to using open source libraries, don’t just pick the first npm module you see on google. Do a bit of research and check reviews, outstanding issues, and any CVEs for your dependency libraries. There are also numerous free and commercial tools that can help you manage vulnerabilities in your dependencies.

同样，在使用开放源代码库时，不要只选择在Google上看到的第一个npm模块。 做一些研究并检查您的依赖库的评论，未解决的问题以及所有CVE。 还有许多免费的商业工具，可以帮助您管理依赖项中的漏洞。

Estimates vary, but I’ve seem estimates from the low 40’s to the upper 90’s for the percentage of production code that is comprised of open-source and third party libraries. The best coding in the world can’t save you if your underlying dependencies or language have nasty vulnerabilities.

估算值各不相同，但我似乎估计了由开源和第三方库组成的生产代码所占的百分比，从低40到高90。 如果您的基础依赖项或语言存在令人讨厌的漏洞，世界上最好的编码将无法挽救您。

Some tools for dependency checking include:

用于依赖性检查的一些工具包括：

• ochrona — Commercial (free version available)

  ochrona —商业(提供免费版本)

• snyk — Commercial (free version available)

  snyk —商业(提供免费版本)

• npm audit — Free (Formerly NSP)

  npm审核 —免费(以前为NSP)

• OWASP Dependency-check — Free

  OWASP依赖性检查 -免费

#4 Know when to retry and when to throw exceptions

＃4知道何时重试以及何时引发异常

There are two general rules I try to follow when error handling. First is to avoid doing general exception catchalls. These can hurt your service by allowing unexpected conditions to go unchecked. Further, in a well designed and understood application as a developer you should have some general idea what can go wrong during various processes, and you check explicitly check for those exception types.

错误处理时，我尝试遵循两个通用规则。 首先是避免做一般的异常处理。 这些可能会导致无法预料的状况不受控制，从而损害您的服务。 此外，在作为开发人员设计良好且易于理解的应用程序中，您应该具有一些一般性的想法，即在各种过程中可能出问题的地方，并且显式检查这些异常类型。

Retrying when possible is also important to ensure availability. A well-designed application knows when a request can be retried and when an exception is unexpected and should be raised. This ties into exception handling and understanding what conditions are safe to retry and what conditions are unsafe or impossible to recover from.

尽可能重试对于确保可用性也很重要。 一个经过精心设计的应用程序知道何时可以重试一个请求以及何时异常是意外的并且应该引发。 这与异常处理和了解哪些条件可以重试以及哪些条件不安全或无法从中恢复相关联。

#5 Build security into your process

＃5在您的流程中建立安全性

This could be an entire post or series of its own, but the general idea is to bake security into your development, build, and deployment processes. This is also a core tenant of DevSecOps, where the goal is to build on the DevOps movement and shift more security into the developers domain by adding additional automation into our increasingly automated build and deployment pipelines.

这可能是一个完整的帖子，也可能是它自己的系列文章，但总体思路是将安全性纳入您的开发，构建和部署过程中。 这也是DevSecOps的核心租户，其目标是在DevOps运动的基础上，通过向我们日益自动化的构建和部署管道中添加其他自动化功能，将更多的安全性转移到开发人员领域。

There are many different types of tools which you can add to improve your security posture, but Dependency Analysis (Composition Analysis), Static application security testing (SAST), Dynamic application security test (DAST), and Container testing are just a few examples.

您可以添加许多不同类型的工具来改善安全状况，但是相关性分析(组成分析)，静态应用程序安全测试(SAST)，动态应用程序安全测试(DAST)和容器测试只是其中的一些示例。

结论 (Conclusion)

While achieving good application security is an endless journey that requires tooling, knowledge, and planning, getting started doesn’t have to feel like na insurmountable challenge. By keeping these guidelines in mind and striving for incremental improvements you can begin on your journey to publishing safer code.

尽管获得良好的应用程序安全性是一个需要工具，知识和计划的无穷无尽的旅程，但是入门并不一定感觉到一个无法克服的挑战。 通过牢记这些准则并努力进行渐进式改进，您可以开始发布更安全的代码的旅程。

Similar to writing bug-free code, it’s also impossible to write risk-free code. The best you can do is try to understand your code, apply security controls when possible, and never leave security as an after-thought.

与编写无错误的代码类似，编写无风险的代码也是不可能的。 您能做的最好的事情就是尝试理解您的代码，在可能的情况下应用安全控制，并且永远不要将安全放在首位。

Hey, I’m Andrew Scott, a software developer and the creator of Ochrona. Ochrona focuses on improving python security by providing insights into your project’s dependencies and doing so with a major focus on Developer Experience (DX).

嗨，我是软件开发人员兼Ochrona的创建者Andrew Scott。 Ochrona通过提供对项目的依赖关系的洞察力来专注于提高python安全性，并着重于开发人员体验(DX)。

Sign up for our Mailing List :)

订阅我们的邮件列表 :)

翻译自: https://medium.com/ochrona/5-secure-coding-guidelines-to-keep-in-mind-63253e37b5bb

牢记昨天的教训