題:
強制一次僅通過一個選項卡訪問一個網站是否可以獲得安全優勢?
d33tah
2015-12-28 20:36:45 UTC
view on stackexchange narkive permalink

我剛剛發現一家波蘭銀行的網站強迫用戶僅在一個瀏覽器標籤中打開它。例如,在尋找您要匯款的帳號時,您無法檢查轉賬歷史。除了可能的安全性原因,我無法想到這樣做的任何好的理由。將一個站點限制為一個站點是否有安全優勢?如果是這樣,他們是什麼?

如果您在新窗口(而不是標籤頁)中創建第二個會話,該怎麼辦?
我想沒關係,但是我沒有嘗試過。
他們如何執行?他們是否在每個點擊的鏈接中傳遞了新的ID?
@StackzOfZtuff:通常會有一個狀態ID(可以稱為頁面,屏幕,操作等)告訴您Web應用程序工作流程中的當前狀態(通常是單個URL,其中的內容由過量的Ajax腳本動態處理) 。如果您單擊一個選項或提交與當前狀態不符的表格,則該應用程序可能會產生假結果,顯示錯誤頁面或直接將您發送回首頁。
我大學的在線評分/註冊系統做同樣的事情,而且很煩人。我認為這樣做並不是出於任何安全原因,而是因為系統設計得很糟糕。 (除其他外,後退按鈕也不起作用。)
您無法提供銀行名稱的原因嗎?我有興趣進一步研究。
這讓我想起了一家公用事業公司,其網站禁止複制/粘貼。我想他們想要阻止人們將信息保存在桌面上的記事本文檔中,但是大多數情況下,這使我在嘗試使用密碼管理器時感到沮喪。
這是一個安全問題嗎?它在問一個相對主觀的問題(“是否合理”),問題文本中沒有提到安全性或任何相關主題。
由於該問題即將關閉,我改寫了該詞,以使其更加客觀和專注於安全性。我希望我這樣做的時候不會改變OP的初衷。
它通過將客戶吸引到其他網頁設計不受大腦損壞的銀行,極大地提高了安全性。
@NeilSmithline:謝謝,您正確閱讀了我的意圖。 :)
-1
尚未提及的原因之一可能是過分熱心的CSRF保護(實際上,您不需要為防止CSRF而為每個請求都需要一個新令牌,每次登錄或更改特權級別時都不需要一個新令牌)。但更有可能的是,這與最受支持的兩個答案所指出的技術棧有關。
@d33tah:您是否嘗試過通過兩個不同的瀏覽器同時打開兩個會話?它有效還是會使您的第一次會話無效?根據我的經驗,此方法行之有效,因為這是我在打開新標籤頁時所使用的實際解決方法,但是在後一種情況下,這可能表明您的銀行存在一些安全問題。
-1
更好的是-$ work的大腦損壞的錯誤跟踪系統,習慣是將多個標籤/窗口中的活動流混合在一起(如果有的話)。因此,如果打開錯誤1和錯誤2(以查看),然後單擊對錯誤1的編輯,則更改可能會在錯誤2中結束。或者,您可能會看到bug2的編輯窗口-但在有bug1的窗口中。
七 答案:
Lie Ryan
2015-12-28 20:57:31 UTC
view on stackexchange narkive permalink

通常,不,強制用戶使用單個選項卡是不合理的。沒有技術上的安全性原因可以使網站僅可用於單個選項卡。這通常是由於系統設計不佳而引起的。

強制使用單個選項卡還意味著註銷時,不會在其他20個選項卡中保留敏感信息。但是,這是一個很差的理由,因為一個受此困擾的網站可以在從一個選項卡註銷時使用localStorage或websocket同時清除所有選項卡。可能會故意將自己限制在一個標籤中。通過強制使用單個選項卡,您可以迫使人們一次只專注於一件事,這使您不太可能忘記某些事情。 IMO,這是一個糟糕的原因,因為弊大於利。

