是否需要在web.config中保護連接字符串？

所以我使用SQL身份驗證在我的web.config中使用連接字符串。是否需要在web.config中保護連接字符串？

當然人們都說這可能是因爲你是明文存儲的密碼中的漏洞。

不過，據我所知，從來沒有IIS服務的web.config，和web.config中應該只具有讀取權限管理員和IIS反正。因此，如果黑客已經訪問了網絡服務器，那麼使用什麼加密並不重要，因爲私鑰將在網絡服務器上。

不會加密連接字符串通過混淆分類爲安全嗎？

是否值得加密web.config中的連接字符串和存儲在Web服務器上的私有密鑰？

而且，當然，如果我不使用SSL，我通過HTTP明文傳輸的連接字符串。如果我使用SSL，那麼這個問題也應該被緩解。

來源

2012-05-02 Dexter

我不會說在Web.config中存儲明文密碼本身就是一個安全漏洞。但是，加密密碼是一個有用的防禦縱深的措施，而不僅僅是安全透過朦朧：

如果IIS，配置到服務的Web.config？
如果在ASP.NET中發現了一個安全漏洞（如padding oracle vulnerability），允許任何人下載Web.config，該怎麼辦？
從完整的管理權限到服務器端代碼注入，對Web服務器的訪問程度有所不同。如果攻擊者只能管理後者，他可能會讀取Web.config，但可能無法訪問機器密鑰，尤其是在您的應用程序在部分信任下運行的情況下。

最終，由您決定在Web.config中存儲明文密碼的風險是否可以接受。當然，如果Windows身份驗證是一個選項，那麼您可能需要考慮使用它來代替SQL身份驗證。

UPDATE：在談到安全性，這是一個好主意，找出資產和威脅。在這種情況下，資產是數據庫中的敏感數據（如果數據不重要，那麼爲什麼還要用密碼來保護它）？威脅是攻擊者以某種方式訪問Web.config和數據庫的可能性以及。可能的緩解是在Web.config中加密數據庫密碼。

有多大的風險呢？我們是否真的必須計劃這樣一個天文罕見的事件？

此緩解措施已經證明其價值一次：發現ASP.NET填充oracle漏洞。任何在Web.config中存儲明文密碼的人都有風險;任何加密密碼的人都不是。你有多確定ASP.NET的另一個類似的漏洞在未來幾年將不會被發現？

我們是否應該加密源代碼並在運行時解密？對我來說似乎過度。

那麼，如果一個攻擊者確實可以訪問你的源代碼？你所保護的資產是什麼，你擔心的是什麼威脅？我認爲在很多情況下，源代碼的價值遠不如數據。（我在這裏想到的是任何人都可以獲得的現成的商業和開源軟件。）如果你的源代碼是有價值，也許混淆是一件需要考慮的事情。

我覺得如果他們已經有限訪問你的盒子，那麼你的主機已經失敗了，或者你已經安裝了易受攻擊的服務。

那麼ASP.NET或您的代碼中的安全漏洞呢？他們做不時彈出。

我擔心的是標準做法。這是一個標準嗎？

Microsoft has recommended加密連接字符串。

你應該做的是評估風險，即存儲明文密碼會：

的可能性有多大，攻擊者就能夠發現和利用暴露的Web.config中的安全漏洞？根據過去的歷史，我認爲可能性很低（但不是「天文學」低）。
您的數據有多重要或敏感？如果你存儲的只是你的貓的圖片，那麼攻擊者是否獲得你的數據庫密碼也許並不重要。但如果你存儲personally identifiable information，那麼從法律角度來說，我認爲你應該採取一切可能的措施來保護你的應用程序，包括加密你的連接字符串。

來源

2012-05-06 22:58:24

1.這是默認選項，您將不得不手動設置它。然後他們也可以訪問你的源代碼。我們是否也應該加密源代碼並在運行時解密？對我來說似乎過度。 3.我覺得如果他們已經有限的訪問權限，那麼你的主機已經失敗了，或者你已經安裝了易受攻擊的服務。 ----對我來說，加密你的web.config是通過混淆的安全。這將像我一樣，加密我的JavaScript以確保我的JavaScript源代碼（即使網頁瀏覽器可以讀取它）。我關心的是標準做法。這是一個標準嗎？ – Dexter

