您所在的位置: 首頁 >
安全研究 >
安全通告 >
十大令人哭笑不得的漏洞
隨著漏洞賞金金額的提高,很多靠此為生的研究者竟發(fā)現(xiàn)了許多所謂的漏洞,今天我們就來看看十大令人哭笑不得的漏洞。
十、并發(fā)會話過多
Gmail和Facebook會話持續(xù)了數(shù)年,你可以同時從不同的設(shè)備訪問它們。如果Gmail和Facebook不想為用戶提供這種便利,則可以實施會話超時,以在用戶閑置五分鐘后將其注銷。
現(xiàn)在,設(shè)想一種情況,假如你需要提交匯款請求,而銀行要求你填寫一個包含十幾個不同輸入字段的在線表單。這樣你就要切換到另一頁以查找一些詳細(xì)信息,對它們進行三次驗證,然后僅檢查一下Reddit(全球很受歡迎的討論網(wǎng)站,它的訪問量已經(jīng)可以排進全球前十)。當(dāng)你最終決定提交表單時,會收到一條錯誤消息,表明你的會話不再有效。為此你必須重新填寫一遍,因為你只有這樣做,才能匯款。不過,這個過程會讓你極為不爽。
起初,會話超時可以阻止某些XSS的利用,但是你輸入密碼的次數(shù)越多,就可能會增加在惡意頁面上意外輸入密碼的機會。
九、無用的信息披露
有一些信息披露是無用的。除了牽強附會的假想場景之外,其他信息幾乎毫無用處,但仍然每天都有報道,我最喜歡的示例是"Server: Apache",這種不可思議的魯莽行為為無數(shù)黑客打開了后門。沒有人能猜到web服務(wù)器可能正在運行Apache,或者使用53種替代技術(shù)中的一種對其進行指紋識別。不幸的是,惡意的開發(fā)人員不允許你禁用它,因此你需要部署一個反向代理。
八、缺少rate-limit/ CAPTCHA
RateLimiter 從概念上來講,速率限制器會在可配置的速率下分配許可證,如果必要的話,每個acquire() 會阻塞當(dāng)前線程直到許可證可用后獲取該許可證,一旦獲取到許可證,不需要再釋放許可證。通俗的講RateLimiter會按照一定的頻率往桶里扔令牌,線程拿到令牌才能執(zhí)行,比如你希望自己的應(yīng)用程序QPS不要超過1000,那么RateLimiter設(shè)置1000的速率后,就會每秒往桶里扔1000個令牌。
雖然強制使用一次性密碼的影響是毀滅性的,但這并不意味著每個應(yīng)用程序終端都應(yīng)該限制來自一個IP的傳入連接的數(shù)量。如果請求只是在應(yīng)用程序上創(chuàng)建工作載荷,你真的想要修復(fù)它嗎?每個修復(fù)都需要關(guān)注、工程時間、測試時間,有時甚至?xí)胄碌穆┒?。沒有直接影響的速率限制(除了DOS)通常被排除在漏洞獎勵計劃之外,因為它沒有達(dá)到風(fēng)險與修復(fù)成本的閾值。
七、將CSV注入作為一個漏洞
早在2014年,CSV注入(CSV Injection)漏洞的發(fā)現(xiàn)者James認(rèn)為這是一種會造成巨大影響的攻擊向量。攻擊包含向惡意的EXCEL公式中注入可以輸出或以CSV文件讀取的參數(shù)。當(dāng)在Excel中打開CSV文件時,文件會從CSV描述轉(zhuǎn)變?yōu)樵嫉腅xcel格式,包括Excel提供的所有動態(tài)功能。在這個過程中,CSV中的所有Excel公式都會執(zhí)行。當(dāng)該函數(shù)有合法意圖時,很易被濫用并允許惡意代碼執(zhí)行。
但是,在跟蹤研究過程中,James發(fā)現(xiàn)了一個公式,如果受害者點擊多個可怕的警告,就會在Excel中執(zhí)行任意代碼。結(jié)果呢?幾乎所有具有CSV導(dǎo)出功能的站點都有此報告。
六、未指定組件中的CVE-XXXX未指定漏洞
根據(jù)你發(fā)現(xiàn)的易受攻擊的軟件版本來報告漏洞并沒有什么錯,但是你很容易被成千上萬的此類報告所困擾。在當(dāng)前條件下,它們中可能只有一小部分實際上是可利用的,或者它們可能根本不會被用戶看到。由于很難找到1%的可利用漏洞并正確確定優(yōu)先級,但這就需要公司付出很多成本。掃描已知漏洞通常只是第一步,真正的價值是通過報告經(jīng)過驗證的漏洞并具有清晰的利用載體來創(chuàng)造的。
五、不再具有威脅的XSS漏洞
XSS(cross-site scripting跨域腳本攻擊)攻擊是最常見的Web攻擊,其重點是“跨域”和“客戶端執(zhí)行”。有人將XSS攻擊分為三種,分別是:Reflected XSS(基于反射的XSS攻擊)、Stored XSS(基于存儲的XSS攻擊)、DOM-based or local XSS(基于DOM或本地的XSS攻擊)。
那些不再起作用的經(jīng)典XSS攻擊可以說是非??尚Φ穆┒?,比如document.write(location.pathname),document.write()是Javascript中對document.open()所開啟的文檔流操作的API方法。document.write()方法可以向HTML輸出流中插入你傳入的內(nèi)容,瀏覽器會按著HTML元素依次順序依次解析它們,并顯示出來。其中的路徑在現(xiàn)代瀏覽器中總是URL編碼的,如果內(nèi)容類型是純文本或json時會嗅探內(nèi)容。曾經(jīng)的IE可謂是漏洞百出,研究人員有很多技巧可以利用Internet Exploder。但是如今,除非用戶決定通過使用過時的Internet Explorer導(dǎo)航到URL來查看一些黃賭毒的非法網(wǎng)站,否則XSS攻擊漏洞可以說是毫無意義。不幸的是,這并不能阻止賞金獵人在他們的報告中把這些所謂的漏洞作為重要的一塊來研究。
四、缺少安全標(biāo)頭
標(biāo)頭是HTTP規(guī)范的一部分,在HTTP請求和響應(yīng)中定義消息的元數(shù)據(jù)。當(dāng)用戶通過客戶端瀏覽器訪問網(wǎng)站時,服務(wù)器使用HTTP響應(yīng)頭進行響應(yīng)。雖然HTTP消息通常由用戶讀取,但元數(shù)據(jù)僅由Web瀏覽器處理,并且自1.0版以來已包含在HTTP協(xié)議中。
在2021年,你不能只編寫:
將其保存到index.html,然后使用nginx的默認(rèn)配置進行索引。如果是這樣的話,那每天的漏洞報告可能會淹沒你,盡管CSP這樣的安全標(biāo)頭為你的網(wǎng)站提供了很好的附加保護,但它們不一定需要出現(xiàn)在每個頁面上。
三、標(biāo)簽釣魚(tabnabbing)
該攻擊手法是由Mozilla Firefox瀏覽器的界面及創(chuàng)意負(fù)責(zé)人Aza Raskin發(fā)現(xiàn)和命名的,tabnabbing可改變用戶瀏覽網(wǎng)頁的標(biāo)簽及接口,以誘導(dǎo)用戶輸入網(wǎng)絡(luò)服務(wù)的賬號與密碼。因此,Raskin將此手法稱為標(biāo)簽綁架(tabnapping),他指出當(dāng)使用者連上一個嵌有第三方script程序或Flash工具的網(wǎng)頁時,就會讓自己曝露于風(fēng)險中,因為相關(guān)的惡意軟件得以偵測使用者經(jīng)常使用或正在使用的網(wǎng)絡(luò)服務(wù),在用戶暫時離開該網(wǎng)頁后,該網(wǎng)頁內(nèi)容及網(wǎng)頁標(biāo)簽會悄悄地變身成為偽造的網(wǎng)絡(luò)服務(wù),并誘導(dǎo)用戶輸入個人信息。
逆向tabnabbing,會發(fā)現(xiàn)兩種類型。通過改變打開攻擊者控制的站點的頁面的URL來濫用 target=_blank,這樣做的目的是當(dāng)你關(guān)閉攻擊者控制的頁面時,騙你登錄釣魚網(wǎng)站。幸運的是,瀏覽器將通過默認(rèn)情況下使用noopener將window.opener設(shè)置為null來鏈接到target = _blank來緩解此漏洞。這意味著,再報告類似的漏洞已經(jīng)毫無意義了。
二、缺少httponly標(biāo)志
如果cookie設(shè)置了HttpOnly標(biāo)志,可以在發(fā)生XSS時避免JavaScript讀取cookie,這也是HttpOnly被引入的原因。但這種方式能防住攻擊者嗎?HttpOnly標(biāo)志可以防止cookie被“讀取”,那么能不能防止被“寫”呢?答案是否定的
根據(jù)研究者多年的跟蹤分析,他們觀察到了一種奇特的現(xiàn)象。當(dāng)一種安全措施像設(shè)置HTTP標(biāo)頭或cookie標(biāo)志一樣簡單時,它很快就會吸引很多狂熱愛好者,他們堅持認(rèn)為必須在任何可能的地方使用它。這樣造成的后果是他們認(rèn)為任何不采取這些措施的網(wǎng)站都肯定不安全。
目前可以肯定,旨在通過停止使用JavaScript來竊取會話cookie來緩解XSS的使用,這幾乎是無用的,因為cookie泄漏是一種復(fù)雜且不切實際的利用方法,攻擊者無論如何也不死盯著這一方法來發(fā)起攻擊。不幸的是,httponly標(biāo)志的粉絲并不知道這一點,他們也不認(rèn)識會話cookie,所以你最好將其應(yīng)用于每個cookie上,否則他們可能會憤怒。
這個漏洞報告除了對賞金獵人有用外,實際的防御價值幾乎可以忽略不計。
一、autocomplete=off設(shè)置失敗
autocomplete 屬性是 HTML5 中的新屬性,在input中autocomplete屬性是默認(rèn)開啟的。屬性值:on——默認(rèn),啟動自動完成;off——禁用自動完成。
input 的屬性autocomplete 默認(rèn)為on,其含義代表是否讓瀏覽器自動記錄之前輸入的值。很多時候,需要對客戶的資料進行保密,防止瀏覽器軟件或者惡意插件獲取到??梢栽趇nput中加入autocomplete="off" 來關(guān)閉記錄,系統(tǒng)需要保密的情況下可以使用此參數(shù)。研究人員跟蹤發(fā)現(xiàn),“autocomplete=off設(shè)置失敗”這個漏洞之所以會被漏洞賞金者視為重點發(fā)現(xiàn)對象,原因如下:
1.傳統(tǒng)觀點認(rèn)為,使用密碼管理器是實現(xiàn)超級安全的唯一密碼的唯一方法;
2.安全審核員聲稱應(yīng)通過設(shè)置autocomplete = off就可以阻止或禁止這種做法;
3.不同意可能會導(dǎo)致無法獲得PCI合規(guī)性;
4.瀏覽器供應(yīng)商不同意,因此所有主要瀏覽器都故意忽略此設(shè)置;
5.有些網(wǎng)站通過不使用type = password或禁用粘貼的方法來解決此漏洞;
那實際結(jié)果如何呢?大多數(shù)網(wǎng)站都把精力浪費在一個所有人都忽略的設(shè)置上,而安全問題沒有得到任何解決。
參考及來源:https://portswigger.net/research/notwasp-bottom-10-vulnerabilities-that-make-you-cry 嘶吼專業(yè)版