web应用程序安全与风险_Web应用程序中的十大安全风险

web应用程序安全与风险

Every year, the Open Web Application Security Project (OWASP) brings out a document that contains the top 10 security risks. This document is created to raise awareness for web application security and is especially useful for developers. It represents a broad consensus about the most critical security risks to web applications.

每年，开放Web应用程序安全性项目(OWASP)都会发布一份文档，其中包含十大安全风险。 创建该文档是为了提高人们对Web应用程序安全性的意识，对开发人员特别有用。 它代表了对Web应用程序最严重的安全风险的广泛共识。

Part of your job as a developer is to be aware of the security risks that could be threatening one of your applications. Being aware of these threats is a good first step. Learning about them and knowing how you can avoid them is crucial to the process of mitigating security risks! So without further ado, let’s jump straight into the top 10 security risks.

作为开发人员的部分工作是要意识到可能威胁您的应用程序之一的安全风险。 意识到这些威胁是一个很好的第一步。 了解它们并知道如何避免它们对于减轻安全风险至关重要！ 因此，事不宜迟，让我们直接跳入十大安全风险。

1.注射 (1. Injection)

Injections should be nothing new to you as a developer. We’ve all probably heard about the bad things that can happen when an injection flaw exists within your application.

作为开发人员，注入对于您来说应该不是什么新鲜事物。 我们都可能听说过当应用程序中存在注入缺陷时可能发生的不良情况。

There are a lot of different types of injection flaws, such as SQL, NoSQL, OS, and LDAP injection. An injection can occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. This is often caused by user-supplied data that isn’t validated, filtered, or sanitized by the application.

有许多不同类型的注入漏洞，例如SQL，NoSQL，OS和LDAP注入。 当不可信数据作为命令或查询的一部分发送到解释器时，可能会发生注入。 攻击者的敌对数据可能会诱使解释器执行未经预期的命令或未经适当授权而访问数据。 这通常是由应用程序未验证，过滤或清除的用户提供的数据引起的。

It might seem obvious to most of you, but your application should not solely rely on front-end validation. Make sure to always validate your data server-side. Always. Front-end validation is easy to get around (e.g. when a user has JavaScript disabled).

对于大多数人来说，这似乎很明显，但是您的应用程序不应仅依赖于前端验证。 确保始终验证您的数据服务器端。 总是。 前端验证很容易解决(例如，当用户禁用JavaScript时)。

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

It turns out that a lot of security risks are caused by broken authentication. This mainly has to do with an incorrect implementation. Application functions related to authentication and session management are often implemented incorrectly.

事实证明，很多安全风险是由身份验证损坏引起的。 这主要与不正确的实现有关。 与身份验证和会话管理相关的应用程序功能通常会错误地实现。

This allows attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

这使攻击者可以破坏密码，密钥或会话令牌，或利用其他实施缺陷来临时或永久地假定其他用户的身份。

And that’s all because a piece of code didn’t work as intended.

那是因为一段代码没有按预期工作。

However, there are some measures that you could take. Where possible, you should implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.

但是，您可以采取一些措施。 在可能的情况下，您应该实施多因素身份验证，以防止自动进行凭据填充，暴力破解和凭据重用攻击。

On top of that, you could implement a weak-password check. Passwords that are being entered by the user should not be in the list of the top 10,000 worst passwords.

最重要的是，您可以实施弱密码检查。 用户输入的密码不应在前10,000个最差密码的列表中。

Furthermore, you shouldn’t ship or deploy with any default credentials—particularly for admin users. This might seem obvious, but it happens way too often.

此外，您不应使用任何默认凭据(特别是对于管理员用户)进行运送或部署。 这看起来似乎很明显，但是它发生得太频繁了。

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

A lot of web applications and APIs do not properly protect sensitive data, such as financial and health care data. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes.

许多Web应用程序和API无法适当地保护敏感数据，例如财务和医疗保健数据。 攻击者可能会窃取或修改这些受保护程度不高的数据，以进行信用卡欺诈，身份盗窃或其他犯罪。

