开发人员哪些错误不能犯_开发人员：不要在您的应用程序中犯这些十大安全错误-CSDN博客

开发人员哪些错误不能犯

As a developer, you’re the first line of defense against data breaches. You should know what to look out for, and you have a responsibility to your users to follow best practices.

作为开发人员，您是防御数据泄露的第一道防线。您应该知道要寻找的内容，并且您有责任让用户遵循最佳做法。

Luckily, there’s an organization dedicated to providing you with up-to-date guidelines for how to secure your web applications. Every web developer should know about the OWASP Top Ten.

幸运的是，有一个专门致力于为您提供有关如何保护Web应用程序的最新准则的组织。每个Web开发人员都应该了解OWASP的前十名。

OWASP十大应用程序安全风险 (The OWASP Top Ten Application Security Risks)

The Open Web Application Security Project (OWASP) is a nonprofit dedicated to promoting security on the web. They’re an awesome organization, and they do a lot of research into the threats and exploits facing modern applications.

开放Web应用程序安全项目(OWASP)是一个非营利性组织，致力于促进Web安全。他们是一个了不起的组织，他们对现代应用程序所面临的威胁和利用进行了大量研究。

According to the experts:

据专家介绍：

Using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code.

使用OWASP Top 10可能是将组织内的软件开发文化转变为产生更安全代码的文化的最有效的第一步。

Following OWASP’s recommendations is the gold standard for security. If you’re a web developer, you need to know about OWASP and understand their top recommendations.

遵循OWASP的建议是安全性的黄金标准。如果您是Web开发人员，则需要了解OWASP并了解他们的重要建议。

So, what are the biggest threats to your application?

那么，对您的应用程序最大的威胁是什么？

1.注射 (1. Injection)

Websites need to accept data from their users. They wouldn’t be very useful otherwise.

网站需要接受其用户的数据。否则它们将不会非常有用。

However, before you do anything with that data (store it, execute code on it, use it to look something up, etc), you need to make sure it’s cleaned and escaped of special characters.

但是，在对该数据执行任何操作(存储，在其上执行代码，使用它来查找内容等)之前，需要确保已清除并转义了特殊字符。

If you don’t, attackers can potentially run their own code on your servers.

如果您不这样做，攻击者可能会在服务器上运行自己的代码。

Image for post — A mom exploits a SQL injection against her son’s school

The best way to prevent injection is to use a library that sanitizes user entered data every time and as soon as user data hits your server. Every programming language for the web has tools & libraries to help sanitize inputs.

防止注入的最佳方法是使用一个库，该库每次用户数据访问您的服务器时都会对用户输入的数据进行清理。 Web的每种编程语言都有工具和库来帮助清理输入。

This is the #1 security risk because it’s the most severe (allows an attacker to run arbitrary code) and also still surprisingly common despite being a known exploit for decades.

这是第一大安全风险，因为它是最严重的(允许攻击者运行任意代码)，并且尽管几十年来一直被人们所熟知，但仍然出奇的普遍。

Want to learn more about preventing injection? OWASP has you covered.

想更多地了解预防注射？ OWASP为您服务。

2.身份验证失败 (2. Broken Authentication)

When an attacker can login as someone else, you’ve obviously got a problem.

当攻击者可以他人登录时，您显然会遇到问题。

This category of risk encompasses a lot of potential problems:

此风险类别包含许多潜在问题：

Storing passwords as plaintext in the database (NEVER, never, NEVER do this!) & then having your database compromised
将密码以纯文本格式存储在数据库中(从不，从不，从不这样做！)，然后危及数据库的安全
Storing session tokens in insecure locations, allowing attackers to use the token to gain authorization
将会话令牌存储在不安全的位置，从而使攻击者可以使用令牌获得授权
Allowing users to pick common or weak passwords that are easy for attackers to guess
允许用户选择容易被攻击者猜测的常用或弱密码
Not expiring session or API tokens, meaning a token only needs to be exposed once & it’s valid forever
不会过期的会话或API令牌，这意味着令牌只需公开一次即可，并且永远有效
Sending back different and identifiable information based on failed requests. Bad: “No such username” (If an attacker keeps guessing long enough, they’ll find a valid username that returns a different response) Good: “Invalid credentials”
根据失败的请求发送回不同且可识别的信息。错误：“没有这样的用户名”(如果攻击者不断猜测足够长的时间，他们会找到一个有效的用户名，并返回不同的响应)。好：“无效的凭据”

