■其他资料

https://blog.csdn.net/sxzlc/article/details/105202979

■分析对象code

・352

http://cwe.mitre.org/data/definitions/352.html

・693

http://cwe.mitre.org/data/definitions/693.html

・16

http://cwe.mitre.org/data/definitions/16.html

・296

http://cwe.mitre.org/data/definitions/296.html

・117

http://cwe.mitre.org/data/definitions/117.html

・80

http://cwe.mitre.org/data/definitions/80.html

・384

http://cwe.mitre.org/data/definitions/384.html

■352

https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers#xfo

Description

The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

web应用程序不能或不能充分验证提交请求的用户是否有意提供格式良好、有效、一致的请求。

CSRF攻击与防御

受害者
Bob 在银行有一笔存款，
通过对银行的网站发送请求http://bank.example/withdraw?account=bob&amount=1000000&for=bob2
可以使 Bob 把 1000000 的存款转到 bob2 的账号下。
通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，
并且该 session 的用户 Bob 已经成功登陆。黑客
Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。
Mallory 可以自己发送一个请求给银行：
http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。
但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码：
src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，
并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，
上述 url 就会从 Bob 的浏览器发向银行，
而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，
该请求会失败，因为他要求 Bob 的认证信息。
但是，如果 Bob 当时恰巧刚访问他的银行后不久，
他的浏览器与银行网站之间的 session 尚未过期，
浏览器的 cookie 之中含有 Bob 的认证信息。
这时，悲剧发生了，这个 url 请求就会得到响应，
钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。
等以后 Bob 发现账户钱少了，即使他去银行查询日志，
他也只能发现确实有一个来自于他本人的合法请求转移了资金，
没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

＝＝＝

・CSRF跨站点请求伪造(Cross—Site Request Forgery)

https://blog.csdn.net/xiaoxinshuaiga/article/details/80766369

＝＝＝

・cookie・session

https://blog.csdn.net/sxzlc/article/details/107971043

＝＝＝

■693

・Veracode関連

https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers#xfo

＝＝＝

・点击劫持 clickjacking （也被称为UI-覆盖攻击）

https://blog.csdn.net/qq_32523587/article/details/79613768

＝＝＝

・X-Frame-Options响应头配置详解

https://blog.whsir.com/post-3919.html

X-Frame-Options HTTP 响应头
是用来给浏览器指示允许一个页面可否在 <frame>, </iframe>或者 <object> 中展现的标记。
网站可以使用此功能，来确保自己网站的内容没有被嵌套到别人的网站中去，
也从而避免了点击劫持 (clickjacking) 的攻击

・X-Frame-Options响应头配置方法

服务级别的配置（Apache、IIS）

https://www.cnblogs.com/louby/p/10026052.html

＝＝＝

Description (说明)

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

本产品未使用或错误地使用了一种保护机制，该机制可对针对产品的定向攻击提供足够的防御。

Extended Description (扩展描述)

This weakness covers three distinct situations. A "missing" protection mechanism occurs when the application does not define any mechanism against a certain class of attack. An "insufficient" protection mechanism might provide some defenses - for example, against the most common attacks - but it does not protect against everything that is intended. Finally, an "ignored" mechanism occurs when a mechanism is available and in active use within the product, but the developer has not applied it in some code path.

这种弱点包括三种不同的情况。当应用程序没有定义针对某类攻击的任何机制时，就会出现“缺失”保护机制。一个“不充分”的保护机制可能提供一些防御措施——例如，针对最常见的攻击——但它并不能针对所有预期的攻击提供保护。最后，当一个机制可用并且在产品中正在使用，但是开发人员没有在某些代码路径中应用它时，就会出现“忽略”机制

Relationships (关系)

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

下表显示了与此弱点相关的弱点和高级别类别。这些关系被定义为ChildOf、ParentOf、MemberOf，并为可能存在于较高和较低抽象级别的类似项提供了见解。此外，PeerOf和CanAlsoBe等关系被定义为显示用户可能想要探究的类似弱点。

■16

Weaknesses in this category are typically introduced during the configuration of the software.

这一类的弱点通常是在软件配置过程中引入的。

・web安全：x-content-type-options头设置

https://blog.csdn.net/tivonalh/article/details/86310298

＝＝＝

・MIME

MIME(Multipurpose Internet Mail Extensions)多用途互联网邮件扩展类型。
是设定某种扩展名的文件用一种应用程序来打开的方式类型，
当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开。

"application/ecmascript"
"application/javascript"
"application/x-javascript"
"text/ecmascript"
"text/javascript"
"text/jscript"
"text/x-javascript"
"text/vbs"
"text/vbscript"

https://www.cnblogs.com/A2008A/archive/2012/06/26/2563613.html

＝＝＝

・MIME sniffing

　　https://www.cnblogs.com/yinlili/p/9887945.html

　　基于IE的MIME sniffing功能的跨站点脚本攻击

・MIME type confusion attacks

　　MIME 类型混淆攻击

・防止，MIME 类型混淆攻击

http://www.voidcn.com/article/p-fheiyjku-bbm.html

X-Content-Type-Options: nosniff

例如，我们即使给一个html文档指定Content-Type为"text/plain"，在IE8-中这个文档依然会被当做html来解析。

利用浏览器的这个特性，攻击者甚至可以让原本应该解析为图片的请求被解析为JavaScript。

通过下面这个响应头可以禁用浏览器的类型猜测行为：

X-Content-Type-Options: nosniff

■296

Description

The software does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.

软件不遵循或错误地遵循证书的信任链返回到受信任的根证书，从而导致对与该证书关联的任何资源的不正确信任。

Extended Description

If a system does not follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate.