Sensitive data may be compromised without extra protection and requires special precautions when exchanged with the browser.

敏感数据可能会受到损害而没有额外的保护，并且与浏览器进行交换时需要采取特殊的预防措施。

If you want to know if your application is vulnerable, you want to know how data is transmitted. Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, and FTP. You also want to make sure that no old or weak cryptographic algorithms are being used since these are easy to crack.

如果您想知道您的应用程序是否容易受到攻击，则想知道如何传输数据。 是否有任何以明文形式传输的数据？ 这涉及诸如HTTP，SMTP和FTP之类的协议。 您还希望确保不使用任何旧的或弱加密算法，因为它们很容易破解。

Probably one of the best ways to prevent sensitive data from being exposed is by making sure to encrypt all sensitive data at rest.

防止暴露敏感数据的最佳方法之一可能是确保对静态的所有敏感数据进行加密。

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

XML External Entities (XXE) is a type of attack against an application that parses XML input. Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

XML外部实体(XXE)是对解析XML输入的应用程序的一种攻击。 许多较旧的或配置不当的XML处理器都会评估XML文档中的外部实体引用。 外部实体可以使用文件URI处理程序，内部文件共享，内部端口扫描，远程代码执行和拒绝服务攻击来公开内部文件。

Most XXE vulnerabilities exist because the application accepts XML directly or XML uploads—especially from untrusted sources—or inserts untrusted data into XML documents, which is then parsed by an XML processor.

之所以存在大多数XXE漏洞，是因为该应用程序直接接受XML或XML上传(尤其是来自不受信任来源的XML)或将不受信任的数据插入XML文档中，然后由XML处理器对其进行解析。

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

Restrictions on what authenticated users are allowed to do are often not properly enforced. Most of the time, users have way too many permissions, which is asking for trouble.

通常，对身份验证用户允许执行的操作的限制通常未得到正确执行。 大多数情况下，用户拥有太多权限，这很麻烦。

Attackers can exploit these flaws to access unauthorized functionality or data, such as access to other users’ accounts, view sensitive files, modify other users’ data, and change access rights.

攻击者可以利用这些缺陷来访问未经授权的功能或数据，例如访问其他用户的帐户，查看敏感文件，修改其他用户的数据以及更改访问权限。

Here’s a really good rule of thumb that you could use as a developer: With the exception of public resources, deny access by default. It’s better to be safe than sorry. On top of that, you could log access control failures and even alert admins when too many access control failures occur.

这是您可以用作开发人员的一个很好的经验法则：除公共资源外，默认情况下拒绝访问。 安全胜于后悔。 最重要的是，您可以记录访问控制失败，甚至在发生太多访问控制失败时向管理员发出警报。

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

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, misconfigured HTTP headers, and verbose error messages containing sensitive information.

安全配置错误是最常见的问题。 这通常是由于默认配置不安全，配置不完整或临时，HTTP标头配置错误以及包含敏感信息的详细错误消息所致。

Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be upgraded in a timely fashion.

不仅必须安全地配置所有操作系统，框架，库和应用程序，而且还必须及时升级它们。

To minimize the chances of security misconfiguration, you should avoid installing or enabling unnecessary features. Also, avoid stack traces or other overly informative error messages to users that can be revealed by error handling. And of course, change default accounts and their passwords.

为了最大程度地减少安全性错误配置的机会，应避免安装或启用不必要的功能。 另外，避免向用户显示堆栈跟踪或其他信息过多的错误消息，这些消息可能会因错误处理而暴露出来。 当然，请更改默认帐户及其密码。

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

Cross-site scripting (XSS) is one of the most popular flaws on the web nowadays. XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or when an existing web page gets updated with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser that can hijack user sessions, deface websites, or redirect the user to malicious sites.

跨站点脚本(XSS)是当今网络上最受欢迎的缺陷之一。 每当应用程序在未经适当验证或转义的情况下在新网页中包含不受信任的数据，或者使用可创建HTML或JavaScript的浏览器API用用户提供的数据更新现有网页时，都会发生XSS漏洞。 XSS允许攻击者在受害者的浏览器中执行脚本，这些脚本可以劫持用户会话，破坏网站或将用户重定向到恶意站点。

