有一個Web應用程序捕獲服務器錯誤並將其報告給管理員，以便可以解決錯誤。這些錯誤是發生在較低級別，守護進程等等的結果。遠不及網頁層。偶爾，失敗的SQL語句會冒泡到錯誤頁面，從而暴露一些數據庫模式。在錯誤消息中暴露SQL架構會帶來哪些安全風險？
有報告頁面的URI和暴露出的錯誤之間沒有相關性。如果我理解正確，我認爲這意味着避免SQL注入的問題，因爲沒有用於注入的Web路徑，但想要確認。
誰可以訪問這些報告，也可以登錄到服務器本身和訪問相關數據庫中的用戶，所以如果我們真正想知道的模式是什麼，我們有辦法進行查看。
這種情況下是否存在安全風險？
我認爲，通行的做法是將錯誤消息記錄到一個集中的地方（可能是數據庫），並具有進行消毒是被顯示給用戶，以確保沒有敏感信息共享消息的例程。
不好的人可以使用有關係統的不可告人的目的，如SQL注入攻擊，服務器拒絕攻擊等知識
簡短的答案是，有沒有理由SQL錯誤應該曾經暴露給用戶，特別是如果這是一個Web應用程序前面的商業用戶。這就是爲什麼我們有「抓」和「扔」的原因。內部異常只應在調試過程中冒出來。否則，它應該保存在日誌中。
通常，我們應該監視日誌。如果您寧願等待客戶投訴（由於人員限制），您當然可以隨附與您的日誌相關的跟蹤號碼，以便說明問題的性質。
如果你在工作「我們在這裏的所有朋友」的環境中，那麼就應該通過錯誤信息可能暴露的模式沒有問題。但是你對安全性的擔憂已經表明情況並非如此。
真的嗎？我們抓住並拋出了這個目的？使用它們的場景是什麼？ –
首先，回答你的問題。
有總是安全風險。攻擊者有無用的數據。即使一個人不能在盤中出現某種攻擊情況，也並不意味着沒有風險。
接下來，介紹在Web前端顯示系統錯誤消息的想法。
正如其他人已經說過，它是在一般非常糟糕的主意。一個無辜的用戶不必看到這些技術細節，而只能看到一個廣義的錯誤頁面。讓他們向網頁訪問者透露的細節是一個錯誤。錯誤更好被修復。修正一個錯誤是一種更好的方案，而不是問Stack Overflow這個問題是否嚴重。
SQL注入漏洞可以利用一次性攻擊而無任何錯誤。 – Gumbo