它們可能與安全性無關,但是有一個原因使Webapp能夠做到這一點。
謊言說,它的系統設計基本上很差。從用戶體驗的角度來看,如果人們被迫做什至沒有真正幫助的事情(例如獲得安全性),那就更糟了。
可以將此“強制單個選項卡”功能視為安全影院嗎?
@Mindwin:如果出於安全原因而提出“強制單個選項卡”,那麼是的,IMO,這是一個安全劇院。
我對此並不十分精通,但是是否有機會減少跨站點請求偽造?
我僅在私有選項卡上使用偽造的Facebook帳戶,而在正常瀏覽處於正常模式下時,這可以確保Facebook無法在私有選項卡之外跟踪我的操作,與其他網站的Cookie進行交互等等……但這僅適用於用於私人窗戶
就其價值而言,這並不是*總是*糟糕的系統設計。某些考試類型的頁面/應用程序可以在學校的Chromebook上使用,因此老師不必擔心學生在其他標籤中查找答案。不是OP發生了什麼,而是真實的事情。
@Ramrod可能與CSRF有關,因為每個選項卡的文檔將具有其自己的反CSRF令牌。如果Web服務器上的會話狀態僅跟踪單個令牌,則每個選項卡都會中斷另一個選項卡的工作。另一方面,這將再次回到較差的系統設計,因為一個人可以存儲令牌的集合併在使用後將其刪除。
我的印像是,使用Javascript,每個選項卡都能夠讀取另一個選項卡的內容,從而使潛在的惡意代碼訪問銀行選項卡的文檔。這不是真的嗎
-1
-1
@Blaisorblade啊,我想我誤會了-該站點允許您打開其他選項卡,而不是它本身的另一個副本?我所說的只是一個選項卡,側面沒有其他內容,因此沒有Wikipedia。
@Jefromi是的,不同的東西;這是由銀行網站完成的。值得慶幸的是,您瀏覽的一個網站無法阻止您打開其他選項卡-只有瀏覽器擁有該特權。
WhiteWinterWolf
2015-12-29 00:07:06 UTC
view on stackexchange narkive permalink

此限制不是由安全措施引起的,而僅僅是由經濟措施引起的。

您觀察到的這種行為實際上可以在許多內部公司Web應用程序中找到,並且您會發現它與很多鏈接在一起Java J2EE Web應用程序服務器(最流行的是IBM WebSphere Application Server)。

儘管依賴輕型客戶端(通用的Web瀏覽器),但這些應用程序的設計方式(通常)很差(通常)使用重客戶端(從安裝在計算機上的可執行文件運行的軟件)的客戶端。

網站通常在設計時考慮了請求-響應模型。設計者決定允許哪些請求給用戶,以及適當的服務器應進行什麼樣的處理和回答。由於每次瀏覽器僅向服務器發送請求時,這方便地使您可以打開任意數量的選項卡。

但是,面對的Web應用程序在其中設計了一種狀態轉換模型。

使用笨拙的客戶端軟件,您會被束縛在非常精確的工作流程中:單擊某個項目時,系統會建議您一些選項,並且您將不得不選擇其中之一或單擊取消按鈕(如果可用),您可能無法直接打開某些窗口而不先通過其他窗口或菜單,某些選項可能無法始終訪問或啟用,具體取決於您當前正在進行的操作動作等。

在任何時候,您都處於某種確定的狀態,根據對應用程序控件的操作,您將從當前狀態切換到另一種狀態,依此類推。應用程序設計人員可以很好地定義每個可能的狀態轉換。

此類Web應用程序僅採用最初為重型客戶端應用程序設計的開發模型,並將其應用於Web應用程序。顯然,這不能很好地擴展,因為通過打開多個選項卡,您使應用程序感到困惑,該應用程序無法確定您的當前狀態:您是在查詢帳戶餘額還是輸入新的銀行轉帳?兩者都不可接受,您一次只能處於一種狀態!而且我什至沒有提到瀏覽器的特定功能,例如後退按鈕或為特定頁面添加書籤,而這些Web應用程序通常不支持這些功能。

