1. 前言

????????每年 OWASP（開放 Web 應(yīng)用程序安全項(xiàng)目）都會(huì)發(fā)布十大安全漏洞。它代表了對 Web 應(yīng)用程序最關(guān)鍵的安全風(fēng)險(xiǎn)的廣泛共識(shí)。了解十大WEB漏洞種類并善于在滲透測試中發(fā)現(xiàn)漏洞是安全行業(yè)人員的基本要求。

2. OWASP TOP 10

2.1 OWASP Top10 2022

1.失效的訪問控制
2.加密機(jī)制失效
3.注入
4.不安全的設(shè)計(jì)
5.安全配置錯(cuò)誤
6.易受攻擊和過時(shí)的組件
7.識(shí)別和認(rèn)證失敗
8.軟件和數(shù)據(jù)完整性故障
9.安全日志記錄和監(jiān)控失敗
10.服務(wù)器端請求偽造（SSRF）

2.2 OWASP Top10簡述

2.2.1 失效的訪問控制

????????訪問控制實(shí)施策略以防止用戶超出其指定權(quán)限范圍進(jìn)行操作。由于訪問漏洞，未經(jīng)身份驗(yàn)證或不受歡迎的用戶可能會(huì)訪問機(jī)密數(shù)據(jù)和進(jìn)程以及用戶權(quán)限設(shè)置。 元數(shù)據(jù)操作，包括篡改或重放 JSON Web 令牌 (JWT) 訪問控制令牌，或修改 cookie 或隱藏字段以提高權(quán)限或利用 JWT 失效，都是訪問控制漏洞的一個(gè)示例。第二個(gè)例子是違反默認(rèn)拒絕原則。必須僅向特定角色、能力或用戶授予訪問權(quán)限，但每個(gè)人都可以訪問。此類錯(cuò)誤可能使攻擊者可以輕松訪問他們想要的一切。 但是，可以通過應(yīng)用安全編碼方法并采取預(yù)防措施（例如禁用管理員帳戶和限制以及安裝多因素身份驗(yàn)證）來避免訪問安全機(jī)制不足以及身份或密碼管理問題。

????????其他預(yù)防技術(shù)包括：

? ? ? ? -僅強(qiáng)制執(zhí)行一次訪問控制機(jī)制，并在應(yīng)用程序期間重復(fù)使用它們，以減少跨域資源共享 (CORS)。
? ? ? ?-領(lǐng)域模型應(yīng)該施加不同的應(yīng)用程序業(yè)務(wù)限制約束。
? ? ? ?-限制對應(yīng)用程序編程接口 (API) 和控制器的訪問，以減輕自動(dòng)攻擊工具的影響。
? ? ? ?-在訪問控制中記錄故障并根據(jù)需要向管理員發(fā)出警報(bào)。
? ? ? ?-模型訪問控制必須強(qiáng)制執(zhí)行記錄所有權(quán)，而不是授予用戶創(chuàng)建、查看、修改或刪除任何信息的權(quán)限。

2.2.2 機(jī)密機(jī)制失效

????????這里的重點(diǎn)在于經(jīng)常暴露敏感數(shù)據(jù)的密碼錯(cuò)誤或缺少密碼錯(cuò)誤。以下是敏感信息泄露的典型例子

????????會(huì)話令牌
????????登錄 ID 和密碼
????????網(wǎng)上交易
????????個(gè)人信息（交換服務(wù)網(wǎng)絡(luò)或SSN、健康記錄等）
????????例如，應(yīng)用程序可以使用自動(dòng)數(shù)據(jù)庫加密來安全地加密信用卡數(shù)據(jù)。不幸的是，當(dāng)訪問此信息時(shí)，它會(huì)立即未加密，從而導(dǎo)致 SQL 注入錯(cuò)誤以明文形式提取信用卡信息，入侵者可能會(huì)利用這些信息。

可以使用以下預(yù)防技術(shù)來避免這些故障：

