■其他資料
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
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等關系被定義為顯示使用者可能想要探究的類似弱點。
■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
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等關系被定義為顯示使用者可能想要探究的類似弱點。
■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
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等關系被定義為顯示使用者可能想要探究的類似弱點。
■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.
在不使任何現有會話辨別符失效的情況下，對使用者進行身份驗證或以其他方式建立新的使用者會話，使攻擊者有機會竊取經過身份驗證的會話。