使用JS檢測，你的Web系統真的安全嗎？

相關學習推薦：

你的Web系統真的安全嗎？

千里之堤，潰於蟻穴。

在Web系統中，一個小小的漏洞，往往能引發極其嚴重的後果。因此，Web安全是每個系統在設計、開發、運維時必須要重點考慮的問題。

現如今很多Web系統所採取的防禦措施是偏向於基礎和簡單的，往往只針對常見的安全漏洞做了防禦，比如：

• Csrf
• XSS
• Sql注入

等等。這些基礎的防禦措施是必須要做的，且實施的成本不高，但它們只是系統安全防禦中的基礎部分。很多開發人員在意識中認為做好這些就足夠應付大部分情況了，這種想法是非常危險的。實際上，除了這些基礎且標準化的漏洞，每個業務系統本身的業務邏輯也很有可能成為駭客攻擊的目標，一旦被抓到並攻破，那後果將是非常嚴重的。下面將列舉一些常見的業務邏輯漏洞，這些漏洞也是之前開發系統時踩過的坑，希望能對大家有所啟發。

對談憑證管理混亂

我們都知道HTTP本身是無狀態的，為了能讓瀏覽器和伺服器互相知道身份並信任對方，大部分web系統都是利用「token」這種約定的憑證來實現的，token會在使用者登入之後產生，並在使用者主動退出或者超過一段時間後失效。也就是說，請求帶上了相應的token，那麼伺服器端就能拿到token做相應的校驗，校驗通過則信任該請求並執行相關業務邏輯，如果沒帶、帶一個非法的或者過期的則認為不合法。這看上去並沒有什麼問，但實際的實現上可能暗藏漏洞。

來看兩個例子：

1.前端開發人員小明在寫使用者點選退出按鈕的邏輯時，只是單純的清空了cookie或者localstorage中的token值（token一般存這兩個地方），並沒有向後臺發起請求讓token在業務中過期失效。那這個token的有效性本質上違背了使用者的意圖，此時就存在非常大的風險。當使用者自發退出後，token仍然有效，假如該token被他人通過某種方式獲取並記錄下來，那他可以完美的回放使用者執行過的操作，比如更改使用者資訊，下單等。

2.在上面的例子中，我們有提到token是要設定過期的，合理的過期時間能有效降低風險。但後臺開發小哥也許在設定token過期的設定中，眼花加手抖，多打一位數，或者把單位理解錯，在S級單位上用了MS級的數值，那過期時間就會被設定的很長。對於登入之後就不喜歡主動退出或者長期掛著頁面的使用者就非常的危險。token在使用者長期不使用的情況下依然有效，如果被他人拿到token，也能幹很多的壞事。

校驗失效

檔案上傳應該是Web應用上比較常用的功能，比如上傳頭像，上傳檔案到網路硬碟等等。惡意使用者可能會在上傳的時候，上傳木馬、病毒、惡意指令碼等檔案，這類檔案在伺服器上被執行會帶來比較嚴重的後果。這種攻擊方式成本較低，比較容易被攻擊者利用。允許上傳的檔案型別越多，受攻擊的可能性就越大。當惡意程式被成功上傳後，可能被使用者下載，在使用者電腦上執行後使之中毒。也可能在伺服器上就執行惡意程式，造成伺服器被控制，進而伺服器癱瘓，資料丟失。

正常情況下，程式都會對檔案型別進行判斷，只允許我們認為合法的檔案上傳到伺服器。但是，這個判斷在一些web程式中，只在前端做了，在後端沒做。這就給攻擊者帶來了機會，攻擊者可以輕鬆的串改請求，從而實現非法檔案的上傳。

正確的做法應該是後端進行副檔名判斷、MIME檢測以及限制上傳檔案大小等限制來防禦。另外，可以將檔案儲存在一個與業務隔離的伺服器來防止惡意檔案攻擊業務伺服器導致服務不可用。

資料列舉

在登入系統，大部分系統會在使用者登入的時候判斷使用者是否存在，然後給出提示「該手機號未註冊」。如果這個邏輯是用一個單獨的介面做的，那麼就會存在被暴力列舉的風險。攻擊者可以通過該介面利用手機號碼庫進行請求列舉，識別出哪些手機號是在系統中註冊過的，給下一步暴力破解密碼帶來機會。

對於這個問題，建議是將該判斷放到登入驗證的介面中，並不返回明確的提示。你會看到做的好的網站上，一般會提示「該手機號未註冊或密碼錯誤」。雖然這在使用者體驗上打了折扣，但也更加的安全。

資料寫入重放

以一個論壇的發帖舉例，利用抓包工具抓取論壇發帖的請求過程，並通過該工具重放過程，會發現貼文列表出現了兩條一樣的貼文，這就是被重放攻擊了。如果加快重放頻率，不僅會在系統中產生很多的垃圾資料，還會因為頻繁寫入給業務資料庫帶來巨大壓力。

對於此類有重放風險的請求，建議加上請求頻率限制。比如，可以判斷兩個請求的時間戳，設定大於某個時間值才有效。

許可權漏洞

許可權校驗是Web系統的基本功能，比如一個公司組織架構管理系統，裡面提供了修改部門名稱、部門經理的功能。加上許可權校驗能很好地避免任意使用者能通過這些功能修改他本無許可權的資訊。此類系統中一定會實現許可權校驗，但實際上真的實現對了嗎？

假設我們規定，系統中某使用者需要同時滿足具有超管許可權且屬於A部門兩個條件，才能修改部門名稱。往往在實際的程式碼實現中，開發人員只是去判斷該使用者是否為超管，而沒有判斷該使用者是否屬於該部門。在這種情況下，我們可以用B部門的超管賬號，去修改A部門的名稱，相當於越權修改了，這顯然不是我們期望的結果。即使B部門的超管使用者在介面上無法找到修改A部門部門名稱的入口，也可以通過抓取請求修改引數來實現。

除了越權修改，當然還能越權檢視。我們肯定也不期望A部門的超管能看到B部門的部門資訊，是不是？

建議大家的系統要對使用者存取角色的許可權進行嚴格的檢查及限制。

安全無小事，正如開頭所講，任何一個漏洞都有可能帶來毀滅性的打擊，希望大家能重視。不僅在業務設計上要重視，同時也要在程式碼審查上要重視，以避免因實現而帶來的低階漏洞問題。

以上只是舉了眾多安全漏洞中的一小部分，更多嚴重的Web應用程式安全風險可以查閱 OWASP Top 10 2017 釋出的Top10安全問題。www.owasp.org.cn/owasp-proje…

以上就是使用JS檢測，你的Web系統真的安全嗎？的詳細內容，更多請關注TW511.COM其它相關文章！