? ? ? ? -您應(yīng)該使用具有延遲因子的穩(wěn)健、加鹽和自適應(yīng)哈希算法來存儲(chǔ)密碼，例如 scrypt、Argon2、PBKDF2 或 bcrypt
? ? ? ? -傳輸敏感數(shù)據(jù)時(shí)應(yīng)避免使用文件傳輸協(xié)議 (FTP)和簡單郵件傳輸協(xié)議 (SMTP)等舊協(xié)議
? ? ? ? -建議實(shí)施經(jīng)過身份驗(yàn)證的加密，而不是僅僅使用加密
? ? ? ? -必須生成加密隨機(jī)密鑰并將其存儲(chǔ)為字節(jié)數(shù)組。如果使用密碼，則必須使用基于密碼的密鑰創(chuàng)建算法將其更改為類似于密鑰的東西

2.2.3?注入

注入（或SQL 注入）是針對網(wǎng)站的數(shù)據(jù)庫攻擊，該網(wǎng)站使用結(jié)構(gòu)化查詢語言 (SQL) 來獲取信息或執(zhí)行通常需要經(jīng)過身份驗(yàn)證的用戶帳戶的活動(dòng)。程序很難從自己的代碼中解釋這些代碼，從而允許攻擊者進(jìn)行注入攻擊以訪問受保護(hù)區(qū)域和偽裝成受信任用戶的敏感數(shù)據(jù)。注入包括SQL注入、命令注入、CRLF注入、LDAP注入等。

一些預(yù)防技術(shù)包括：

? ? ? ? -一個(gè)更可取的替代方案是使用完全避開解釋器、提供參數(shù)化 API 或易位到對象關(guān)系映射 (ORM) 工具的 API。
? ? ? ?- 建議使用積極的服務(wù)器端驗(yàn)證輸入。許多應(yīng)用程序，包括用于移動(dòng)應(yīng)用程序的文本字段和 API，都需要特殊字符。
? ? ? ? -在查詢中使用 LIMIT 和其他 SQL 約束是避免 SQL 注入情況下大量數(shù)據(jù)暴露的好方法。

2.2.4 不安全的設(shè)計(jì)

????????這是 2021 年的一個(gè)全新類別，專注于設(shè)計(jì)和架構(gòu)缺陷，需要更多地使用威脅建模、設(shè)計(jì)安全建議和參考架構(gòu)。不安全的設(shè)計(jì)是一個(gè)廣泛的類別，包含各種問題，例如“缺失或不充分的控制設(shè)計(jì)”。這并不意味著不安全的設(shè)計(jì)是所有其他十大風(fēng)險(xiǎn)類別的根源。

????????不安全的設(shè)計(jì)與不安全的實(shí)現(xiàn)不同。即使設(shè)計(jì)是安全的，實(shí)施缺陷也可能導(dǎo)致漏洞。另一方面，有缺陷的設(shè)計(jì)不能通過完美的實(shí)現(xiàn)來彌補(bǔ)，因?yàn)椴淮嬖诒匾陌踩Ｗo(hù)措施來防御特定的威脅。

????????可以通過采用以下預(yù)防技術(shù)來避免這些威脅：

? ? ? ? -在 AppSec 專家的協(xié)助下設(shè)置和使用安全的開發(fā)生命周期，以評估和構(gòu)建安全和隱私保護(hù)措施。
? ? ? ? -建議對關(guān)鍵驗(yàn)證、訪問控制、應(yīng)用程序邏輯和基本流程進(jìn)行威脅建模。
? ? ? ? -在用戶故事中包含安全術(shù)語和控制。
? ? ? ? -所有層級的租戶隔離設(shè)計(jì)也被視為一種實(shí)用的預(yù)防方法。

2.2.5?安全配置錯(cuò)誤

????????一般的安全設(shè)置問題，就像配置錯(cuò)誤的訪問控制一樣，通過為攻擊者提供對關(guān)鍵數(shù)據(jù)和站點(diǎn)區(qū)域的快速和輕松的訪問而造成重大危險(xiǎn)。