To prevent your website from being vulnerable to XSS attacks, you could use a framework that automatically escapes XSS by design, such as React. And it’s always a good idea to escape untrusted HTTP request data based on the context in the HTML output.

为了防止您的网站容易受到XSS攻击，您可以使用一个框架，该框架可以根据设计自动转义XSS，例如React 。 并且，根据HTML输出中的上下文转义不受信任的HTTP请求数据始终是一个好主意。

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

Exploiting deserialization can be hard to pull off. This is because off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code.

利用反序列化可能很难实现。 这是因为现成的漏洞利用程序在不对底层漏洞利用代码进行更改或调整的情况下极少起作用。

However, the risks are very high. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

但是，风险很高。 不安全的反序列化通常会导致远程执行代码。 即使反序列化缺陷不会导致远程执行代码，也可以将它们用于执行攻击，包括重播攻击，注入攻击和特权升级攻击。

There are a few things that you can do to prevent insecure deserialization. One of the things that you could do is implement an integrity check, such as digital signatures on any serialized objects. This prevents hostile object creation or data tampering.

您可以采取一些措施来防止不安全的反序列化。 您可以做的一件事是实施完整性检查，例如对任何序列化对象进行数字签名。 这样可以防止恶意创建对象或篡改数据。

Another thing that you could do is enforce strict type constraints during deserialization before object creation. Note that bypasses to this technique have been demonstrated, so reliance solely on this isn’t advisable.

您可以做的另一件事是在对象创建之前的反序列化期间强制执行严格的类型约束。 请注意，已经演示了绕过此技术的方法，因此建议不要完全依赖此技术。

You could also isolate and run code that deserializes in low-privilege environments if possible. If that’s not possible, you could always log deserialization exceptions and failures, such as where the incoming type isn’t the expected type.

如果可能，您还可以隔离并运行在低特权环境中反序列化的代码。 如果那不可能，您总是可以记录反序列化异常和失败，例如传入类型不是期望的类型。

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

This security risk bugs me a lot. Some developers tend to use components with known vulnerabilities just to get their code to work. Components in this context mean libraries, frameworks, and other software modules.

这种安全风险使我非常烦恼。 一些开发人员倾向于使用具有已知漏洞的组件来使他们的代码正常工作。 在本文中，组件是指库，框架和其他软件模块。

All of them run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

它们全部以与应用程序相同的特权运行。 如果利用了易受攻击的组件，则此类攻击可能会导致严重的数据丢失或服务器接管。 使用具有已知漏洞的组件的应用程序和API可能破坏应用程序防御，并造成各种攻击和影响。

To minimize this risk, you should remove unused dependencies, unnecessary features, and files. Furthermore, you should monitor all your components on a regular basis to check if there any known vulnerabilities. One simple way to do this is by subscribing to security bulletins.

为了最大程度地降低这种风险，您应该删除未使用的依赖项，不必要的功能和文件。 此外，您应该定期监视所有组件，以检查是否存在任何已知漏洞。 一种简单的方法是订阅安全公告。

10.记录和监视不足 (10. Insufficient Logging and Monitoring)

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems. This can have huge consequences. Attackers could tamper, extract, or destroy data. Or they could possibly pivot to more systems.

日志记录和监控不足，再加上事件响应的缺失或无效集成，使攻击者可以进一步攻击系统。 这会产生巨大的后果。 攻击者可能篡改，提取或破坏数据。 否则他们可能会转向更多系统。

Shocking fact: Most breach studies show that the time to detect a breach is over 200 days, and it’s typically detected by external parties rather than internal processes or monitoring.

令人震惊的事实：大多数违规研究表明，检测到违规的时间超过200天，通常由外部各方而不是内部流程或监视来检测。

翻译自: https://medium.com/better-programming/the-top-10-security-risks-in-web-applications-412847f01904

web应用程序安全与风险