web应⽤程序安全与风险_Web应⽤程序中的⼗⼤安全风险web应⽤程序安全与风险
Every year, the Open Web Application Security Project (OWASP) brings out a document that contains the top 10 curity risks. This document is created to rai awareness for web application curity and is especially uful for developers. It reprents a broad connsus about the most critical curity risks to web applications.
每年，开放Web应⽤程序安全性项⽬(OWASP)都会发布⼀份⽂档，其中包含⼗⼤安全风险。 创建该⽂档是为了提⾼⼈们对Web应⽤程序安全性的意识，对开发⼈员特别有⽤。 它代表了对Web应⽤程序最严重的安全风险的⼴泛共识。
Part of your job as a developer is to be aware of the curity risks that could be threatening one of your applications. Being aware of the threats is a good first step. Learning about them and knowing how you can avoid them is crucial to the process of mitigating curity risks! So without further ado, let’s jump straight into the top 10 curity 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 nt 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 caud by ur-supplied data that isn’t validated, filtered, or sanitized by the application.
舞台剧是什么有许多不同类型的注⼊漏洞，例如SQL，NoSQL，OS和LDAP注⼊。 当不可信数据作为命令或查询的⼀部分发送到解释器时，可能会发⽣注⼊。 攻击者的敌对数据可能会诱使解释器执⾏未经预期的命令或未经适当授权⽽访问数据。 这通常是由应⽤程序未验证，过滤或清除的⽤户提供的数据引起的。
It might em obvious to most of you, but your application should not solely rely on front-end validati
on. Make sure to always validate your data rver-side. Always. Front-end validation is easy to get around (e.g. when a ur has JavaScript disabled).
对于⼤多数⼈来说，这似乎很明显，但是您的应⽤程序不应仅依赖于前端验证。 确保始终验证您的数据服务器端。 总是。 前端验证很容易解决(例如，当⽤户禁⽤JavaScript时)。
2.⾝份验证失败 (2. Broken Authentication)
It turns out that a lot of curity risks are caud by broken authentication. This mainly has to do with an incorrect implementation. Application functions related to authentication and ssion management are often implemented incorrectly.
事实证明，很多安全风险是由⾝份验证损坏引起的。 这主要与不正确的实现有关。 与⾝份验证和会话管理相关的应⽤程序功能通常会错误地实现。
This allows attackers to compromi passwords, keys, or ssion tokens, or to exploit other implementation flaws to
assume other urs’ identities temporarily or permanently.
壶口瀑布在哪个省
这使攻击者可以破坏密码，密钥或会话令牌，或利⽤其他实施缺陷来临时或永久地假定其他⽤户的⾝份。
And that’s all becau 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-u attacks.
但是，您可以采取⼀些措施。 在可能的情况下，您应该实施多因素⾝份验证，以防⽌⾃动进⾏凭据填充，暴⼒破解和凭据重⽤攻击。
On top of that, you could implement a weak-password check. Passwords that are being entered by the ur should not be in the list of the .
最重要的是，您可以实施弱密码检查。 ⽤户输⼊的密码不应的列表中。
Furthermore, you shouldn’t ship or deploy with any default credentials—particularly for admin urs. This might em obvious, but it happens way too often.
此外，您不应使⽤任何默认凭据(特别是对于管理员⽤户)进⾏运送或部署。 这看起来似乎很明显，但是它发⽣得太频繁了。
3.敏感数据公开 (3. Sensitive Data Exposure)
A lot of web applications and APIs do not properly protect nsitive 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 compromid without extra protection and requires special precautions when exchanged with the browr.
敏感数据可能会受到损害⽽没有额外的保护，并且与浏览器进⾏交换时需要采取特殊的预防措施。
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 ud since the are easy to crack.
如果您想知道您的应⽤程序是否容易受到攻击，则想知道如何传输数据。 是否有任何以明⽂形式传输的数据？ 这涉及诸如HTTP，SMTP 和FTP之类的协议。 您还希望确保不使⽤任何旧的或弱加密算法，因为它们很容易破解。
Probably one of the best ways to prevent nsitive data from being expod is by making sure to encrypt all nsitive data at rest.
牛排饭防⽌暴露敏感数据的最佳⽅法之⼀可能是确保对静态的所有敏感数据进⾏加密。
4. XML外部实体 (4. XML External Entities)
XML External Entities (XXE) is a type of attack against an application that pars XML input. Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be ud to disclo internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of rvice attacks.
XML外部实体(XXE)是对解析XML输⼊的应⽤程序的⼀种攻击。 许多较旧的或配置不当的XML处理器都会评估XML⽂档中的外部实体引⽤。 外部实体可以使⽤⽂件URI处理程序，内部⽂件共享，内部端⼝扫描，远程代码执⾏和拒绝服务攻击来公开内部⽂件。
Most XXE vulnerabilities exist becau the application accepts XML directly or XML uploads—especially from untrusted sources—or inrts untrusted data into XML documents, which is then pard by an XML processor.
之所以存在⼤多数XXE漏洞，是因为该应⽤程序直接接受XML或XML上传(尤其是来⾃不受信任来源的XML)或将不受信任的数据插⼊XML ⽂档中，然后由XML处理器对其进⾏解析。
5.损坏的访问控制 (5. Broken Access Control)
Restrictions on what authenticated urs are allowed to do are often not properly enforced. Most of the time, urs have way too many permissions, which is asking for trouble.
通常，对⾝份验证⽤户允许执⾏的操作的限制通常未得到正确执⾏。 ⼤多数情况下，⽤户拥有太多权限，这很⿇烦。
Attackers can exploit the flaws to access unauthorized functionality or data, such as access to oth
er urs’ accounts, view nsitive files, modify other urs’ data, and change access rights.
攻击者可以利⽤这些缺陷来访问未经授权的功能或数据，例如访问其他⽤户的帐户，查看敏感⽂件，修改其他⽤户的数据以及更改访问权限。
Here’s a really good rule of thumb that you could u 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 en issue. This is commonly a result of incure default configurations, incomplete or ad hoc configurations, misconfigured HTTP headers, and verbo error messages containing nsitive information.
安全配置错误是最常见的问题。 这通常是由于默认配置不安全，配置不完整或临时，HTTP标头配置错误以及包含敏感信息的详细错误消息所致。
Not only must all operating systems, frameworks, libraries, and applications be curely configured, but they must be upgraded in a timely fashion.
不仅必须安全地配置所有操作系统，框架，库和应⽤程序，⽽且还必须及时升级它们。
To minimize the chances of curity misconfiguration, you should avoid installing or enabling unnecessary features. Also, avoid stack traces or other overly informative error messages to urs that can be revealed by error handling. And of cour, 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 ur-supplied data using a browr API that can create HTML or JavaScript. XSS allow
s attackers to execute scripts in the victim’s browr that can hijack ur ssions, deface websites, or redirect the ur to malicious sites.
跨站点脚本(XSS)是当今⽹络上最受欢迎的缺陷之⼀。 每当应⽤程序在未经适当验证或转义的情况下在新⽹页中包含不受信任的数据，或者使⽤可创建HTML或JavaScript的浏览器API⽤⽤户提供的数据更新现有⽹页时，都会发⽣XSS漏洞。 XSS允许攻击者在受害者的浏览器中执⾏脚本，这些脚本可以劫持⽤户会话，破坏⽹站或将⽤户重定向到恶意站点。
To prevent your website from being vulnerable to XSS attacks, you could u a framework that automatically escapes XSS by design, such as . And it’s always a good idea to escape untrusted HTTP request data bad on the context in the HTML output.
为了防⽌您的⽹站容易受到XSS攻击，您可以使⽤⼀个框架，该框架可以根据设计⾃动转义XSS，例如 。 并且，根据HTML输出中的上下⽂转义不受信任的HTTP请求数据始终是⼀个好主意。
8.不安全的反序列化 (8. Incure Derialization)
Exploiting derialization can be hard to pull off. This is becau off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code.
利⽤反序列化可能很难实现。 这是因为现成的漏洞利⽤程序在不对底层漏洞利⽤代码进⾏更改或调整的情况下极少起作⽤。
However, the risks are very high. Incure derialization often leads to remote code execution. Even if derialization flaws do not result in remote code execution, they can be ud to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
技术型处女但是，风险很⾼。 不安全的反序列化通常会导致远程执⾏代码。 即使反序列化缺陷不会导致远程执⾏代码，也可以将它们⽤于执⾏攻击，包括重播攻击，注⼊攻击和特权升级攻击。
闪闪的红星观后感There are a few things that you can do to prevent incure derialization. One of the things that you could do is implement an integrity check, such as digital signatures on any rialized objects. This prevents hostile object creation or data tampering.
您可以采取⼀些措施来防⽌不安全的反序列化。 您可以做的⼀件事是实施完整性检查，例如对任何序列化对象进⾏数字签名。 这样可以防⽌恶意创建对象或篡改数据。
Another thing that you could do is enforce strict type constraints during derialization before object creation. Note that bypass to this technique have been demonstrated, so reliance solely on this isn’t advisable.
您可以做的另⼀件事是在对象创建之前的反序列化期间强制执⾏严格的类型约束。 请注意，已经演⽰了绕过此技术的⽅法，因此建议不要完全依赖此技术。
You could also isolate and run code that derializes in low-privilege environments if possible. If that’s not possible, you could always log derialization exceptions and failures, such as where the incoming type isn’t the expected type.
如果可能，您还可以隔离并运⾏在低特权环境中反序列化的代码。 如果那不可能，您总是可以记录反序列化异常和失败，例如传⼊类型不是期望的类型。
9.使⽤具有已知漏洞的组件 (9. Using Components With Known Vulnerabilities)
This curity risk bugs me a lot. Some developers tend to u 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, su
ch an attack can facilitate rious data loss or rver takeover. Applications and APIs using components with known vulnerabilities may undermine application defens and enable various attacks and impacts.
它们全部以与应⽤程序相同的特权运⾏。 如果利⽤了易受攻击的组件，则此类攻击可能会导致严重的数据丢失或服务器接管。 使⽤具有已知漏洞的组件的应⽤程序和API可能破坏应⽤程序防御，并造成各种攻击和影响。
To minimize this risk, you should remove unud 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 curity bulletins.
为了最⼤程度地降低这种风险，您应该删除未使⽤的依赖项，不必要的功能和⽂件。 此外，您应该定期监视所有组件，以检查是否存在任何已知漏洞。 ⼀种简单的⽅法是订阅安全公告。
10.记录和监视不⾜ (10. Insufficient Logging and Monitoring)
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident respon, allows attackers to further attack systems. This can have huge conquences. 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 process or monitoring.
眉开眼笑的意思令⼈震惊的事实：⼤多数违规研究表明，检测到违规的时间超过200天，通常由外部各⽅⽽不是内部流程或监视来检测。
web应⽤程序安全与风险