常見解決方案：

? ? ? ? -系統(tǒng)化的強(qiáng)化過程允許快速輕松地部署安全環(huán)境。開發(fā)、質(zhì)量控制和操作環(huán)境的配置應(yīng)該是相似的，具有不同的用戶權(quán)限。
? ? ? ? -它非常適合自動(dòng)化流程以建立新的安全環(huán)境，以節(jié)省必要的時(shí)間和精力。應(yīng)刪除或不安裝未使用的功能和框架。沒有不必要的功能、組件、文檔或演示的主要平臺(tái)會(huì)降低配置漏洞的可能性。

2.2.6 易受攻擊和過時(shí)的組件

????????一般的安全設(shè)置問題，就像配置錯(cuò)誤的訪問控制一樣，通過為攻擊者提供對關(guān)鍵數(shù)據(jù)和站點(diǎn)區(qū)域的快速和輕松的訪問而造成重大危險(xiǎn)。

常見解決方案：

? ? ? ? -系統(tǒng)化的強(qiáng)化過程允許快速輕松地部署安全環(huán)境。開發(fā)、質(zhì)量控制和操作環(huán)境的配置應(yīng)該是相似的，具有不同的用戶權(quán)限。
? ? ? ? -它非常適合自動(dòng)化流程以建立新的安全環(huán)境，以節(jié)省必要的時(shí)間和精力。應(yīng)刪除或不安裝未使用的功能和框架。沒有不必要的功能、組件、文檔或演示的主要平臺(tái)會(huì)降低配置漏洞的可能性。

2.2.7 識(shí)別和認(rèn)證失敗

????????現(xiàn)在包含與識(shí)別問題相關(guān)的 CWE。當(dāng)攻擊者獲取用戶信息、密碼恢復(fù)、ID 會(huì)話和其他登錄憑據(jù)時(shí)，就會(huì)產(chǎn)生安全問題。顧名思義，身份和身份驗(yàn)證失敗包括黑客利用此類漏洞利用身份驗(yàn)證不足。

????????如果應(yīng)用程序允許自動(dòng)攻擊，例如憑證填充（當(dāng)攻擊者可以訪問真實(shí)用戶和密碼列表）或預(yù)定義的、較弱的和常見的密碼（例如“Password1”或“admin/admin”），這些可能是身份驗(yàn)證缺陷的跡象

????????為避免此類缺陷，必須考慮以下預(yù)防措施：

? ? ? ? -必須在可行的情況下使用多因素身份驗(yàn)證，以避免自動(dòng)憑證填充、暴力攻擊和被盜憑證的重復(fù)使用。
? ? ? ? -通過對照包含 10,000 個(gè)最差密碼的數(shù)據(jù)庫檢查新密碼或修改密碼，可以提高密碼安全性。
? ? ? ? -對每個(gè)結(jié)果使用相同的消息有助于防止對密碼恢復(fù)、注冊和 API 路徑的帳戶枚舉攻擊。
不要安裝任何默認(rèn)憑據(jù)，尤其是對于管理用戶。

2.2.8 軟件和數(shù)據(jù)完整性問題

????????隨著越來越多的敏感信息存儲(chǔ)在數(shù)據(jù)庫中，容易受到安全漏洞的影響，數(shù)據(jù)完整性問題對于軟件來說變得至關(guān)重要。

????????這是一個(gè)新類別，它側(cè)重于假設(shè)軟件更新、重要數(shù)據(jù)和 CI/CD 程序的完整性，而無需對其進(jìn)行驗(yàn)證。一個(gè)例子是當(dāng)應(yīng)用程序使用來自內(nèi)容交付網(wǎng)絡(luò) (CDN) 或未經(jīng)授權(quán)的來源的擴(kuò)展、模塊或存儲(chǔ)庫時(shí)。未受保護(hù)的持續(xù)集成/持續(xù)交付 ( CI/CD ) 流程可能會(huì)增加惡意代碼、系統(tǒng)受損或未經(jīng)授權(quán)訪問的風(fēng)險(xiǎn)。

