是的。這是一個問題，是一個大問題。最近，我在一家企業的網上商店中發現了一個設計缺陷，使我可以在其他訪問者的圖表中插入無辜的筆記。進一步發現，我還能夠在這些註釋中插入Javascript代碼（XSS）。因此，換句話說，我可以在每個訪問者的圖表上利用XSS。我做了一個快速PoC，向他們展示瞭如何使用該設計缺陷XSS，BeEF輕鬆地入侵任何訪問者的計算機（在本例中為PoC）

因此，即使是最小的缺陷也可能會帶來巨大的風險。

此外，誰說發現的錯誤是該錯誤的唯一開發者。網站建立了？也許他還犯了很多其他錯誤。

報告是您最好的選擇-即使看起來不必要。

您的問題是：如果安全缺陷不會造成太大危害，是否可以接受？

如果由企業決定，答案是是同時了解後果。

您在做什麼被稱為風險評估。對於每種風險，您都必須在實例化時突出其對公司的後果。根據該評估，您（您=有權做出業務決定的人）有三種選擇：

• 您可以接受它-假設修復它的成本不值得後果
• ，您可以減輕：將其修復到可以接受後果的程度
• 您可以確保進行防範-有效地將風險轉移給其他人。

您可以想像，風險評估中有多個熱點。 / p>

第一個是對後果和可能性的評估。關於如何執行此操作的書籍和文章很多，最終，這是基於強烈的揮手和經驗。輸出結果從來都不像書中的那樣

發生這種情況的可能性為76％，這將使我們損失126,653€

，但是

好吧，我認為這是我們應該注意的風險

請注意，“後果”部分有時可以量化（利潤損失

除了風險評估的令人懷疑的理論方面之外，您還應該始終利用一個巨大的優勢：風險，必須以某種方式處理。

這不僅是一個背後失去其貴族名稱的地方，而且還是突出顯示信息安全工作應該去的地方的正確工具。它還可以提高您的知名度（沒有那麼多積極主動的案例可以提高知名度），並迫使您對重要和不重要的內容進行認真，深入，務實的研究。

我看到的使用這種簡單的密碼重置方案的問題是，它暗示了該平台中的其他漏洞。有缺陷的安全性概念很少如此孤立，只能發生一次，因為此類缺陷通常與開發人員有關安全性的做法有關。至少，我懷疑他們的內部登錄過程也可能受到相同的漏洞的影響，有可能使攻擊者訪問他們通常不應該訪問的數據庫，代碼和進程。

從那裡，則有可能修改服務器代碼以報告明文密碼或收集其他私人信息，並可能允許對其他系統進行攻擊。畢竟，即使是在2016年，儘管這樣做存在明顯的風險，但仍有許多人仍在使用與Facebook相同的銀行帳戶密碼。即使沒有，將暱稱與電子郵件地址相關聯也可能會使用戶面臨其他帳戶的風險；攻擊者知道的有關用戶帳戶的信息越多，他們越有可能利用其手段來破壞同一個人擁有的其他帳戶。

我至少建議您與網站所有者聯繫，看看他們是否將解決問題，如果沒有解決，除非絕對必要，否則請考慮不使用其應用程序。我還建議您將用戶帳戶中的電子郵件更改為未連接到您關注的電子郵件地址的一次性帳戶。我們不再處在一個可以假設顯然沒有細微缺陷再也不會在以後困擾我們的時代。

如果我正確地看到了這種情況，他們可以更改任何帳戶的電子郵件地址和密碼，然後啟動修復表單並通過郵件繼續進行修復過程。

支持團隊可能會假設電子郵件地址合法，可以與收件人交換敏感信息-如果是已知客戶，您甚至可以開始處理通過網站/郵件收到的訂單。

另一個問題可能是您是否可以訪問聯繫歷史記錄或維修訂單的歷史記錄？也許客戶將機密信息寫到了維修訂單中，甚至訂單的數量和類型都可以揭示其業務中的問題？

另一個問題可能是客戶電子郵件地址的大量垃圾郵件。如果我調用您的密碼重置一百萬次，它將向您的用戶發送一百萬封郵件，不僅會填充他們的收件箱，還會使您進入多個垃圾郵件過濾器列表中……在這方面，獲取服務器可能很麻煩

如果我只需要枚舉暱稱並可以重置所有帳戶密碼，DoS當然非常容易。

但是最大的問題是錯誤的感覺安全性

可能是我們忽視了當前存在的某個角度或問題。但是，即使現在沒有任何問題-如果有人決定明年在此頁面中實現新功能該怎麼辦？也許供客戶在線訂購/付款。 -您提供只能使用用戶名和密碼訪問的上下文，人們和開發人員將依賴於此。每個人都會認為“這是應用程序的安全部分，只能由客戶訪問，因此我可以X並依靠Y”。

如果應用程序實際上是公共可訪問的，則看起來應該是。如果應用程序看起來很安全，那麼它應該是安全的！

這裡有兩種觀點：

• 是用戶，是的，我很擔心，我會讓車主知道，並且我不會分享任何關於此的敏感信息網站。
• 作為網站所有者/開發人員，您有責任評估是否存在任何潛在的安全風險是否嚴重到值得我們努力的程度。並非每種風險都會嚴重到足以證明採取措施的合理性，可以根據發生的可能性，違反的影響以及控制風險所需的努力來判斷。

在這種情況下，您已經得到（猜測）：

• 嚴重性：低
• 可能性：中度
• 努力：低

因此他們可能應該為此做些事情；

