本文共 10695 字，大约阅读时间需要 35 分钟。
owasp top 10
In terms of security, there are many vulnerabilities that need to be treated and prevented, but some need more attention than others. Without question, the best guide to help you address these security issues is The Open Web Application Security Project.
在安全性方面，有许多漏洞需要加以处理和预防，但有些漏洞比其他漏洞需要引起更多关注。 毫无疑问，帮助您解决这些安全问题的最佳指南是The Open Web Application Security Project。
started as a simple project to raise awareness among developers and managers about the most common web security problems. And nowadays it has become a standard in application security.
最初是一个简单的项目，旨在提高开发人员和管理人员对最常见的Web安全问题的认识。 如今，它已成为应用程序安全性的标准。
In this article, we’ll give a more in-depth technical overview of some of the vulnerabilities listed in the OWASP project and how to mitigate them. We will do bad code - good code examples side by side to help you better understand and prevent these types of attacks and to improve your
在本文中，我们将对OWASP项目中列出的某些漏洞以及如何缓解这些漏洞进行更深入的技术概述。 我们将并排执行不良代码-良好的代码示例，以帮助您更好地理解和防止此类攻击并提高
This type of vulnerability happens when a program allows an attacker to supply untrusted/malicious input data. This causes the interpreter to execute unexpected commands, usually to reveal data that should otherwise be inaccessible or to bypass some security implementation.
当程序允许攻击者提供不可信/恶意输入数据时，就会发生这种类型的漏洞。 这使解释器执行意外的命令，通常会显示本来应该不可访问的数据或绕过某些安全性实施。
The most common cause of injection vulnerabilities results from a software’s failure to filter, validate or sanitize a user’s input.
注入漏洞的最常见原因是软件无法过滤 ， 验证或清除用户输入的结果。
Let’s take a look at two “wrong code implementations” which allow injection attacks to happen.
让我们看一下两个“错误的代码实现”，它们允许发生注入攻击。
Let’s say you have a login route that receives an email and for whatever reason, it receives the password already hashed.
假设您有一个接收电子邮件的登录路由，无论出于何种原因，它都会接收已经散列的密码。
If we know a user’s email address, for example myemail@email.com, then we can effortlessly bypass this login system by sending the following JSON object, which creates a NoSQL injection.
如果我们知道用户的电子邮件地址，例如myemail@email.com ，则可以通过发送以下JSON对象(创建NoSQL注入)毫不费力地绕过该登录系统。
{ "email": "myemail@email.com", "password": { "$ne": "" }} This object will instruct the MongoDb to find a user with the email “myemail@email.com” and with a password different from an empty string.
该对象将指示MongoDb查找电子邮件为“ myemail@email.com”且密码不同于空字符串的用户。
This example may be a little far-fetched, but take a look at the following code and see if you can spot the problem.
这个示例可能有点牵强，但是请看下面的代码，看看是否可以发现问题。
For this example we have a registration form on the interface with the following code on the back-end:
对于此示例，我们在界面上有一个注册表，在后端具有以下代码：
How we can exploit this code? Very simple: let’s say for this example that the User Schema looks like this:
我们如何利用此代码？ 非常简单：在这个示例中，用户模式如下所示：
export const UserSchema = new mongoose.Schema({ email: { type: String, required: true, unique: true }, password: { type: String, required: true }, admin: { type: Boolean, default: false }, accountConfirmed: { type: Boolean, default: false },}, ); Now just send the following POST request with Postman or any other tool that you prefer to use:
现在，使用Postman或您希望使用的任何其他工具发送以下POST请求：
{ "email": "my-email", "password": "123321", "admin": "true", "accountConfirmed": "true"} And now you have successfully registered on this website – not as a simple user but with a confirmed admin account.
现在，您已经成功在此网站上注册-不是简单的用户，而是已确认的管理员帐户。
The problem here is that if we just simply use:
这里的问题是，如果我们只是简单地使用：
{ ...req.body } then we will create a new user object with all the properties inside the object body, so here we can inject anything we want.
然后我们将在对象主体内创建所有属性的新用户对象，以便在此处注入所需的任何内容。
Let’s refactor the code from both examples to prevent this kind of attack.
让我们从两个示例中重构代码以防止这种攻击。
For the first example, we can check the expected type for both email and password. In our case we are waiting for a string in both fields:
对于第一个示例，我们可以检查电子邮件和密码的预期类型。 在我们的例子中，我们正在两个字段中等待一个字符串：
If we supply the same parameters again:
如果我们再次提供相同的参数：
{ "email": "myemail@email.com", "password": { "$ne": "" }} We will receive a 400 Bad Request response. We can go even further and check if the email is actually an email and not just a simple string, but this is out of our scope for now.
我们将收到400错误的请求响应。 我们甚至可以进一步检查该电子邮件是否实际上是一封电子邮件，而不仅仅是一个简单的字符串，但这不在我们的讨论范围之内。
For the second one, we can use “whitelist” server-side input validation by stripping off unwanted properties:
对于第二个，我们可以通过剥离不需要的属性来使用“白名单”服务器端输入验证：
These examples were for NoSQL injection, but this technique can be extended for as well.
这些示例用于NoSQL注入，但是该技术也可以扩展到 。
Above we saw some poorly implemented security standards which resulted from our mistakes. However there are situations when the problem is not from the code that we wrote, but from the open-source code that we use in our project.
在上面，我们看到了由于错误而导致的一些安全标准执行不力。 但是，在某些情况下，问题不是来自我们编写的代码，而是来自我们在项目中使用的开源代码。
An attacker can exploit the vulnerabilities of these components to execute malicious code or to make the program behave in an unwanted manner.
攻击者可以利用这些组件的漏洞来执行恶意代码或使程序以不良方式运行。
Even though this seems to be out of your hands, it is not. There are steps we can take to prevent this kind of problem.
即使这似乎无法控制，但事实并非如此。 我们可以采取一些步骤来防止这种问题。
For example, we can do a continuous inventory for component versions of both the client-side and server-side and remove unused dependencies and / or features.
例如，我们可以对客户端和服务器端的组件版本进行连续清点，并删除未使用的依赖项和/或功能。
We can monitor sources like this maintained by WhiteSource for vulnerabilities in the components.
我们可以监视诸如WhiteSource维护类中组件中的漏洞。
To ensure that your components are safe you should check vulnerability databases regularly and apply security patches promptly. This will help you to stay protected.
为确保组件安全，应定期检查漏洞数据库并及时应用安全补丁。 这将帮助您保持保护。
This vulnerability comes into play when web apps implement authentication/session management techniques poorly. This is because it gives attackers access to accounts that they otherwise shouldn’t be authorized to access.
当Web应用程序实施的身份验证/会话管理技术不佳时，此漏洞就会发挥作用。 这是因为它为攻击者提供了访问帐户的权限，否则他们不应被授权访问。
This security issue is most widespread in the form of brute force attacks and when session-ids / tokens are exposed in such a form that they can be easily stolen.
此安全问题以蛮力攻击的形式最普遍，并且当会话ID /令牌以很容易被盗的形式暴露时。
Let’s take the example from the previous code snippet. We tweaked it a little bit to send a 401 (Unauthorized) response when no user is found with a given email and password.
让我们以前面的代码片段为例。 当未找到具有给定电子邮件和密码的用户时，我们对其进行了一些微调，以发送401 (未经授权)响应。
Even though this is the refactored code, it is still vulnerable to Broken Auth. Here, if we use a wrong password, we get a 401 response. But if the password is weak we can brute force it until we guess it.
即使这是重构的代码，它仍然容易受到“验证失败”的攻击。 在这里，如果我们使用错误的密码，则会收到401响应。 但是，如果密码很弱，我们可以对其进行暴力破解，直到我们猜出来为止。
We can prevent brute force attacks by simply using a rate limit on our route. Now the user has 3 chances to authenticate, after which they will no longer be able to send requests on this route for the next 15 minutes (and will get a response of 429 Too many requests).
我们只需在路线上使用速率限制，就可以防止暴力攻击。 现在，用户有3次机会进行身份验证，在此之后，他们将在接下来的15分钟内不再能够在此路由上发送请求(并且将收到429个请求过多的响应 )。
The next type of vulnerability on this topic has to do especially with the poorly JSON web token management.
与该主题有关的下一类漏洞尤其与JSON Web令牌管理不佳有关。
The next example is very frequently found in login systems:
下一个示例在登录系统中很常见：
Most of the time, a login system using JWT is implemented in this way. After the user sends the right credentials a token is generated using their id or another unique value. Then the token is sent to the front-end where it will be saved inside the application. Or if a persistent authentication is needed it will be saved inside cookies or local storage.
大多数情况下，使用JWT的登录系统是通过这种方式实现的。 用户发送正确的凭据后，将使用其ID或另一个唯一值生成令牌。 然后将令牌发送到前端，将其保存在应用程序内部。 或者，如果需要持久身份验证，它将保存在Cookie或本地存储中。
The problem with this approach is that the token that should be secured can now be accessed through the front-end code, thus making it vulnerable. Malicious code injected into the front-end JavaScript could access cookies or local storage and steal this token.
这种方法的问题在于，现在可以通过前端代码访问应该保护的令牌，从而使其容易受到攻击。 注入前端JavaScript的恶意代码可能访问cookie或本地存储并窃取此令牌。
This problem can be overcome with the next implementation.
下一个实现可以解决此问题。
This time the token is also saved in cookies, but it is saved from the back-end code with the httpOnly property. This means that it cannot be accessed from any code running on the front end.
这次令牌也保存在cookie中，但是使用httpOnly属性从后端代码中保存。 这意味着无法从前端运行的任何代码访问它。
To make it more secure, the token is saved with the signed property, which causes the cookies to be signed with a secret key.
为了使其更加安全，令牌将与signed属性一起保存，这将导致cookie使用密钥进行签名。
You can go even further and block the http protocol with the secure flag which forces the cookie to be sent over https.
您甚至可以更进一步，并使用安全标志阻止http协议，该标志强制cookie通过https发送。
As the name indicates, this vulnerability fires when a web application fails to sufficiently protect sensitive data.
顾名思义，当Web应用程序无法充分保护敏感数据时，将触发此漏洞。
While recent legal changes such as should ensure that sensitive data is not exposed, a significant percentage of web applications fail to meet these requirements.
尽管最近的法律更改(例如应确保不暴露敏感数据，但相当一部分Web应用程序无法满足这些要求。
This usually happens when data is transmitted in clear text using HTTP, SMTP and FTP, or when weak/old cryptographic algorithms are used.
当使用HTTP，SMTP和FTP以明文形式传输数据时，或者使用弱/旧加密算法时，通常会发生这种情况。
A likely scenario can be the following:
可能的情况如下：
A web site doesn’t use or enforce TLS for all pages. An attacker monitors network traffic, downgrades connections from HTTPS to HTTP, intercepts requests, and steals the information sent. Maybe they even steal the user’s session cookie, thus, accessing or modifying the user’s private data.
网站未对所有页面使用或强制使用TLS。 攻击者监视网络流量，将连接从HTTPS降级到HTTP，拦截请求，并窃取发送的信息。 也许他们甚至窃取了用户的会话cookie，从而访问或修改了用户的私有数据。
Another scenario can be:
另一种情况可以是：
Passwords are stored inside the database unsalted or as simple and weak hashes. A file upload flaw or any other attack allows an attacker to retrieve the password database. After that, all the hashes can be exposed with a rainbow table of pre-calculated values, thus giving to the attacker the actual plain password of the users.
密码不加盐或作为简单弱哈希存储在数据库中。 文件上传漏洞或任何其他攻击都使攻击者可以检索密码数据库。 之后，所有散列都可以使用预先计算的值的彩虹表公开，从而向攻击者提供用户的实际普通密码。
翻译自:
owasp top 10
转载地址：http://ufuzd.baihongyu.com/