預(yù)防技術(shù)包括：

????????-人們可能會(huì)使用諸如數(shù)字簽名之類的措施來確認(rèn)數(shù)據(jù)或軟件來自預(yù)期的來源而沒有任何篡改。
????????-軟件供應(yīng)鏈的安全工具，如 OWASP CycloneDX 或 OWASP Dependency-Check，可用于保證組件不包含設(shè)計(jì)缺陷。
? ? ? ? -有必要確保 CI/CD 工作流具有所需的分段、訪問控制和參數(shù)化，以在整個(gè)設(shè)置和部署操作過程中保護(hù)代碼完整性。
? ? ? ? -未經(jīng)簽名或未加密的編譯數(shù)據(jù)不應(yīng)發(fā)送給不受信任的客戶端，除非已進(jìn)行完整性測試或數(shù)字簽名以識(shí)別數(shù)據(jù)更改或重復(fù)。

2.2.9 安全日志監(jiān)控和記錄失敗

????????在存在可疑行為和事件的情況下缺乏跟蹤可能會(huì)擴(kuò)大不受監(jiān)控的時(shí)間間隔，從而使安全漏洞被忽視的時(shí)間比使用更好的日志記錄的時(shí)間更長。此 OWASP Top 10 2021 部分旨在幫助識(shí)別、升級和解決最近的違規(guī)行為。如果沒有記錄和監(jiān)控，就不可能檢測到安全漏洞。

? ? ? ? -確認(rèn)所有身份驗(yàn)證、訪問安全系統(tǒng)和服務(wù)器端數(shù)據(jù)驗(yàn)證問題都記錄有足夠的用戶信息，以檢測可疑或欺詐帳戶，并存儲(chǔ)足夠長的時(shí)間以進(jìn)行延遲的全面調(diào)查。
? ? ? ? -確保以日志管理系統(tǒng)可使用的格式創(chuàng)建日志。
? ? ? ? -創(chuàng)建或應(yīng)用用于事件恢復(fù)和響應(yīng)工作的策略，例如 NIST 800-61r2 或更高版本。
? ? ? ? -確保對日志數(shù)據(jù)進(jìn)行適當(dāng)編碼，以避免對監(jiān)控系統(tǒng)的入侵或網(wǎng)絡(luò)威脅。

2.2.10 服務(wù)端請求偽造（SSRF）

????????該類別的結(jié)果顯示了高于平均水平的測試覆蓋率、合理的低發(fā)生率以及高于平均水平的影響和利用評級。SSRF 是在服務(wù)器端查詢未驗(yàn)證用戶提供的 URL 的情況下開發(fā)的。這允許攻擊者誘使應(yīng)用程序?qū)卧煺埱髠鬏數(shù)讲幌Ｍ奈恢?，即使該位置受到虛擬專用網(wǎng)絡(luò) (VPN)、防火墻或網(wǎng)絡(luò)訪問控制列表 (ACL) 的保護(hù)。

????????隨著新的在線應(yīng)用程序?yàn)樽罱K用戶提供方便的功能，獲取 URL 已成為一種典型情況。因此，SSRF 患病率正在增加。此外，由于云服務(wù)和設(shè)計(jì)復(fù)雜性，SSRF 的強(qiáng)度正在增加。考慮到這一點(diǎn)，可以通過采用以下預(yù)防技術(shù)來避免此類攻擊：

? ? ? ? -為了限制 SSRF 的影響，應(yīng)該將遠(yuǎn)程資源訪問功能分離到不同的網(wǎng)絡(luò)中。
? ? ? ?-安裝“默認(rèn)拒絕”防火墻設(shè)置或網(wǎng)絡(luò)訪問控制規(guī)則，以阻止除必需的內(nèi)部流量外的所有 Web 流量。
? ? ? ? -在 (TOCTOU) 情況下，為了防止 DNS 重新映射和“檢查時(shí)間、使用時(shí)間”等攻擊，最好注意 URL 的準(zhǔn)確性。

