專業在線打字練習平台-巧手打字通，只輸出有價值的知識。
一 數據庫操作，要謹慎
1.1 SQL注入，危害大
通過SQL注入等方式，把用户輸入的數據當做代碼執行。
簡單場景舉例：假如程序裏有以下基於訂單號查詢訂單的SQL語句，訂單號是用户從頁面傳遞過來的：
"SELECT * FROM my_order WHERE order_no = '" + OrderNo+ "'";如果黑客構造瞭如下訂單號參數：666'; drop table my_order--
那麼最終實際執行的SQL語句將會如下：
SELECT * FROM my_order WHERE order_no = '666'; drop table my_order --'查詢訂單的語義，就變成了查詢完訂單後，再執行一個drop表的操作，而這個操作，就是用户構造的惡意攻擊命令！
如果應用沒有做有效的參數校驗及脱敏處理，後台數據庫也沒有做權限約束，該sql注入的危害是極大的。
1.2 SQL隱式轉換，需留意
你知道嗎？下面的語句是能夠被正常執行的：
select * from my_order where order_no = "test"=0; // 相當於:where order_no = 1
update my_order set my_status="WHERE my_status=" = "yyy" ; // 相當於：update my_order set my_status = 0查詢操作主要影響的是數據返回的結果集，而更新操作則直接關係到整張表中數據的準確性和完整性。因此，在執行SQL語句之前，進行嚴格的正確性檢查是極其必要的。
二 跨站腳本攻擊,要防禦
Cross Site Scripting：跨站腳本攻擊,有時也縮寫為XSS。
攻擊者會在網頁中嵌入惡意腳本，一旦用户瀏覽該頁面，這些隱藏的惡意代碼就會被執行，進而實現攻擊者的特定目的。
舉個HTML頁面渲染攻擊的例子：
<span>$!orderNo</span>
<input type="hidden" name="oriSearchText" value="$!keyWord" $disabledFlag />
<script> var callback="$!response.script"</script>這段代碼就有可能被黑客利用,彈出木馬鏈接，獲取本地登錄會話信息等：
<span><iframe src="Hacker Url"></iframe></span>
<input type="hidden" name="oriSearchText" value=""> <iframe src="Hacker Url"></iframe>" <"" $disabledFlag />
<script> var callback=";hackerFunction4GetYourSession(document.cookie)"</script>XSS（跨站腳本攻擊）的核心問題在於用户提交的HTML代碼未經充分過濾和轉義就直接被頁面回顯，為解決這類安全隱患，必須對用户輸入的數據進行嚴格的轉換和脱敏處理。
三 跨站請求偽造，需甄別
Cross Site Request Forgery：即跨站請求偽造,有時也縮寫為XSRF。攻擊者通過誘導用户在已登錄的Web應用程序上執行惡意操作，比如誘導用户觸發應用的URL請求或填寫欺騙性表單，實質上是利用了應用的會話（session）機制，非法冒用已認證用户的身份，對應用執行未經授權的惡意GET/POST請求，以篡改用户數據。
3.1 實施步驟舉例
- 黑客首先在服務器端精心編寫惡意腳本，並構造出包含授信操作的特定URL，比如用於提交評論的鏈接。
- 接着，惡意用户利用這一漏洞，在回覆帖子時插入圖片，而圖片的來源地址則巧妙地指向黑客預先設置好的惡意腳本。
- 當無辜的用户瀏覽這些包含惡意圖片鏈接的帖子時，瀏覽器會自動請求加載這些圖片，從而在不知不覺中執行了黑客的惡意腳本。
- 惡意腳本進一步利用302重定向技術，根據帖子內容的不同，將用户重定向至預先設定的、包含敏感操作（如評論提交）的URL，從而在不經過用户明確授權的情況下執行惡意操作。
上述示例雖僅聚焦於引導用户跳轉至評論區作為演示，但實際上，黑客的手段遠不止於此。他們還可能精心構造偽裝成用户登錄頁面的URL，企圖誘騙用户輸入個人密碼；或是設計看似合法的支付頁面URL，以套取用户的支付密碼等高度敏感的核心信息。這些操作在用户毫無察覺的情況下進行，其潛在危害極為嚴重。
3.2 如何防禦XSRF攻擊
可以採用以下幾種策略：
- 使用CSRF令牌（Token）
這是最常見和有效的防禦方法。服務器生成一個唯一的CSRF令牌，並將其嵌入到每個表單或請求中。當客户端提交請求時，這個令牌會作為請求的一部分被髮送。服務器在收到請求後，會驗證令牌的有效性，確保請求來自受信任的源。這種方法可以有效防止CSRF攻擊，因為攻擊者很難預測或偽造這個令牌。
- 雙重驗證
對於重要的操作，如轉賬、修改密碼等，可以實施雙重驗證機制。除了用户密碼外，還需要額外的驗證信息，如短信驗證碼、指紋識別等。這樣即使攻擊者成功構造了CSRF請求，也無法通過雙重驗證，從而無法完成攻擊。
- 使用HTTPS
確保Web應用程序使用HTTPS協議進行通信。HTTPS可以加密客户端和服務器之間的數據傳輸，防止攻擊者在中間截獲或篡改請求。雖然HTTPS本身並不直接防禦CSRF攻擊，但它可以增強整體的安全性，降低攻擊成功的可能性。
- 驗證請求的來源（Referer檢查）
服務器可以檢查請求的Referer頭部，以判斷請求是否來自受信任的源。然而，這種方法並不是百分之百可靠的，因為Referer頭部可以被偽造或在某些情況下被瀏覽器省略。因此，它通常作為額外的防禦措施，而不是主要的防禦手段。
- 設置SameSite Cookie屬性
對於敏感操作相關的Cookie，可以設置SameSite屬性為Strict或Lax。這樣，瀏覽器就不會在跨站請求中發送這些Cookie，從而有效防止CSRF攻擊。但是，需要注意的是，這種方法可能會影響一些合法的跨站請求，因此需要根據實際情況進行配置。
四 越權操作，要杜絕
4.1 水平越權 VS 垂直越權
水平越權控制：“基於數據的訪問控制” 設計缺陷引起的漏洞。由於服務器端在接收到請求數據進行操作時沒有判斷數據的所屬人/所屬部門而導致的越權數據訪問漏洞；
未經檢驗和加密的參數漏洞是引發水平越權漏洞的基礎。當系統直接依據用户提交的手機號發送驗證碼時，若缺乏有效的驗證機制，攻擊者便可通過編寫自動化腳本，輕易發起短信轟炸攻擊。
更為安全穩妥的做法是，依據當前已登錄用户的唯一標識，通過後端服務查詢並確認其對應的手機號，而非直接採納前端輸入的參數（鑑於所有來自前端的數據均視為潛在的不安全輸入）。
或許有人會質疑，既然獲取當前登錄用户信息也依賴於前端傳遞的會話標識（如cookie、session ID），那麼這些標識是否就絕對可靠呢？
答案是否定的。儘管通過跨站腳本（XSS）等手段存在會話劫持的風險，但值得注意的是，會話標識的實現通常融合了多重安全機制，包括加密、時效控制及防篡改策略等，相較於普通業務參數而言，這些措施顯著增強了數據的安全性，提供了更為堅實的防護屏障。
垂直越權控制: “基於URL的訪問控制” 設計缺陷引起的漏洞，又叫做權限提升攻擊。由於後台應用沒有做權限控制，或僅僅在菜單、按鈕上做了權限控制，導致惡意用户只要猜測其他管理頁面的URL或者敏感的參數信息，就可以訪問或控制其他角色擁有的數據或頁面，達到權限提升的目的。
4.2 越權舉例説明
- 登錄用户A時，正常更改或者是查看A的用户信息；
- 然後抓取數據包，將業務傳參ID篡改為其他用户的；
- 如果成功查看或者修改了同權限其他用户信息就屬於水平越權；
- 如果可以獲得到更高權限用户（管理員）的操作能力(刪除)就是垂直越權；
五 安全漏洞，要規避
把握住傳參就能把握住邏輯漏洞的命脈。
5.1 規避策略分類
- 白名單校驗：接受已知的合法數據集。
- 黑名單校驗：拒絕已知的非法數據集；
- 白名單淨化：對任何不屬於已驗證合法字符數據中的字符進行淨化，然後再使用淨化後的數據，淨化的方式包括刪除、編碼、替換；
- 黑名單淨化：剔除或者轉換某些字符（例如，刪除引號、轉換成HTML實體，防止SQL注入）；
5.2 提示文案，也有風險
- 為提升用户體驗，眾多系統在註冊流程中增設了手機號與郵箱的查重功能，即時反饋如“該手機號已註冊！”的提示信息給用户。然而，這種做法不經意間提供了可遍歷的接口，增加了註冊用户信息泄露的風險，因此必須實施合理的請求頻率限制措施以保障安全。
- 在涉及手機號短信註冊、登錄、密碼找回及郵箱驗證等敏感操作中，若直接將驗證碼（或驗證憑證）嵌入交互請求中，則可能面臨被惡意攻擊者攔截的風險，進而導致驗證機制形同虛設。為防止驗證流程被輕易繞過，必須優化驗證邏輯設計，確保驗證信息的安全傳輸與驗證過程的有效執行。
總結
本文全面剖析了系統安全面臨的多個關鍵領域，包括數據、應用、權限及設計等方面，詳細闡述了這些領域內影響系統安全的典型場景。
- 在數據安全層面，文章重點指出了SQL注入這一嚴重威脅，它利用應用程序的漏洞，惡意篡改SQL語句，進而竊取或破壞數據庫中的敏感信息。同時，也提醒了SQL隱式轉換雖提升了編程效率，但其潛在的風險不容忽視，特別是在數據類型處理上需格外謹慎，以防安全漏洞的產生。
- 針對網頁安全，本文強調了跨站腳本攻擊（XSS）和跨站請求偽造（CSRF）這兩種常見且危險的攻擊方式，並指出需通過實施內容安全策略等有效防禦措施來加以應對。
- 在權限管理領域，文章深入分析了水平越權和垂直越權這兩種複雜的權限問題，強調了構建精細的訪問控制策略對於防範此類風險的重要性。
- 此外，設計安全方面也被納入討論範疇，特別是指出了提示文案設計時的敏感性，強調需謹慎處理，以避免誤導用户或泄露敏感信息。
綜上所述，構建一個穩固的安全防護體系，需要採取一系列綜合性的策略，包括但不限於加強輸入驗證、推廣使用參數化查詢、實施嚴格的安全編碼規範、部署高效的防禦機制，以及加強權限審計與管理等。這些措施的共同作用，將有效保障用户數據與應用的安全，顯著降低安全風險。