這不是安全的選擇,只是一種經濟的選擇,因為它使應用程序成為可能編程更容易,更快,因此更便宜。

我會爭辯說,至少在今天,這使應用程序編程更容易。也許在過去設計這些系統時確實如此,但是今天有無數的現代框架可用來幫助構建設計良好的RESTful Web應用程序。實際上,我懷疑嘗試使用像今天這樣的反模式來構建應用程序比構建無狀態應用程序“難”。
僅當您從現有的狀態繁重的客戶端應用程序中重用設計時,這樣的設計才會更便宜。在幾乎所有其他Web本機設計中,無狀態客戶端更易於構建,更快並且可擴展性更好。
@Ajedi32: J2EE Web應用程序是一個與傳統Web開發完全不同的世界。它累積了抽象層,您提供了一個用路徑鏈接的Java類,並且您的應用程序甚至無法訪問由應用程序服務器抽象的HTTP請求。我認為所有這些可能意味著在開發中將採用不同的方法。但是,我完全同意您的看法,在我看來,大多數情況下使用這樣的J2EE Webapp只是一個管理決定(可能不是最明智的決定),而且根本不是技術選擇,因為它通常會帶來更多問題比解決方案。
@LieRyan:我對Ajedi32的回答也適用。僅當您必須處理現有基礎結構時,才可以在公司基礎結構中構思這種選擇。如果您已經向IBM投入了大量資金來支持您的WebSphere平台,其中後端連接已經正常運行並受支持(JMS隊列,SAP集成等),那麼您可能希望重用它來實現新的Web界面,而不是從頭開始,即使這意味著使用更沉重和不切實際的技術,而不是使用更現代和用戶友好的技術。
+1它使具有某種思維方式的編碼人員(而不是一般而言)更容易編程。具有非Web受控客戶端背景的Java編碼人員會很高興在Session中填充大量狀態,而沒有意識到他們正在破壞“無狀態” Web自然提供的導航/可用性便利。它不是更安全(事實上,我已經看到它通過引入ToC / ToU問題而引起安全漏洞),但它更適合這種思維方式。由於對Web的熟悉程度,它一般都在撤退,但是您仍然可以在像銀行這樣的企業漏洞中看到它。
Rory Alsop
2015-12-30 04:31:50 UTC
view on stackexchange narkive permalink

我曾與8家以一種或另一種方式實施此功能的銀行合作,我確信這是一項重要的安全功能。它是一個選項卡無關緊要,但是限制一個實例對減少許多攻擊路徑很有幫助。

如果允許多個實例,那麼攻擊者就可能在有效會話期間從另一台計算機進行攻擊。如果您只允許一個,則將刪除大多數變體。

這些銀行實施該標記的一般方式是在協商新會話後檢查令牌/ Cookie並關閉存在的所有會話,不管是新標籤頁,瀏覽器還是其他任何內容。