2.3 參考

Web 應(yīng)用程序的十大安全漏洞_web十大漏洞_crazy_itman的博客-CSDN博客

OWASP Top 10 2022介紹_世界盡頭與你的博客-CSDN博客

3. 一次WEB滲透測試的記錄

????????近期做了一個(gè)WEB滲透測試。對測出的問題在此做個(gè)概要的記錄。

1. 復(fù)制出有權(quán)限用戶的某URL，發(fā)現(xiàn)無權(quán)限的用戶登錄后，修改URL為剛剛復(fù)制內(nèi)容，發(fā)現(xiàn)竟然可以登錄。（失效的訪問控制）

2. 用客戶A的賬號登錄，使用搜索日志功能，使用postman修改HTTP請求里的賬號ID為客戶B的賬號，發(fā)現(xiàn)可以查看到B的日志。（失效的訪問控制）

3. 可以任意偽造jwt有效負(fù)載,發(fā)現(xiàn)報(bào)文可以BASE64解碼編碼，獲取"alg"所在花括號的解碼，明文中"alg"的值改為“none”，重新編碼為“ey****”，將jwt的報(bào)頭部分（Authorization）的value替換為“ey****”，jwt的有效載荷可以任意設(shè)置。（失效的訪問控制）

4. 使用一個(gè)角色id調(diào)用任何公共api。從響應(yīng)頭中獲取角色id。使用新角色id再次調(diào)用api，將新角色id放在請求頭中。結(jié)果將會(huì)改變。（失效的訪問控制）

5.?Public API的輸入客戶ID可以通過“customer - ID”頭注入。輸入標(biāo)頭在使用前未經(jīng)過驗(yàn)證。這是一個(gè)重要的數(shù)據(jù)泄漏問題。只有在檢索到客戶ID時(shí)，一個(gè)租戶才能調(diào)用公共api來獲取其他租戶的數(shù)據(jù)。（失效的訪問控制）

1. 準(zhǔn)備兩個(gè) tenants: tenant A and tenant B.
2. 使用 "cid": "A的cid" 調(diào)用 API? "https://....../audit/logs "
3. 在header里添加?“***-customer-id”: “B的cid”.
4. 成功獲得B的?audit log 信息.

6.?輸入標(biāo)頭在使用前未經(jīng)過驗(yàn)證。這是一個(gè)重要的數(shù)據(jù)泄漏問題。只要能檢索到客戶ID，一個(gè)租戶就能調(diào)用公共api來獲取其他租戶的數(shù)據(jù)。（失效的訪問控制）

1. 在header使用正確的uic_token調(diào)用 API? "http://......./notifications/counts"
2. 從響應(yīng)里獲取customer id
3. 將步驟2中獲得的customer id裝在header中可以調(diào)用API

7.攻擊者可以通過修改角色id獲得不同的角色權(quán)限。（失效的訪問控制）

????????1.使用一個(gè)角色id的權(quán)限調(diào)用api。

????????2.從響應(yīng)頭中獲取角色id。

????????3.使用新角色id再次調(diào)用api(從步驟2中獲取)，將新角色id放在請求頭中。權(quán)限將改變。

8.當(dāng)執(zhí)行查詢時(shí)沒有指定ui -令牌時(shí)，請求仍然可以被查詢出來。（失效的訪問控制）

Uic-token用于CSRF檢查，如果沒有指定此token，則可能存在CSRF攻擊

9.會(huì)話沒有正確終止。注銷后，會(huì)話仍然有效，可用于發(fā)出UI API請求。（識(shí)別和認(rèn)證失?。?/span>

1.?首先退出當(dāng)前會(huì)話。

2.?使用舊的cookie和ui令牌調(diào)用API ，請求仍然成功。

10.在調(diào)試模式下，密碼顯示在控制臺(tái)上（識(shí)別和認(rèn)證失?。?/span>

密碼為敏感信息;攻擊者獲取此密碼后可以直接登錄控制臺(tái)