The top ways to prevent these issues, according to OWASP:

OWASP指出，预防这些问题的主要方法是：

Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
在可能的情况下，实施多因素身份验证以防止自动进行凭据填充，暴力破解和凭据重用攻击。
Do not deploy with any default credentials, particularly for admin users.
不要使用任何默认凭据进行部署，尤其是对于管理员用户。
Implement weak-password checks, such as validating new or changed passwords against a list of the top 10,000 worst passwords and requiring passwords to be at least 8 characters.
实施弱密码检查，例如针对前10,000个最差的密码列表验证新密码或更改的密码，并要求密码至少为8个字符。
Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
通过对所有结果使用相同的消息，确保针对帐户枚举攻击加强注册，凭证恢复和API途径。
Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
限制或越来越多地延迟失败的登录尝试。记录所有故障，并在检测到凭据填充，暴力破解或其他攻击时提醒管理员。
Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
使用服务器端安全的内置会话管理器，该管理器在登录后生成具有较高熵的新随机会话ID。会话ID不应位于URL中，在注销，空闲和绝对超时后应安全地存储它们并使其无效。

3.敏感数据公开 (3. Sensitive Data Exposure)

Over the past few years, this is the most common attack vector.

在过去的几年中，这是最常见的攻击媒介。

Things start to get tricky, because attackers can exploit many types of man-in-the middle scenarios to steal data when it’s in transit or temporarily being stored in plaintext.

事情开始变得棘手，因为攻击者可以利用多种中间人场景在传输或临时存储为纯文本时窃取数据。

The attacks can take many forms, but the most common ways attackers steal information are:

攻击可以采取多种形式，但是攻击者窃取信息的最常见方式是：

Downgrading connections from HTTPS to HTTP to decrypt data in transit
将连接从HTTPS降级到HTTP以解密传输中的数据
Cracking a weaker encryption scheme that was used to store or transfer data
破解用于存储或传输数据的较弱的加密方案
Pre-hashing popular passwords using unsalted and simpler encryption schemes then matching those hashes to stolen user tables
使用无盐且更简单的加密方案预哈希流行的密码，然后将这些哈希与被盗的用户表进行匹配
Using SQL injection to make the database engine fetch data into plaintext that was encrypted
使用SQL注入使数据库引擎将数据提取为已加密的纯文本

To prevent these attacks:

为防止这些攻击：

All sensitive data should be encrypted with a modern encryption algorithm
所有敏感数据均应使用现代加密算法进行加密
If you don’t absolutely need to store some data, then discard it — if you don’t store it, attackers cant steal it
如果您绝对不需要存储某些数据，则将其丢弃-如果您不存储数据，攻击者将无法窃取它
Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.
使用具有工作因数(延迟因数)的强大自适应和盐化哈希函数(例如Argon2 ， scrypt ， bcrypt或PBKDF2 )来存储密码。
Make sure session cookies and other sensitive browser data are only sent on HTTPS and that they’re not available in client-side javascript
确保会话Cookie和其他敏感的浏览器数据仅通过HTTPS发送，并且在客户端JavaScript中不可用

4. XML外部实体 (4. XML External Entities)

XEE attacks allow an attacker to make your code evaluate an external URL when they upload an XML file to your application.

XEE攻击使攻击者在将XML文件上传到您的应用程序时，可以使您的代码评估外部URL。

These types of attacks are especially prevalent and successful against older applications with dependencies that aren’t up to date to protect against XEE attacks.

这些类型的攻击在较旧的应用程序中尤其普遍并且成功，这些应用程序具有最新的依赖关系，无法防止XEE攻击。