在一般情況下，針對您的問題“如果沒有太多危害就可以接受安全漏洞，這是可以接受的。”從他們？” -是的，可以。您需要確定嚴重性/可能性/努力權衡是否值得解決問題。在許多情況下，“接受風險”是一個完全合理的反應。

作為一個極端的例子，“可以破壞強大的加密貨幣的外星人訪問地球”是我的業務面臨的風險。我選擇不控制該風險，因為它發生的可能性非常低，因此不值得。

這是一個好問題，不容易回答。

每個安全風險都只是一個風險。解決該風險需要權衡提議的解決方案的成本，混亂和風險危險。

針對您的特定問題，您擁有網站的“私有”部分，其中包含一些信息，但是訪問該網站的那部分人不會造成真正的傷害。您的安全漏洞還要求黑客必須知道每個密碼都重置為同一事物，以及該事物是什麼。

所以，現在，今天，您最大的風險是零或至少較低。

明天最大的風險是私有部分可能包含機密信息。

“修復”的成本似乎很小。特別是如果您已經郵寄了新的“固定”密碼。從本質上講，只需將密碼分配更改為隨機密碼即可，並且此問題現在已“修復”。可能不是最好的，但是更好。

因此，您的修復成本較低，但安全風險較低。您需要將其與業務需求進行權衡，並確定是否值得。

請記住，企業可能會使用該固定密碼。例如，支持人員可能已經受過訓練，可以重設密碼，然後在電話上告訴用戶新密碼，並與他們待在一起直到他們可以進入，然後幫助他們更改密碼。計算成本時，您需要考慮這一點。

我的工作：

當我發現錯誤或安全問題時，將其記錄下來，並估算要修復的開發成本。然後，我將其添加到列表中，並讓合適的人知道。它可能永遠不會從該列表中刪除，但我每年（或每6個月一次）與網站所有者一起查看該列表，並儘我所能解決問題。

由於存在這種風險，可能無法很快解決。我可以看到很多業務需求首先出現，沒關係。但是，至少它已經記錄在案，當有人告訴我他們想在網站的那部分放置“秘密”信息時，我可以告訴他們有關風險的信息。

注意這種類型的風險可能會導致其他類型的風險。編碼時，做出了錯誤的安全決策。應該檢查該站點是否有其他錯誤的決定。

請記住，作為開發人員，您可能比用戶更了解實際的安全風險。如果用戶發現其帳戶被劫持，則他們可能會認為未經授權的用戶可能會訪問比其實際能力更多的信息。即使實際上沒有暴露任何敏感信息，您的公司也可能會受到聲譽打擊。例如，如果用戶有一個競爭性公司試圖找出的新的革命性製造過程，該怎麼辦？如果需要維修新流程中使用的特殊設備並更改其電子郵件，則維修訂單可能使另一家公司了解其新流程是什麼。

聽起來很簡單修復，最終您將不得不進行評估，以查看風險是否值得修復它。

從客戶（在某種程度上被認為是受信任的）模擬合法用戶是發起基於社交工程的攻擊的好方法。

如果您控制電子郵件地址，那麼修復表格->電子郵件流程非常適合此操作。也許您可以購買一個類似的域名並更改電子郵件地址“ someone@domain.com”->“ someone@domain.ca”，該地址與“我剛剛轉移到我們的加拿大子公司，所以我沒有我的我”記錄，您能提醒我...嗎？”

如果您可以了解有關客戶/供應商歷史的一些信息，則可以進一步向客戶模仿供應商。經常這樣簡單地問：“幾個月前拜訪的服務工程師叫什麼名字？他們在特定問題上顯然很有幫助，但是我不在，我的同事與他們打交道。”

不是，如果用戶能夠訪問該網站，他將可以使用其暱稱（機密數據）來訪問某人的電子郵件，在某些國家，這足以迫使您通知所有用戶，表明有人能夠侵入數據庫，並且存在信息洩漏。 這既損害了信譽，也不利於提起訴訟。

因此，一般而言，安全漏洞是可以接受的，但可能不是可接受的安全漏洞。同樣，您的用戶可能會突然收到對所有此類垃圾郵件的開放，它們可能會突然開始通過電子郵件接收惡意軟件和垃圾郵件。

黑客總是樂於助人（對他們而言）使用他們發現的缺陷。您假設用戶身份不是關鍵信息，但如果是例如作弊網站，則可能是關鍵信息。另外，如果一個用戶正在積極宣傳某個教派/邪教怎麼辦，而突然間邪教成員可以發現自己的身份怎麼辦？如果洩露了纏擾者的受害者並由於纏擾者能夠再次找到他該怎麼辦？

在沒有警告用戶的情況下泄露身份是侵犯隱私的行為，因此要當心。缺陷應該得到修復，並在發現後立即進行風險分析。

例如，與允許某人訪問我的電子郵件地址相比，我希望刪除我所有的論壇帖子。

這取決於極端情況。

情況A-不用擔心！用您的話來說，對於可用數據並沒有太大的擔憂。如果它可能已經公開，並且整個安全設置只是一種營銷/忠誠度計劃，那麼就沒有太多需要在意的了。如果它是由沒有專門知識的人完成的，那麼它也可以解釋草率的程序。只要該人能正常完成工作，就可以了。

情況B-擔心！如果這僅是組織中某些部分情況的提示，則可能會發現更糟糕的安全漏洞。如果服務器對於企業至關重要，請首先考慮檢查備份是否正確，然後進行全面審核。

然後當然還有其餘的字母。