????????1.以“無權(quán)限”角色登錄門戶。

????????2.打開鏈接https:// ....../#/admin/logs

????????3.打開調(diào)試模式，選擇console。???????

????????4.輸入一些關(guān)鍵字和“搜索”，它將顯示密碼在web控制臺(tái)。

11.在沒有cookie的情況下調(diào)用前端驗(yàn)證API，響應(yīng)將提示“x-account-id”丟失。如果不需要認(rèn)證，可以通過x-account-id頭設(shè)置賬號ID。（識(shí)別和認(rèn)證失?。?/span>

12.調(diào)用前端產(chǎn)品連接器API，在頁面中沒有使用的響應(yīng)中有令牌字段。憑證泄漏問題。（識(shí)別和認(rèn)證失敗）

13.可以刪除審計(jì)日志（不安全的設(shè)計(jì)）

黑客在進(jìn)行一些有風(fēng)險(xiǎn)的操作時(shí)，可能會(huì)刪除審計(jì)日志（DELETE https://......）。

14.攻擊者可以頻繁發(fā)送測試郵件;它可能會(huì)導(dǎo)致DOS和垃圾郵件。（不安全的設(shè)計(jì)）

????????通過“Camp Admin”啟動(dòng)門戶。進(jìn)入Accounts->Notifications，選擇一個(gè)項(xiàng)目，在1分鐘內(nèi)頻繁點(diǎn)擊“發(fā)送測試郵件”。

15.反射型跨站腳本（XSS）注入。（注入）

這是一個(gè)反射跨站腳本注入。XSS可以用來竊取易受攻擊的域中的cookie，并可能獲得對用戶身份驗(yàn)證會(huì)話的未經(jīng)授權(quán)訪問，更改/破壞易受攻擊的網(wǎng)頁的內(nèi)容，或者危害用戶的web瀏覽器。如果攻擊者修改請求中的時(shí)區(qū)字段，插入竊取cookie的JavaScript，如果他們設(shè)法讓受害者訪問他們的URL，就有可能獲得控制權(quán)。

????????1.在控制臺(tái)設(shè)置中，保存設(shè)置時(shí)。POST請求的有效負(fù)載中有一個(gè)字段的值可以用于注入

<script>alert(\"0\");</script>

16.Web應(yīng)用程序組件容易受到跨站點(diǎn)腳本(XSS)攻擊。（注入）

Web應(yīng)用程序組件容易受到跨站點(diǎn)腳本(XSS)攻擊。利用這個(gè)問題，攻擊者可以在應(yīng)用程序輸入?yún)?shù)中提供任意的客戶端站點(diǎn)代碼(JavaScript,VBScript等)，這些代碼最終將在最終用戶的Web瀏覽器中呈現(xiàn)和執(zhí)行。

info.html頁面很容易受到基于dom的鏈接注入的攻擊，當(dāng)點(diǎn)擊后會(huì)導(dǎo)致跨站攻擊。XSS可以用來竊取易受攻擊的域中的cookie，并在/破壞易受攻擊的網(wǎng)頁內(nèi)容或破壞用戶的web瀏覽器后，潛在地獲得對用戶身份驗(yàn)證會(huì)話的未經(jīng)授權(quán)的訪問。一種常見的策略是重新繪制受信任域上的易受攻擊頁面，以欺騙真實(shí)的會(huì)話超時(shí)和登錄頁面，從而獲取用戶密碼。

????????1.使用“Camp Admin”角色登錄門戶。、

????????2.登出門戶

????????3.輸入url https://********/info.html#/redirect?url=javascript:alert(0)，注入腳本

17.響應(yīng)的詳細(xì)信息可以顯示應(yīng)用程序的信息，這增加了發(fā)現(xiàn)任何現(xiàn)有漏洞的機(jī)會(huì)。（安全配置錯(cuò)誤）

響應(yīng)的詳細(xì)信息可以顯示應(yīng)用程序的信息，這增加了發(fā)現(xiàn)任何現(xiàn)有漏洞的機(jī)會(huì)。

