❶ SpringBoot 防止sql注入、XSS攻擊、CSRF/CROS惡意訪問
一、SQL 注入問題
SQL 注入即是指 web 應用程序對用戶輸入數據的合法性沒有判斷或過濾不嚴，攻擊者可以在 web 應用程序中事先定義好的查詢語句的結尾上添加額外的 SQL 語句，在管理員不知情的情況下實現非法操作，以此來實現欺騙資料庫伺服器執行非授權的任意查詢，從而進一步得到相應的數據信息。
簡單來說，就是將大部分 SQL 語句當參數傳入系統中，從而獲取系統中的數據。下面簡單舉例說明
系統中有這樣一條信息 SQL 語句執行，分頁查詢所有用戶，每頁查詢 20 條，並且根據指定欄位進行排序，也就是說排序欄位也是參數傳遞過來的
SQL 注入問題分析：
這樣很簡單的一句話 SQL，就可以把系統搞炸掉，這種方式可以實現刪庫跑路
以上語句會把整個 test 資料庫所有內容都刪掉
盡量用預編譯機制，少用字元串拼接的方式傳參，它是 sql 注入問題的根源。
有些特殊字元，比如：%作為 like 語句中的參數時，要對其進行轉義處理。
需要對所有的異常情況進行捕獲，切記介面直接返回異常信息，因為有些異常信息中包含了 sql 信息，包括：庫名，表名，欄位名等。攻擊者拿著這些信息，就能通過 sql 注入隨心所欲地攻擊你的資料庫了。目前比較主流的做法是，有個專門的網關服務，它統一暴露對外介面。用戶請求介面時先經過它，再由它將請求轉發給業務服務。這樣做的好處是：能統一封裝返回數據的返回體，並且如果出現異常，能返回統一的異常信息，隱藏敏感信息。此外還能做限流和許可權控制。
使用 sqlMap 等待代碼檢測工具，它能檢測 sql 注入漏洞。
需要對資料庫 sql 的執行情況進行監控，有異常情況，及時郵件或簡訊提醒。
對生產環境的資料庫建立單獨的賬號，只分配 DML 相關許可權，且不能訪問系統表。切勿在程序中直接使用管理員賬號。
建立代碼 review 機制，能找出部分隱藏的問題，提升代碼質量。
對於不能使用預編譯傳參時，要麼開啟 druid 的 filter 防火牆，要麼自己寫代碼邏輯過濾掉所有可能的注入關鍵字。
XSS 攻擊通常指的是通過利用網頁開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶載入並執行攻擊者惡意製造的網頁程序。這些惡意網頁程序通常是 JavaScript，但實際上也可以包括 Java、 VBScript、ActiveX、 Flash 或者甚至是普通的 HTML。攻擊成功後，攻擊者可能得到包括但不限於更高的許可權（如執行一些操作）、私密網頁內容、會話和 cookie 等各種內容。
通常情況下，被用來盜用 Cookie、破壞頁面結構、重定向到其他網站等
對用戶輸入的表單信息進行檢測過濾
CSRF - Cross-Site Request Forgery - 跨站請求偽造:
攻擊可以在受害者毫不知情的情況下以受害者名義偽造請求發送給受攻擊站點，從而在未授權的情況下執行在許可權保護之下的操作，CORS - Cross Origin Resourse-Sharing - 跨站資源共享，惡意訪問內網敏感資源。
有效的解決辦法是通過多種條件屏蔽掉非法的請求，例如 HTTP 頭、參數等：
防止大規模的惡意請求，niginx 反向代理可以配置請求頻率，對 ip 做限制。nginx 可以很方便地做訪問控制，特別是一些偶發性的大量惡意請求，需要屏蔽處理。
屏蔽 ip 地址
屏蔽 user-agent
屏蔽代理 ip
有兩種情形會需要屏蔽代理 ip：一是代理 ip 訪問，二是負載均衡（real-ip 請求負載均衡伺服器，再代理給後端 server）
創建 包裝器，這是實現 XSS 過濾的關鍵，在其內重寫了 getParameter，getParameterValues，getHeader 等方法，對 http 請求內的參數進行了過濾
❷ 如何檢查sql注入問題
SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令！查漏洞可以去網路里打iiscan，登錄億思官網，裡面有免費的網站安全檢測，可以查漏洞的！！！
❸ 求用java編寫帶界面的SQL注入檢測程序
程序沒有，不過以前做過這方面的一些研究，給你總結了一下。一般來說有這些種，樓主可以根據這些來寫測試語句。
1.沒有正確過濾轉義字元
在用戶的輸入沒有為轉義字元過濾時，就會發生這種形式的注入式攻擊，它會被傳遞給一個SQL語句。這樣就會導致應用程序的終端用戶對資料庫上的語句實施操縱。比方說，下面的這行代碼就會演示這種漏洞：
statement := "SELECT * FROM users WHERE name = '" + userName + "'; "
這種代碼的設計目的是將一個特定的用戶從其用戶表中取出，但是，如果用戶名被一個惡意的用戶用一種特定的方式偽造，這個語句所執行的操作可能就不僅僅是代碼的作者所期望的那樣了。例如，將用戶名變數(即username)設置為：
a' or 't'='t，此時原始語句發生了變化：
SELECT * FROM users WHERE name = 'a' OR 't'='t';
如果這種代碼被用於一個認證過程，那麼這個例子就能夠強迫選擇一個合法的用戶名，因為賦值't'='t永遠是正確的。
在一些SQL伺服器上，如在SQLServer中，任何一個SQL命令都可以通過這種方法被注入，包括執行多個語句。下面語句中的username的值將會導致刪除「users」表，又可以從「data」表中選擇所有的數據(實際上就是透露了每一個用戶的信息)。
a'; DROP TABLE users; SELECT * FROM data WHERE name LIKE '%
這就將最終的SQL語句變成下面這個樣子：
SELECT * FROM users WHERE name = 'a'; DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';
其它的SQL執行不會將執行同樣查詢中的多個命令作為一項安全措施。這會防止攻擊者注入完全獨立的查詢，不過卻不會阻止攻擊者修改查詢。
2.Incorrect type handling
如果一個用戶提供的欄位並非一個強類型，或者沒有實施類型強制，就會發生這種形式的攻擊。當在一個SQL語句中使用一個數字欄位時，如果程序員沒有檢查用戶輸入的合法性(是否為數字型)就會發生這種攻擊。例如：
statement := "SELECT * FROM data WHERE id = " + a_variable + "; "
從這個語句可以看出，作者希望a_variable是一個與「id」欄位有關的數字。不過，如果終端用戶選擇一個字元串，就繞過了對轉義字元的需要。例如，將a_variable設置為:1; DROP TABLE users，它會將「users」表從資料庫中刪除，SQL語句變成：SELECT * FROM DATA WHERE id = 1; DROP TABLE users;
3.資料庫伺服器中的漏洞
有時，資料庫伺服器軟體中也存在著漏洞，如MYSQL伺服器中mysql_real_escape_string()函數漏洞。這種漏洞允許一個攻擊者根據錯誤的統一字元編碼執行一次成功的SQL注入式攻擊。
4.盲目SQL注入式攻擊
當一個Web應用程序易於遭受攻擊而其結果對攻擊者卻不見時，就會發生所謂的盲目SQL注入式攻擊。有漏洞的網頁可能並不會顯示數據，而是根據注入到合法語句中的邏輯語句的結果顯示不同的內容。這種攻擊相當耗時，因為必須為每一個獲得的位元組而精心構造一個新的語句。但是一旦漏洞的位置和目標信息的位置被確立以後，一種稱為Absinthe的工具就可以使這種攻擊自動化。
5.條件響應
注意，有一種SQL注入迫使資料庫在一個普通的應用程序屏幕上計算一個邏輯語句的值：
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1
這會導致一個標準的面面，而語句
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2在頁面易於受到SQL注入式攻擊時，它有可能給出一個不同的結果。如此這般的一次注入將會證明盲目的SQL注入是可能的，它會使攻擊者根據另外一個表中的某欄位內容設計可以評判真偽的語句。
6.條件性差錯
如果WHERE語句為真，這種類型的盲目SQL注入會迫使資料庫評判一個引起錯誤的語句，從而導致一個SQL錯誤。例如：
SELECT 1/0 FROM users WHERE username='Ralph'。顯然，如果用戶Ralph存在的話，被零除將導致錯誤。
7.時間延誤
時間延誤是一種盲目的SQL注入，根據所注入的邏輯，它可以導致SQL引擎執行一個長隊列或者是一個時間延誤語句。攻擊者可以衡量頁面載入的時間，從而決定所注入的語句是否為真。