The easiest way to prevent these attacks is not to use XML. Pick a stricter data format like JSON or YAML.

防止这些攻击的最简单方法是不使用XML。选择更严格的数据格式，例如JSON或YAML。

If you have to use XML, make sure all your parsers, processors, and dependencies are up to date. Source Code Analysis Tools can help identify issues in existing applications.

如果必须使用XML，请确保所有解析器，处理器和依赖项都是最新的。源代码分析工具可以帮助识别现有应用程序中的问题。

5.损坏的访问控制 (5. Broken Access Control)

This category is similar to #2 (Broken Authentication), but it applies when an attacker can access sensitive data without being logged in as the correct user.

此类别与＃2(身份验证失败)相似，但适用于攻击者可以访问敏感数据而无需以正确用户身份登录的情况。

For example, say an attacker logs in to your website and navigates to the billing history page at a URL like:

例如，假设攻击者登录到您的网站，并通过以下网址导航到“计费历史记录”页面：

mysite.com/users/1809/billing/history

It’s a good guess that the 1809 part of the URL is the user ID.

可以很好地猜测URL的1809部分是用户ID。

If an attacker can change that ID and see other users’ billing data, then you have a broken access control attack.

如果攻击者可以更改该ID并查看其他用户的账单数据，则说明您的访问控制攻击受到了破坏。

Similarly, attackers can manipulate other IDs, tokens, or credentials to visit blocked URLs or elevate their privileges to admin.

同样，攻击者可以操纵其他ID，令牌或凭据来访问被阻止的URL或将其特权提升为管理员。

Checklist to prevent these attacks:

防止这些攻击的清单：

Deny by default for all web requests and API endpoints — make authentication standardized and default across your application
默认情况下，所有Web请求和API端点均拒绝-标准化身份验证并在整个应用程序中默认设置
Create, read, update, and delete access on data models should always be user-specific and managed with explicit model permissions
对数据模型的创建，读取，更新和删除访问应始终是用户特定的，并应具有明确的模型权限进行管理
Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots
禁用Web服务器目录列表，并确保Web根目录中不存在文件元数据(例如.git)和备份文件
Log access control failures, alert admins when appropriate (e.g. repeated failures)
记录访问控制失败，在适当时提醒管理员(例如，反复失败)
Rate limit your API and URLs to prevent manipulation that comes from automated tools
为您的API和URL设置速率限制，以防止来自自动化工具的操纵

6.安全配置错误 (6. Security Misconfiguration)

No matter how secure your server or client-side framework is, it means nothing if you have the security settings poorly configured.

无论您的服务器或客户端框架有多安全，如果安全设置配置不当，这都没有任何意义。

For example, many frameworks include debug settings that are useful when developing but dangerous if released into production.

例如，许多框架都包含调试设置，这些调试设置在开发时很有用，但如果发布到生产环境中则很危险。

Other pitfalls:

其他陷阱：

Leaving default accounts active and/or with their default passwords unchanged
保持默认帐户处于活动状态和/或保持默认密码不变
Having error messages that reveal stack traces or other info about configuration
具有错误消息，可显示堆栈跟踪或其他有关配置的信息
Using out of date frameworks and libraries without the most recent security patches
使用没有最新安全补丁的过时框架和库
Leaving environment variables or other secure keys in publicly accessible config files or source control
将环境变量或其他安全密钥保留在公共可访问的配置文件或源代码管理中

Luckily, remedying these problems is easy. Use the most up-to-date version of your framework & libraries. Then, learn about and follow security best practices for configuring your application for production.

幸运的是，解决这些问题很容易。使用您的框架和库的最新版本。然后，了解并遵循安全最佳实践来配置应用程序以进行生产。

Additionally, make sure the process for deploying to production always and predictably includes these security hardening steps.

另外，请确保用于生产的部署过程始终且可预测地包括这些安全强化步骤。

7.跨站点脚本(XSS) (7. Cross-Site Scripting (XSS))

This is an increasingly popular (and dangerous) attack vector as client-side JavaScript has become more prevalent.