調(diào)用API 時(shí)帶有錯(cuò)誤的body，響應(yīng)結(jié)果包含應(yīng)用程序詳細(xì)信息。

18.CSP頭未添加或未配置為安全值，這會(huì)將資源加載到不受信任的站點(diǎn)信息，從而導(dǎo)致XSS和其他相關(guān)漏洞。（安全配置錯(cuò)誤）

內(nèi)容安全策略(CSP)是一個(gè)附加的安全層，有助于檢測和減輕某些類型的攻擊。包括(但不限于)跨站腳本(XSS)和數(shù)據(jù)注入攻擊。這些攻擊被用于從數(shù)據(jù)竊取到網(wǎng)站污損或分發(fā)惡意軟件的所有事情。CSP提供了一組標(biāo)準(zhǔn)的HTTP標(biāo)頭，允許網(wǎng)站所有者聲明允許瀏覽器在該頁面上加載的內(nèi)容來源——涵蓋的類型包括JavaScript、CSS、HTML框架、字體、圖像和可嵌入對象

19.由于Web服務(wù)器上的跨域資源共享(Cross Origin Resource Sharing, CORS)配置錯(cuò)誤，Web瀏覽器可能無法加載數(shù)據(jù)。Access-Control-Allow-Origin: *對于敏感數(shù)據(jù)不安全。（安全配置錯(cuò)誤）

web服務(wù)器上的CORS錯(cuò)誤配置允許來自任意第三方域的跨域讀取請求，在該域中使用未經(jīng)身份驗(yàn)證的api。但是，Web瀏覽器實(shí)現(xiàn)不允許任意第三方從經(jīng)過身份驗(yàn)證的api讀取響應(yīng)。這在一定程度上降低了風(fēng)險(xiǎn)。這種錯(cuò)誤配置可能被攻擊者用來訪問以未經(jīng)身份驗(yàn)證的方式可用的數(shù)據(jù)，但這些數(shù)據(jù)使用了其他形式的安全性，例如IP地址白名單。

20. 沒有使用HSTS 安全策略（安全配置錯(cuò)誤）

HTTP嚴(yán)格傳輸安全(HSTS)是一種web安全策略機(jī)制，web服務(wù)器聲明遵守的用戶代理(如web瀏覽器)只使用安全的HTTPS連接(即HTTP層在TLS/SSL上)與它交互。HSTS是IETF標(biāo)準(zhǔn)跟蹤協(xié)議，在RFC 6797中指定。

缺少此標(biāo)頭將使web服務(wù)器處于可以用作普通HTTP流量的風(fēng)險(xiǎn)中。

21.每個(gè)人都可以把任何文件下載到服務(wù)器，它可能會(huì)替換文件并影響應(yīng)用程序，其他客戶可能會(huì)得到帶病毒的文件運(yùn)行。（安全配置錯(cuò)誤）

? ? ? ?1. 以“管理員”角色打開v1門戶。

????????2.從門戶找到get文件url。

????????3.使用PUT方法將任何文件發(fā)送到url，例如test.js。它可以用get方法獲取這個(gè)文件。

22.Http可以用來進(jìn)行API調(diào)用（安全配置錯(cuò)誤）

某API可以使用Postman發(fā)出http請求

在響應(yīng)頭中沒有“Strict-Transport-Security”頭。“Strict-Transport-Security”頭能限制站點(diǎn)只能使用HTTPS訪問，并且將來使用HTTP訪問它的任何嘗試都應(yīng)自動(dòng)轉(zhuǎn)換為HTTPS。

4.最后

????????WEB安全的主要類型每年都要較小的變化。熟練掌握最常見的WEB漏洞類型是滲透工作的展開的重要基礎(chǔ)。文章來源地址http://www.zghlxwxcb.cn/news/detail-430725.html

到了這里，關(guān)于WEB十大安全漏洞（OWASP Top 10）與滲透測試記錄的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！