我剛剛發現一家波蘭銀行的網站強迫用戶僅在一個瀏覽器標籤中打開它。例如,在尋找您要匯款的帳號時,您無法檢查轉賬歷史。除了可能的安全性原因,我無法想到這樣做的任何好的理由。將一個站點限制為一個站點是否有安全優勢?如果是這樣,他們是什麼?
我剛剛發現一家波蘭銀行的網站強迫用戶僅在一個瀏覽器標籤中打開它。例如,在尋找您要匯款的帳號時,您無法檢查轉賬歷史。除了可能的安全性原因,我無法想到這樣做的任何好的理由。將一個站點限制為一個站點是否有安全優勢?如果是這樣,他們是什麼?
通常,不,強制用戶使用單個選項卡是不合理的。沒有技術上的安全性原因可以使網站僅可用於單個選項卡。這通常是由於系統設計不佳而引起的。
強制使用單個選項卡還意味著註銷時,不會在其他20個選項卡中保留敏感信息。但是,這是一個很差的理由,因為一個受此困擾的網站可以在從一個選項卡註銷時使用localStorage或websocket同時清除所有選項卡。可能會故意將自己限制在一個標籤中。通過強制使用單個選項卡,您可以迫使人們一次只專注於一件事,這使您不太可能忘記某些事情。 IMO,這是一個糟糕的原因,因為弊大於利。
此限制不是由安全措施引起的,而僅僅是由經濟措施引起的。
您觀察到的這種行為實際上可以在許多內部公司Web應用程序中找到,並且您會發現它與很多鏈接在一起Java J2EE Web應用程序服務器(最流行的是IBM WebSphere Application Server)。
儘管依賴輕型客戶端(通用的Web瀏覽器),但這些應用程序的設計方式(通常)很差(通常)使用重客戶端(從安裝在計算機上的可執行文件運行的軟件)的客戶端。
網站通常在設計時考慮了請求-響應模型。設計者決定允許哪些請求給用戶,以及適當的服務器應進行什麼樣的處理和回答。由於每次瀏覽器僅向服務器發送請求時,這方便地使您可以打開任意數量的選項卡。
但是,面對的Web應用程序在其中設計了一種狀態轉換模型。
使用笨拙的客戶端軟件,您會被束縛在非常精確的工作流程中:單擊某個項目時,系統會建議您一些選項,並且您將不得不選擇其中之一或單擊取消按鈕(如果可用),您可能無法直接打開某些窗口而不先通過其他窗口或菜單,某些選項可能無法始終訪問或啟用,具體取決於您當前正在進行的操作動作等。
在任何時候,您都處於某種確定的狀態,根據對應用程序控件的操作,您將從當前狀態切換到另一種狀態,依此類推。應用程序設計人員可以很好地定義每個可能的狀態轉換。
此類Web應用程序僅採用最初為重型客戶端應用程序設計的開發模型,並將其應用於Web應用程序。顯然,這不能很好地擴展,因為通過打開多個選項卡,您使應用程序感到困惑,該應用程序無法確定您的當前狀態:您是在查詢帳戶餘額還是輸入新的銀行轉帳?兩者都不可接受,您一次只能處於一種狀態!而且我什至沒有提到瀏覽器的特定功能,例如後退按鈕或為特定頁面添加書籤,而這些Web應用程序通常不支持這些功能。
這不是安全的選擇,只是一種經濟的選擇,因為它使應用程序成為可能編程更容易,更快,因此更便宜。
我曾與8家以一種或另一種方式實施此功能的銀行合作,我確信這是一項重要的安全功能。它是一個選項卡無關緊要,但是限制一個實例對減少許多攻擊路徑很有幫助。
如果允許多個實例,那麼攻擊者就可能在有效會話期間從另一台計算機進行攻擊。如果您只允許一個,則將刪除大多數變體。
這些銀行實施該標記的一般方式是在協商新會話後檢查令牌/ Cookie並關閉存在的所有會話,不管是新標籤頁,瀏覽器還是其他任何內容。
有一家瑞典銀行正在這樣做。他們在每個請求上傳遞一個使用令牌,因此一個請求不能重複執行兩次。這意味著,如果有人設法竊取了您的會話cookie,那麼在沒有任何人注意的情況下他們將無法使用它。
這是對安全性的一小部分增加(由於SSL / TLS變得更好,因此如今可能甚至沒有增加),對用戶體驗的影響很大。
其他銀行(例如Klarna)使用單次點擊付款解決方案來極大地提升用戶體驗,但要確保它的安全則要艱鉅得多。
最終,銀行有責任進行此權衡,將用戶限制在一個選項卡可能會有所幫助,例如,降低了用戶忘記關閉 all 標籤。
如果這是一個有狀態的應用程序,則打開單獨的選項卡會使用戶感到困惑,因為一個選項卡中顯示的數據將不包含自另一個選項卡以來執行的任何操作。
這不是安全問題,但Web應用程序中常見的一種設計選擇,因為它允許更複雜的操作,而無需進行額外的工作即可使其成為無狀態。
是的,儘管可以防止應用程序偶然在不同的選項卡中運行。
有一類Web應用程序漏洞,稱為“業務邏輯缺陷”。當需要遵循多步驟過程時,這些問題尤其普遍。通過為用戶提供令牌,令牌會逐頁傳遞,並在每個步驟中進行更改,從而確保用戶按照設置的順序執行多步驟過程。這樣可以減輕開發人員假定由於已經到達某個頁面而合法地遵循了所有先前的步驟的風險。
因為令牌是在GET或POST參數中從一個頁面傳遞到另一個頁面,所以打開另一個頁面在另一個選項卡中導致令牌被更改,因此原始選項卡中的令牌將不再對導航有效。
這種傳遞令牌的方法可以在會話服務器端進行驗證。還固有地可以防止CSRF。使用此方法保護整個站點還可以確保不會丟失任何內容,因為對於每個請求,都不會跳過令牌驗證。這也可以防止用戶雙擊例如。轉帳按鈕,因為令牌僅對第一個請求有效,並且將確保此類操作不會意外提交兩次。
確實有幫助。您可能想看看道格拉斯·克羅克福德(Douglas Crockford)關於通過使用單獨的基於QT的渲染引擎來確保互聯網安全的建議。它有一些優點。
優點是:Web瀏覽器的dom和沙箱性質通過為每個頁面使用單獨的呈現引擎(假設我正確閱讀)而被廢止了,因此沒有如果發生Cookie盜竊,可能會通過多個選項卡出現dom或沙箱。
哦,這裡是鏈接: http://www.infoq.com/新聞/ 2015/07 / douglas-crockford-new-web-upgrad