随着客户端JavaScript变得越来越普遍，这是一种越来越流行(且危险)的攻击媒介。

Basically, this attack involves running malicious JavaScript and HTML in the user’s browser. While the code appears to come from a verified site, it’s actually from a dangerous source.

基本上，这种攻击涉及在用户的浏览器中运行恶意JavaScript和HTML。虽然代码似乎来自经过验证的站点，但实际上是来自危险来源。

For example, if a site you trusted opened a popup like this, would you fill it out?

例如，如果您信任的站点打开了这样的弹出窗口，您会填写它吗？

While it looks trustworthy, it may also have come from an attacker spoofing the design and features of the target site.

尽管它看起来值得信赖，但它可能也源于攻击者欺骗了目标站点的设计和功能。

Malicious XSS attacks come in 3 basic varieties:

恶意XSS攻击分为3种基本类型：

Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output.
反映的XSS ：应用程序或API包含未经验证和未转义的用户输入，作为HTML输出的一部分。
Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator.
已存储的XSS ：应用程序或API存储未过滤的用户输入，稍后由其他用户或管理员查看。
DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM manipulation.
DOM XSS ：动态地将攻击者可控制的数据包含到页面JavaScript框架，单页应用程序和API容易受到DOM操作的攻击。

To protect against these attacks:

为了防止这些攻击：

Use up-to-date frameworks that protect against XSS — Django, Rails, Spring, React, Angular, and all other major frameworks include provisions for XSS
使用防止XSS的最新框架-Django，Rails，Spring，React，Angular和所有其他主要框架都包括针对XSS的规定
Never put untrusted data inside a script, HTML comment, tags, tag attributes, or directly in CSS
切勿将不受信任的数据放在脚本，HTML注释，标签，标签属性中或直接放在CSS中
Escape any untrusted data you do insert into the page:
转义您插入页面的所有不受信任的数据：

 & --> &amp;
 < --> &lt;
 > --> &gt;
 " --> &quot;
 ' --> &#x27;
 / --> &#x2F;

8.不安全的反序列化 (8. Insecure Deserialization)

Complex applications often need to pass data models back and forth between services.

复杂的应用程序通常需要在服务之间来回传递数据模型。

For example, a React app may need to talk to a Spring Boot backend. Since the requests can be complicated and based on a lot of conditions, the developers just serialize the React application’s state and then send that to the backend with every request.

例如，React应用可能需要与Spring Boot后端进行对话。由于请求可能很复杂，并且基于很多条件，因此开发人员只需序列化React应用程序的状态，然后将其与每个请求一起发送到后端。

When an attacker notices that the Java objects are coming back with a certain signature, they can use tools like Java Serial Killer to infiltrate the server.

当攻击者注意到Java对象以特定签名返回时，他们可以使用Java Serial Killer之类的工具来渗透服务器。

Similarly, a PHP site might use PHP’s object serialization to save a cookie with the user’s session ID and privileges. Spoofing that serialization would allow an attacker to elevate their privileges or login as someone else.

同样，PHP站点可能使用PHP的对象序列化来保存具有用户会话ID和特权的cookie。欺骗该序列化将使攻击者能够提升其特权或以其他人的身份登录。

What you can do about deserialization attacks:

您可以对反序列化攻击做什么：

Don’t serialize objects directly. Instead, use a data format that only allows for primitive types (e.g. — Use a JSON schema of your object)
不要直接序列化对象。相反，请使用仅允许原始类型的数据格式(例如，使用对象的JSON模式)
Add hashed signatures to serialized objects to make sure they haven’t been tampered with.
将哈希签名添加到序列化对象中，以确保它们未被篡改。
Only deserialize in isolated, low privilege situations & log all exceptions so you can disable or rate limit users that are deserializing too often
仅在孤立的低特权情况下反序列化并记录所有异常，以便您可以禁用或限制经常反序列化的用户

9.使用具有已知漏洞的组件 (9. Using Components with Known Vulnerabilities)