評論不作進一步討論;此對話已[移至聊天](http://chat.stackexchange.com/rooms/33682/discussion-on-answer-by-rory-alsop-are-there-security-advantages-gained-from-for) 。
Filip Haglund
2015-12-29 03:07:44 UTC
view on stackexchange narkive permalink

有一家瑞典銀行正在這樣做。他們在每個請求上傳遞一個使用令牌,因此一個請求不能重複執行兩次。這意味著,如果有人設法竊取了您的會話cookie,那麼在沒有任何人注意的情況下他們將無法使用它。

這是對安全性的一小部分增加(由於SSL / TLS變得更好,因此如今可能甚至沒有增加),對用戶體驗的影響很大。

其他銀行(例如Klarna)使用單次點擊付款解決方案來極大地提升用戶體驗,但要確保它的安全則要艱鉅得多。

最終,銀行有責任進行此權衡,將用戶限制在一個選項卡可能會有所幫助,例如,降低了用戶忘記關閉 all 標籤。

JamesRyan
2015-12-29 00:16:22 UTC
view on stackexchange narkive permalink

如果這是一個有狀態的應用程序,則打開單獨的選項卡會使用戶感到困惑,因為一個選項卡中顯示的數據將不包含自另一個選項卡以來執行的任何操作。

這不是安全問題,但Web應用程序中常見的一種設計選擇,因為它允許更複雜的操作,而無需進行額外的工作即可使其成為無狀態。

我認為有狀態需要更多的工作,因為您必須跟踪狀態。現在,如果您想說某人可能會嘗試對過時的數據進行操作(例如,花雙倍的錢),那麼您的程序“必須”無論如何都要進行檢查,以防止惡意。用毯子覆蓋不良的設計不會使它變好。
SilverlightFox
2016-01-25 16:14:43 UTC
view on stackexchange narkive permalink

是的,儘管可以防止應用程序偶然在不同的選項卡中運行。

有一類Web應用程序漏洞,稱為“業務邏輯缺陷”。當需要遵循多步驟過程時,這些問題尤其普遍。通過為用戶提供令牌,令牌會逐頁傳遞,並在每個步驟中進行更改,從而確保用戶按照設置的順序執行多步驟過程。這樣可以減輕開發人員假定由於已經到達某個頁面而合法地遵循了所有先前的步驟的風險。

因為令牌是在GET或POST參數中從一個頁面傳遞到另一個頁面,所以打開另一個頁面在另一個選項卡中導致令牌被更改,因此原始選項卡中的令牌將不再對導航有效。

這種傳遞令牌的方法可以在會話服務器端進行驗證。還固有地可以防止CSRF。使用此方法保護整個站點還可以確保不會丟失任何內容,因為對於每個請求,都不會跳過令牌驗證。這也可以防止用戶雙擊例如。轉帳按鈕,因為令牌僅對第一個請求有效,並且將確保此類操作不會意外提交兩次。

m2kin2
2015-12-28 20:56:31 UTC
view on stackexchange narkive permalink

確實有幫助。您可能想看看道格拉斯·克羅克福德(Douglas Crockford)關於通過使用單獨的基於QT的渲染引擎來確保互聯網安全的建議。它有一些優點。

優點是:Web瀏覽器的dom和沙箱性質通過為每個頁面使用單獨的呈現引擎(假設我正確閱讀)而被廢止了,因此沒有如果發生Cookie盜竊,可能會通過多個選項卡出現dom或沙箱。

哦,這裡是鏈接: http://www.infoq.com/新聞/ 2015/07 / douglas-crockford-new-web-upgrad

瀏覽器中的選項卡仍與瀏覽器中的所有其他選項卡或窗口共享cookie存儲,歷史記錄等,從而可以進行CSRF之類的攻擊。將使用限制在單個選項卡上無濟於事,而是需要使用其他瀏覽器或至少使用其他瀏覽器配置文件。
將當前的瀏覽器限制為一個選項卡與修改網絡的工作方式有什麼關係?
@SteffenUllrich實際上,在私有選項卡上使用敏感網站只會提高安全性和隱私性,我僅在私有窗口上使用偽造的Facebook帳戶,這可確保Facebook與我在“常規”選項卡上所做的所有其他操作之間保持隔離
@Freedo:沒有私有選項卡,只有私有模式。此模式類似於其他瀏覽器配置文件,因為它不與原始配置文件共享任何cookie等。但是這些仍在私有模式下的不同選項卡之間共享。除此之外,問題是關於限製到單個選項卡(在正常瀏覽器模式內),而不是限制使用私有模式。
奇怪,我一直認為cookie仍然會從私人窗口中顯示。是的,我嘗試了一下,因此私有模式僅不在客戶端存儲歷史記錄。
我不知道為什麼克羅克福德享有如此高的聲譽。這是他的許多壞主意之一。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...