此外，它有多大的風險？人們通過網絡訪問整個ASP.net網站上的web.configs是否很常見？我的意思是，IIS可能會遭受無法恢復的錯誤，並意外地顯示web.config，因爲它正試圖讀取web.config並在短時間內顯示某個網站。我們是否真的必須計劃這樣一個天文罕見的事件？大多數PHP網站也使用某種settings.php或config.php來保護他們的數據庫密碼，並且只更改其讀取權限。他們不加密（甚至在生產服務器中）。 – Dexter

我試着在我更新的答案中解決您的問題。 –

我認爲這不是來自「外部」保護，而是來自「內部」。

有時，SQL管理員/用戶和操作系統管理員是不同的人。但操作系統管理員可以訪問所有文件，因此他可以輕鬆讀取web.config文件中的SQL憑據。但是這些證書可以以某種方式加密，甚至OS管理員也無法解密。

而且這是很難的「安全通過模糊」，因爲加密的連接字符串canno't不正確的用戶證書進行解密和usualy只有IIS「用戶」有一個。

來源

2012-05-02 15:58:51 Euphoric

如果某人是操作系統管理員，他們是不是有權訪問IIS用戶和用戶證書中包含的私鑰？通過混淆我似乎更像安全。我認爲這樣可以更好地保護那些只有對站點文件夾進行本地化FTP訪問的用戶（這樣他們纔有可能讀取web.config），而不是完全訪問Web服務器。 – Dexter

我不認爲有可能讀取證書。我不記得確切的程序，但我相信操作系統管理員不可能讀取加密。 – Euphoric

'aspnet_regiis -pd section' –

請考慮，如果生產密碼存在於web.config文件中，則任何有權訪問該文件的開發人員都可以訪問生產數據庫。當連接字符串中的用戶名具有對數據庫的讀/寫訪問權時，這尤其是個問題。然後，開發人員就可以「修復」那些沒有發生「修復」的記錄。

來源

2012-05-02 16:01:32

是的，我同意。我認爲這可以保護開發人員，使用FTP訪問的用戶，他們可能不被允許訪問/更改生產數據庫（並且沒有Web服務器管理員訪問權限）。這不是我特別關心的問題，因爲開發人員很少，而且經過審查。但絕對要討論的內容是正確的？ – Dexter

這也取決於您的行業是否以及如何監管。某些行業必須能夠證明其生產數據是安全的。 –

我遇到了一些人，他們認爲web.config很脆弱，可以通過「通過系統中的其他應用獲取訪問權限」來訪問。這讓我大惑不解，因爲如果他們有權訪問您的網絡服務器，那麼他們已經擁有了所有的源代碼---我們也加密了嗎？所以我確實認爲這是對已經擁有源代碼訪問權但不允許訪問數據庫的開發者的某種保護。我覺得這更像是一個主機問題而不是開發人員問題。 – Dexter

我曾經閱讀IHackStuff在線博客上的一些文章。這傢伙解釋了一些方法去真正有趣的方式使用谷歌搜索引擎鍵入的東西在搜索框，如：

filetype:config web.config -CVS

這想出了有關在生產服務器上緩存的web.config文件中多個結果，所有的信息這些文件可供公衆使用。考慮到這種可能性，我仍然會建議加密web.config數據庫訪問信息，只要這些信息足夠有價值。

來源

2012-05-02 16:11:37 CoderRoller

-1：對不起，我不相信你。嘗試通過IIS提供.config文件，你會看到。如果您認爲這是真的，那麼發佈一個帶有證明的鏈接。 –

https://svn.koolkraft.net/nblogr/tags/34/NBlogr.Web/Web.config – CoderRoller

ftp://202.120.107.88/incoming/WebSite1/Web.config – CoderRoller

你說得很對，web.config不會被ASP.NET送達給瀏覽器。但是開發人員很謹慎，所以當他們發佈一個新版本時，他們有時會將一個已知好的web.config複製到web.config.old或web.config.bak中。而且由於開發人員很懶，在發佈之後，他們忘記刪除舊的web.config，或者在需要回滾發佈的情況下讓它停留幾天。

現在，.old和.bak文件將提供給瀏覽器，這意味着很容易編寫腳本或工具來掃描這些文件並將它們下載到攻擊者，然後他們可以通過它們他們的閒暇時間尋找與用戶名和密碼的連接字符串，並突然從您的數據庫信用卡號碼流傳互聯網...

如果你不想進入命令行和RSA密鑰（坦率地說，你爲什麼？），看看this tool加密你的web.config。

來源

2012-05-02 16:26:47 PhilPursglove

爲什麼您需要使用標準.NET功能以外的任何其他擴展配置文件部分的功能，並讓它們在使用後自動解密？ –

是否需要在web.config中保護連接字符串？

回答

相關問題