This one is also easy to avoid. If your third-party libraries are out of date, chances are you have a security vulnerability.

这也是很容易避免的。如果您的第三方库已过期，则很可能存在安全漏洞。

Upgrading your dependencies will usually fix these vulnerabilities.

升级依赖项通常可以解决这些漏洞。

In fact, source control providers like GitHub can help you monitor and prioritize these issues:

实际上，像GitHub这样的源代码控制提供程序可以帮助您监视这些问题并确定优先级：

Furthermore, GitHub can automatically create a pull request to upgrade your dependencies.

此外，GitHub可以自动创建拉取请求以升级您的依赖项。

10.日志和监控不足 (10. Insufficient Logging & Monitoring)

What gets measured gets managed.

测量的东西得到管理。

Nearly every major security incident would be mitigated with earlier warnings.

几乎所有重大安全事件都可以通过早期警告得到缓解。

Logging and monitoring is the foundation of security, because it allows you to track, review, and blacklist suspicious requests.

日志记录和监视是安全性的基础，因为它使您可以跟踪，查看和将可疑请求列入黑名单。

According to OWASP:

根据OWASP：

MIn 2016, identifying a breach took an average of 191 days — plenty of time for damage to be inflicted.

MIn 2016年，识别违规行为平均需要191天 -造成损害的时间很多。

Things to start monitoring today:

今天要开始监视的事情：

Logins
登录名
Failed logins
登录失败
Any high-value transactions
任何高价值交易
Request frequency by user
用户请求频率

Once you have logs for these things:

一旦有了这些事情的日志：

Make sure there are alert thresholds for suspicious activity
确保有可疑活动的警报阈值
Log this data to somewhere outside the local server
将此数据记录到本地服务器之外的某个位置
Preferably, use a third party monitoring service to consume and visualize your logs — raising alarms in real time
最好使用第三方监视服务来使用和可视化您的日志-实时发出警报
Run a penetration testing scan (using a tool like OWASP ZAP — see I told you OWASP is awesome) and make sure it triggers your alerts
运行渗透测试扫描(使用OWASP ZAP之类的工具-看到我告诉您OWASP很棒)，并确保它触发了警报

Since the variety of possible attacks is so wide, logging is your best bet to detect attacks when they come.

由于可能的攻击种类繁多，因此记录日志是检测攻击发生时的最佳选择。

我从OWASP十大中学到的东西 (What I Learned from the OWASP Top Ten)

Discovering the OWASP top ten has changed the way I approach web development.

发现OWASP的前十名改变了我进行Web开发的方式。

Of course, I’ve always known that security is important, and I’ve heard of the more common attacks in this list.

当然，我一直都知道安全性很重要，而且我听说过此列表中更常见的攻击。

Thanks to OWASP, however, we now have a clear checklist of attack vectors and best practices to protect against them.

但是，由于有了OWASP，我们现在有了一个清晰的清单，列出了攻击媒介和最佳实践，以防止受到攻击。

OWASP even has awesome open source projects to help test, harden, and analyze your application. Their Juice Shop example is especially helpful to train developers on the ways these attacks could take place.

OWASP甚至还提供了很棒的开源项目来帮助测试，强化和分析您的应用程序。他们的Juice Shop示例对培训开发人员如何进行这些攻击的方式特别有用。

Every developer has a responsibility to protect user data. It’s critical that all developers know about the OWASP Top Ten security risks and how to address them.

每个开发人员都有责任保护用户数据。所有开发人员都必须了解OWASP十大安全风险以及如何解决这些风险，这一点至关重要。

关于贝内特 (About Bennett)

I’m a software developer in New York City. I do web stuff in Python and JavaScript.

我是纽约市的软件开发人员。我使用Python和JavaScript编写网络内容。

Like what you’ve read here? I have an email list you can subscribe to. Infrequent emails, only valuable content, no time wasters. I’d love to have you there.

喜欢您在这里阅读的内容吗？我有一个可以订阅的电子邮件列表。电子邮件很少，只有有价值的内容，没有时间浪费。我很想带你去。