保護網站管理部分的最佳做法是什麼？

我想知道人們認爲保護網站管理部分的最佳做法，特別是從認證/訪問的角度來看。保護網站管理部分的最佳做法是什麼？

當然有很明顯的事情，比如使用SSL和記錄所有訪問，但我想知道以上這些基本步驟人們認爲要設置欄。

例如：

你只是依靠您使用普通用戶相同的認證機制？如果不是，什麼？
你是否在同一個'應用程序域'中運行管理部分？
你採取什麼步驟使管理部分未被發現？（或者你拒絕了整個「默默無聞」的事情）

到目前爲止，從應答者的建議包括：

介紹人造服務器端暫停到每個管理員密碼檢查防止蠻力攻擊[開發人員藝術]
使用單獨的登錄頁面爲用戶和管理員使用相同的數據庫表（阻止XSRF和會話竊取授予訪問管理區域s）[Thief Master]
也考慮將webserver本機認證添加到管理區域（例如，通過的.htaccess）[盜賊大師]
考慮一些失敗的管理員登錄嘗試[盜賊法師]後阻止用戶IP
添加驗證碼失敗後，管理員的登錄嘗試[盜賊大師]
爲用戶和管理員提供同樣強大的機制（使用上述技術）（例如，不要專門對待管理員）[Lo'oris]
考慮二級認證（例如客戶端證書，智能卡，紙牌空間等）。）[JoeGeeky]
只允許從受信任的IP /域訪問，將檢查添加到基本HTTP管道（通過例如HttpModules）如果可能的話。 [JoeGeeky]
[ASP.NET]鎖定下來的IPrincipal &校長（使他們不變的，不可枚舉）[JoeGeeky]
盟員權利提升 - 例如在任何管理員權限升級時向其他管理員發送電子郵件。 [JoeGeeky]
考慮管理員的細粒度權限 - 例如，而不是基於角色的權利，爲每個管理員的個別操作定義權限[JoeGeeky]
限制創建管理員 - 例如，管理員不能更改或創建其他管理員帳戶。爲此，請使用鎖定的「superadmin」客戶端。[JoeGeeky]
考慮客戶機端的SSL證書，或RSA類型密鑰卡（電子令牌）[丹尼爾Papasian]
如果使用用於驗證餅乾，使用單獨的Cookie用於管理和正常的網頁，通過例如將管理部分放在不同的域中。 [Daniel Papasian]
如果可行，請考慮將管理站點保留在私有子網上，不在公共互聯網上。 [約翰Hartsock]
補發認證/會話票據的網站[理查德JP勒岡]的管理員/正常使用環境之間移動時

來源

2010-05-17 UpTheCreek

只是一個想法，但。保護管理員部分的最佳方式可能不在於公共互聯網上。您可以選擇僅將管理站點保留在私有子網上。 – 2010-05-27 20:44:27

您指定的這些想法中哪一個適用於所有用戶而不僅僅是管理員？ – 2010-05-28 16:59:18

您可能想要在http://www.webloginproject.com/上檢查WebLoginProject，它是一個基於XSS，SQL注入，會話修復和CSRF漏洞的安全設計的協作登錄系統。它有ASP和PHP的源代碼，它是多語言的，看起來很酷。許多開發人員正在研究它的固定孔，以便它可以儘可能地保證安全。 – stagas 2010-05-31 11:32:06

這些都是很好的答案......我通常喜歡爲我的管理部分添加幾個額外的圖層。雖然我用一個主題有一些變化，他們一般包括下列之一：

第二級驗證：這可能包括客戶端證書，智能卡，CardSpace的，等等（出X509證書。） ...
域名/ IP限制：在這種情況下，只有來自可信/可驗證域的客戶端;如內部子網;被允許進入管理區域。遠程管理員通常會經過可信的VPN入口點，因此他們的會話可以驗證，並且通常也使用RSA密鑰進行保護。如果您使用的是ASP.NET，那麼您可以通過HTTP模塊輕鬆地在HTTP管道中執行這些檢查，從而防止您的應用程序在安全檢查不滿意時收到任何請求。
鎖定IPrincipal &基於主體的授權：創建自定義原則是一種常見的做法，但常見的錯誤是使它們可修改和/或權利可枚舉。雖然它不僅僅是一個管理問題，但更重要的是，用戶可能會提高權限。確保它們是不可變的，而不是可枚舉的。此外，請確保所有授權評估均基於委託人。
Federate Rights Elevation：當任何帳戶收到選定數量的權限時，所有管理員和安全官員將立即通過電子郵件得到通知。這確保瞭如果攻擊者提升我們立即知道的權利。這些權利通常圍繞特權，查看隱私保護信息的權利和/或財務信息（例如信用卡）。
謹慎發佈權限，甚至管理員：最後，對於某些商店來說，這可能會更先進一些。授權權利應儘可能謹慎，並應圍繞真實的功能行爲。典型的基於角色的安全（RBS）方法傾向於有一個組心態。從安全角度來看，這不是最好的模式。而不是'羣組'''像'用戶管理器'，嘗試進一步分解（例如創建用戶，授權用戶，提升/撤銷訪問權限等...）。這在管理方面可能會有一些額外的開銷，但是這使您可以靈活地分配更大的管理員組實際需要的權限。如果訪問受到威脅，至少他們可能無法獲得所有權利。我喜歡用.NET和Java支持的代碼訪問安全（CAS）權限來封裝它，但這超出了本答案的範圍。還有一件事...在一個應用程序中，管理員無法管理更改其他管理員帳戶，或使用戶成爲管理員。這隻能通過一個只有幾個人可以訪問的鎖定客戶端來完成。

來源

2010-05-17 18:15:19 JoeGeeky

有良好的管理員密碼。

不是"123456"而是一串足夠長的字母，數字和特殊字符，比如15-20個字符。像"ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"。

爲每個密碼檢查添加一個暫停以防止強力攻擊。

來源

2010-05-17 10:09:56

你能解釋一下'暫停'會是什麼？你是否指的是像Thread.Sleep（5000）這樣的東西殺死一些時間？ – earthling 2010-05-25 18:17:04

@senloe：是的，只需添加一個仿真響應延遲即可限制每個時間間隔的嘗試次數。 – 2010-05-25 20:03:01

沒有任何效果。當其他請求睡眠時，您可以請求另一個密碼。 – 2010-05-31 11:46:57

如果網站需要登錄常規活動和管理員，例如一個論壇，我會使用單獨的登錄使用相同的用戶數據庫。這確保了XSRF和會話竊取不會允許攻擊者訪問管理區域。

此外，如果管理部分位於單獨的子目錄中，使用Web服務器的身份驗證（例如，Apache中的.htaccess）來保護該服務器可能是個好主意 - 那麼某人需要密碼和用戶密碼。

掩蓋管理路徑幾乎不會產生任何安全性收益 - 如果有人知道有效的登錄數據，他很可能也能夠找到管理工具的路徑，因爲他既可以通過它進行釣魚或鍵盤記錄，也可以通過社交工程獲得也可能會顯示出路徑）。

蠻力保護措施，例如3次登錄失敗後阻止用戶的IP，或者在登錄失敗後不需要第一次登錄（因爲這對於合法用戶來說非常煩人）也可能有用。

來源

2010-05-17 10:10:23 ThiefMaster

我拒絕默默無聞
使用兩種身份驗證系統，而不是一個是矯枉過正
嘗試之間人爲的暫停應該爲用戶提供太多
阻斷失敗嘗試的IP地址應該爲用戶提供太多
用戶也應該使用強密碼
如果您認爲驗證碼沒問題，您可以猜測，您可以將它們用於用戶

是的，寫完後，我意識到這個答案可以概括爲「沒有什麼特別的管理員登錄，他們都應該用於任何登錄的安全功能」。

來源

2010-05-17 11:15:55

感謝您的回答。就我個人而言，我傾向於不同意，例如：用戶是否喜歡「ksd83」，「4d＃rrpp0％27＆lq（go43 $ sd {3>'）等密碼並且不會重置有效用戶觸發的IP塊健忘會生成不必要的管理員/客戶服務工作？個人而言，我認爲不同級別的風險證明了不同的方法 – UpTheCreek 2010-05-17 11:22:42

管理員密碼應該是複雜的，但不能過於複雜，否則即使管理員也不會記住它並將它記下來會迫使他違抗每條安全規則）。暫時阻止嘗試失敗的IP是非常標準的，vbulletin可以做到這一點，phpbb做到了這一點，用戶習慣於這樣做。 – 2010-05-17 11:44:51

我真的不想看看phpbb或vbulletin的安全最佳做法;） – UpTheCreek 2012-03-27 14:12:38

這裏有一些其他的事情要考慮：

一個值得考慮的選擇，特別是如果你管理的管理員的電腦或者他們在技術上過硬，是使用基於客戶端身份驗證SSL證書什麼的。 RSA密鑰卡以及其他還可用於增加安全性。
如果您完全使用cookie - 可能是用於身份驗證/會話令牌 - 您可能希望確保cookie僅發送到管理頁面。這有助於通過盜取cookie，或通過第1/2層妥協或XSS來緩解網站帶來的風險。這可以通過讓管理部分位於不同的主機名或域以及使用cookie設置安全標誌來輕鬆完成。
通過IP進行限制也很聰明，而且如果您在整個互聯網上都有用戶，那麼您仍然可以執行此操作，前提是他們可以加入可信的VPN。

來源

2010-05-25 18:10:52

-2

這很大程度上取決於你想保護什麼樣的數據（法律要求等）。

很多建議都是關於驗證的。我認爲你應該考慮使用OpenId/Facebook身份驗證作爲登錄。（他們很可能會花費更多的資源在身份驗證安全性上）
保存更改以及更新數據庫中的值。您可以回滾從用戶X或日期X和Y

來源

2010-05-28 09:10:28

網站管理部分的Facebook驗證......你真的認爲這是個好主意嗎？對於一般用戶來說，是的......但是對於_admin section_？感覺對我有點危險...... – 2010-05-30 21:55:47

我不確定。但我認爲這個網站只運行openid身份驗證。我認爲facebook認證和openid之間沒有什麼大的差別。但我還沒有閱讀任何許可協議等。 – 2010-05-30 22:30:03

非常不好的想法openid管理員身份驗證，也回滾大部分時間是不可能的，壞人都準備好在你的系統內...什麼回滾？ – Aristos 2010-06-01 12:31:17

之間如果只能使用誰同時擁有普通用戶權限和管理員權限的用戶只需登錄改變這種方式，復興其會話標識符（是它在一個cookie或一個GET參數或任何其他......）至少在特權級別發生變化時...。

所以，如果我登錄，做一堆普通用戶的東西，然後訪問管理頁面，重新生成我的會話ID。如果我然後從管理頁面導航到普通用戶頁面，請再次重新生成我的ID。

來源

2010-05-30 22:10:54

你能解釋一下這個成就嗎？ – 2016-09-15 20:51:13

http://security.stackexchange.com/questions/1246/session-hijacking-regenerate-session-id – 2016-09-15 21:06:26

我相信這不會像你想象的那樣有幫助。因爲如果攻擊者能夠在普通用戶頁面中獲取當前會話ID，則可以使用它訪問管理頁面並生成新的會話ID。如我錯了請糾正我。 – 2016-09-15 21:15:46

-1

嚴格的方法是擁有兩個完全不同的「農場」，包括數據庫，服務器和所有服務器，並將數據從一個農場移動到另一個農場。大多數現代化的大型系統都使用這種方法（Vignette，SharePoint等）。它通常被稱爲具有不同階段的「編輯階段」 - >「預覽階段」 - >「交付階段」。這種方法可以讓你像處理代碼一樣對待content/config（dev-> qa-> prod）。

如果你不那麼偏執，你可以有一個單一的數據庫，但只有你的管理部分在「編輯」服務器上可用。我的意思是，只有編輯腳本/文件放在編輯服務器上。

當然，編輯階段只能在本地Intranet和/或使用VPN上使用。

這似乎有點矯枉過正，可能並不是所有使用案例中最簡單的解決方案，但它確實是最強健的做事方式。

請注意，諸如「擁有強大的管理員密碼」之類的內容很好，但仍然會讓您的管理員開放給各種各樣的聰明人。

來源

2010-05-31 19:25:07

我認爲這在純粹的CMS /發佈的情況下只會在你推送內容而不是處理數據方面有用/實用。 – UpTheCreek 2010-06-01 06:55:51

也許，但我已經知道（和看到）情況，這也是爲了處理和用戶輸入而完成的。對於具有單獨編輯服務器的單個農場來說，這是毫不費力的。對於多個農場，您所做的是將來自站點的輸入放入隊列（數據庫或其他數據庫）中，並使用外部過程處理並複製到「編輯」服務器/數據庫中。這使您可以更好地控制進入系統的內容。然而，實施起來很複雜。 – 2010-06-02 12:09:37

我們使用Windows Authentication進行管理訪問。這是保護管理區域的最實用方法，同時保持與適用於一般最終用戶的認證不同。系統管理員管理Admin用戶訪問憑證並對域用戶帳戶執行密碼策略。

來源

2010-06-01 12:38:03

-3

添加密碼字段和管理員知道的安全問題，例如，什麼是你的第一個女朋友的名字，或每次查看管理面板時隨機提問。

也許你總是可以將管理部分放在一個大目錄中，例如

http://domain.com/sub/sub/sub/sub/sub/index.php

但是，這並不是真正的好哈。

也許你可以包括在主頁查詢字符串，如：

http://domain.com/index.php?display=true

當它，用戶名和密碼字段將出現。

來源

2010-06-01 12:39:00 MacMac

-1

我沒有注意到任何人提到管理員密碼的存儲/驗證。請不要以純文本格式存儲PW，最好甚至不要使用可反轉的東西 - 使用類似salted MD5哈希的東西，這樣至少如果有人碰巧檢索到存儲的「密碼」，他們沒有任何非常有用的東西，除非他們也有你的鹽方案。

來源

2010-06-01 12:52:39

-1爲md5。你不需要密碼的快速散列，甚至超過md5ing的其他問題。 bcrypt將是更好的選擇。 – Kzqai 2011-12-28 16:26:43

保護網站管理部分的最佳做法是什麼？

回答

相關問題