如果系统没有遵循证书到根服务器的信任链，则证书将失去作为信任度量的所有有用性。从本质上讲，从证书中获得的信任来自一个信任链——在这个信任链的末尾有一个信誉良好的受信任实体。最终用户必须信任该信誉良好的来源，并且该信誉良好的来源必须通过证书的媒介为有关资源提供担保。

In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.

在某些情况下，这种信任会穿越多个相互担保的实体。最终用户信任的实体位于该信任链的一端，而持有证书的资源位于该链的另一端。如果用户在其中一个信任链的末端收到证书，然后只检查链中的第一个链接，则没有派生出真正的信任，因为必须将整个链遍历回受信任的源以验证证书。

There are several ways in which the chain of trust might be broken, including but not limited to:

Any certificate in the chain is self-signed, unless it the root.
Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate.
An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions.
The root certificate has been compromised or authorized to the wrong party.

有几种可能打破信任链的方式，包括但不限于：

・链中的任何证书都是自签名的，除非是根证书。

・并非所有中间证书都经过检查，从原始证书一直到根证书。

・一个中间的，CA签名的证书没有预期的基本约束或其他重要的扩展。

・根证书已被泄露或授权给错误的一方。

Relationships

■117

・log注入

https://blog.csdn.net/sxzlc/article/details/105202979

===

Description

The software does not neutralize or incorrectly neutralizes output that is written to logs.

软件不会中和或错误地中和写入日志的输出。

Extended Description

This can allow an attacker to forge log entries or inject malicious content into logs.

这使得攻击者能够伪造日志条目或将恶意内容注入日志中。

Log forging vulnerabilities occur when:

Data enters an application from an untrusted source.
The data is written to an application or system log file.

日志伪造漏洞出现在

1.数据从不受信任的源进入应用程序。

2.数据将写入应用程序或系统日志文件

Relationships

■80

・XSS攻击

https://www.cnblogs.com/shawWey/p/8480452.html

＝＝＝

Description

The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.

软件接收来自上游组件的输入，但它不会中和或错误地中和特殊字符，如“<”、“>”和“&”，这些字符在发送到处理网页的下游组件时可能被解释为web脚本元素。

Extended Description

This may allow such characters to be treated as control characters, which are executed client-side in the context of the user's session. Although this can be classified as an injection problem, the more pertinent issue is the improper conversion of such special characters to respective context-appropriate entities before displaying them to the user.

这可能允许将此类字符视为控制字符，在用户会话的上下文中在客户端执行。尽管这可以被归类为注入问题，但更相关的问题是在向用户显示这些特殊字符之前，将它们不当地转换为相应的上下文相关实体。

Relationships

■384

Description

Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

在不使任何现有会话标识符失效的情况下，对用户进行身份验证或以其他方式建立新的用户会话，使攻击者有机会窃取经过身份验证的会话。

代码安全_弱点（脆弱性）分析 CWE_20200807相关推荐

代码安全_弱点（脆弱性）分析 CWE
■CWE Common Weakness Enumeration 通用缺陷枚举 http://cwe.mitre.org/data/definitions/117.html 脆弱性(ぜいじゃくせい) ...
python函数增强代码可读性_如何提高代码的可读性学习笔记
本文整理自 taowen 师傅在滴滴内部的分享. 1.Why 对一线开发人员来说,每天工作内容大多是在已有项目的基础上继续堆代码.当项目实在堆不动时就需要寻找收益来重构代码.既然我们的大多数时间都花在 ...
软件安全与脆弱性分析-对于freenote小程序的Poc分析
最近上软件安全与脆弱性分析课程,对freenote小程序(貌似是某一年的CTF题)进行了依次Poc分析.感觉很有意思,在这里对分析过程进行一个总结. 1.程序功能介绍给定的程序运行界面如上图所示,大 ...
x264 代码重点详解详细分析
eg mplayer x264 代码重点详解详细分析分类: ffmpeg 2012-02-06 09:19 4229人阅读评论(1) 收藏举报 h.264codecflv优化initializ ...
高通Android智能平台环境搭建_编译流程分析
高通Android智能平台环境搭建_编译流程分析高通平台环境搭建,编译,系统引导流程分析 TOC \o \h \z \u 1. 高通平台android开发总结. 7 1.1 搭建高通平台环境开发环境 ...
20145307陈俊达_安卓逆向分析_Xposed的hook技术研究
20145307陈俊达_安卓逆向分析_Xposed的hook技术研究引言其实这份我早就想写了,xposed这个东西我在安卓SDK 4.4.4的时候就在玩了,root后安装架构,起初是为了实现一些屌 ...
脚本病毒分析扫描专题1-VBA代码阅读扫盲、宏病毒分析
1.Office Macor MS office宏的编程语言是Visual Basic For Applications(VBA). 微软在1994年发行的Excel5.0版本中,即具备了VBA的宏功 ...
手把手教你用Keras进行多标签分类（附代码）_数据派THU-CSDN博客 (翻译：程思衍校对：付宇帅)
手把手教你用Keras进行多标签分类(附代码)_数据派THU-CSDN博客手把手教你用Keras进行多标签分类(附代码)_数据派THU-CSDN博客
2016年大数据Spark“蘑菇云”行动代码学习之AdClickedStreamingStats模块分析
2016年大数据Spark"蘑菇云"行动代码学习之AdClickedStreamingStats模块分析系统背景:用户使用终端设备(IPAD.手机.浏览器)等登录系统,系 ...

代码安全_弱点（脆弱性）分析 CWE_20200807

■352

■693

■16

■296

■117

■80

■384

代码安全_弱点（脆弱性）分析 CWE_20200807相关推荐

最新文章

热门文章