1. 怎樣判斷網頁有sql注入漏洞
直接用軟體
這個最簡單
2. 如何防範SQL注入漏洞及檢測
SQL注入漏洞攻擊的防範方法有很多種，現階段總結起來有以下方法：
(1)數據有效性校驗。如果一個輸入框只可能包括數字，那麼要通過校驗確保用戶輸入的都是數字。如果可以接受字母，那就要檢查是不是存在不可接受的字元，最好的方法是增加字元復雜度自動驗證功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。另外限製表單數據輸入和查詢字元串輸入的長度也是一個好方法。如果用戶的登錄名最多隻有10個字元，那麼不要認可表單中輸入10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
(2)封裝數據信息。對客戶端提交的數據進行封裝，不要將數據直接存入cookie中，方法就是在編程的代碼中，插入session、if、try、else，這樣可以有效地防止攻擊者獲取cookie中的重要信息。
(3)去除代碼中的敏感信息。將在代碼中存在的用戶名、口令信息等敏感欄位刪除，替換成輸入框。
SQL=" select from users where username = 』admin』and password= 』1234567』 "
如：這樣顯然會暴露管理員的用戶名、口令信息。可以將其修改成：
SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"
這樣就安全了很多，入侵者也是不會輕易的就獲取到用戶名、口令信息。
(4)替換或刪除單引號。使用雙引號替換掉所有用戶輸入的單引號，這個簡單的預防措施將在很大程度上預防SQL注入漏洞攻擊，單引號時常會無法約束插入數據的Value，可能給予輸入者不必要的許可權。用雙引號替換掉單引號可以使大部分SQL注入漏洞攻擊失敗。 如：
「select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'」
顯然會得到與
「select * from users where username='admin' and password= '1234567'」
相同的結果。
(5)指定錯誤返回頁面。攻擊者有時從客戶端嘗試提交有害代碼和攻擊字元串，根據Web Service給出的錯誤提示信息來收集程序及伺服器的信息，從而獲取想得到的資料。應在Web Service中指定一個不包含任何信息的錯誤提示頁面。
(6)限制SQL字元串連接的配置文件。使用SQL變數，因為變數不是可以執行的腳本，即在Web頁面中將連接資料庫的SQL字元串替換成指定的Value，然後將Web.config文件進行加密，拒絕訪問。
(7)設置Web目錄的訪問許可權。將虛擬站點的文件目錄禁止遊客用戶(如：Guest用戶等)訪問，將User用戶許可權修改成只讀許可權，切勿將管理許可權的用戶添加到訪問列表。
(8)最小服務原則。Web伺服器應以最小許可權進行配置，只提供Web服務，這樣可以有效地阻止系統的危險命令，如ftp、cmd、vbscript等。
(9)鑒別信息加密存儲。將保存在資料庫users表中的用戶名、口令信息以密文形式保存，也可以對users表進行加密處理，這樣可以大大增加對鑒別信息訪問的安全級別。
(10)用戶許可權分離。應盡可能的禁止或刪除資料庫中sa許可權用戶的訪問，對不同的資料庫劃分不同的用戶許可權，這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的資料庫進行訪問。
3. SQL注入漏洞的判斷
如果以前沒玩過注入，
請把IE菜單-工具-Internet選項－高級－顯示友好HTTP錯誤信息前面的勾去掉。
為了把問題說明清楚，以下以asp?id=xx(" target=_blank>http://www.hackbase.com/news.asp?id=xx(這個地址是假想的)
為例進行分析，xx可能是整型，也有可能是字元串。
1、整型參數的判斷
當輸入的參數xx為整型時，通常news.asp中SQL語句原貌大致如下：
select * from 表名 where 欄位=xx，所以可以用以下步驟測試SQL注入是否存在。
最簡單的判斷方法
http://www.hackbase.com/news.asp?id=xx』(附加一個單引號)，
此時news.asp中的SQL語句變成了
select * from 表名 where 欄位=xx』，
如果程序沒有過濾好「』」的話
就會提示 news.asp運行異常；
但這樣的方法雖然很簡單，但並不是最好的
因為
first,不一定每台伺服器的IIS都返回具體錯誤提示給客戶端，
如果程序中加了cint(參數)之類語句的話，SQL注入是不會成功的，
但伺服器同樣會報錯，具體提示信息為處理 URL 時伺服器上出錯。
請和系統管理員聯絡。
second，目前大多數程序員已經將「』「 過濾掉，所以用」 』」測試不到注入點
所以一般使用經典的1=1和1=2測試方法
見下文：
http://www.hackbase.com/news.asp?id=xx and 1=1, news.asp運行正常，
而且與http://www.hackbase.com/news.asp?id=xx運行結果相同；
http://www.hackbase.com/news.asp?id=xx and 1=2, news.asp運行異常；（這就是經典的 1=1 ;1=2 判斷方法）
如果以上面滿足，news.asp中就會存在SQL注入漏洞，反之則可能不能注入。
2、字元串型參數的判斷
方法與數值型參數判斷方法基本相同
當輸入的參數xx為字元串時，通常news.asp中SQL語句原貌大致如下：
select * from 表名 where 欄位='xx'，所以可以用以下步驟測試SQL注入是否存在。
http://www.hackbase.com/news.asp?id=xx』(附加一個單引號)，此時news.asp中的SQL語句變成了
select * from 表名 where 欄位=xx』，news.asp運行異常；
http://www.hackbase.com/news.asp?id=xx and '1'='1', news.asp運行正常，
而且與http://www.hackbase.com/news.asp?id=xx運行結果相同；
http://www.hackbase.com/news.asp?id=xx and '1'='2', news.asp運行異常；
如果以上滿足，則news.asp存在SQL注入漏洞，反之則不能注入
3、特殊情況的處理
有時ASP程序員會在程序員過濾掉單引號等字元，以防止SQL注入。此時可以用以下幾種方法試一試。
①大小定混合法：由於VBS並不區分大小寫，而程序員在過濾時通常要麼全部過濾大寫字元串，要麼全部過濾小寫字元串，而大小寫混合往往會被忽視。如用SelecT代替select,SELECT等；
②UNICODE法：在IIS中，以UNICODE字元集實現國際化，我們完全可以IE中輸入的字元串化成UNICODE字元串進行輸入。如+ =%2B，空格=%20 等
；URLEncode信息參見附件一；
③ASCII碼法：可以把輸入的部分或全部字元全部
<4>出了上述方法以外，還有個更簡單的方法就是使用現成的工具
像NB聯盟的NBSI就是一款很不錯的工具，目前最新的版本為2.2
4. 怎麼檢測sql server注入漏洞
許多網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼(一般是在瀏覽器地址欄進行,通過正常的www埠訪問)，根據程序返回的結果，獲得某些想得知的數據，這就是所謂的SQL Injection，即SQL注入。
網站的惡夢——SQL注入
SQL注入通過網頁對網站資料庫進行修改。它能夠直接在資料庫中添加具有管理員許可權的用戶，從而最終獲得系統管理員許可權。黑客可以利用獲得的管理員許可權任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序，對網站和訪問該網站的網友都帶來巨大危害。
防禦SQL注入有妙法
第一步:很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用來防止別人進行手動注入測試。
可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾，你的管理員賬號及密碼就會被分析出來。
第二步:對於注入分析器的防範，通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟體並不是沖著「admin」管理員賬號去的，而是沖著許可權(如flag=1)去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。
第三步:既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，如果找一個許可權最大的賬號製造假象，吸引軟體的檢測，而這個賬號里的內容是大於千字以上的中文字元，就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。
1.對表結構進行修改。將管理員的賬號欄位的數據類型進行修改，文本型改成最大欄位255(其實也夠了，如果還想做得再大點，可以選擇備注型)，密碼的欄位也進行相同設置。
2.對表進行修改。設置管理員許可權的賬號放在ID1，並輸入大量中文字元(最好大於100個字)。
3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。
我們通過上面的三步完成了對資料庫的修改。
另外要明白您做的ID1賬號其實也是真正有許可權的賬號，現在計算機處理速度那麼快，要是遇上個一定要將它算出來的軟體，這也是不安全的。只要在管理員登錄的頁面文件中寫入字元限制就行了，就算對方使用這個有上千字元的賬號密碼也會被擋住的，而真正的密碼則可以不受限制。
5. SQL注入漏洞檢測對於字元串型的判斷方法
你說的這兩種是一樣的，就看第一種就行。我給你逐步解釋一下
第一步在url後面添加了『後sql語句可以正常運行說明asp代碼沒有設置屏蔽』的機制；
第二步在url最後添加了'and'1'='1後select語句就編程了
select * from 表名 where 欄位='YY'and'1'='1'
如果這樣也能正常運行則證明asp代碼沒有屏蔽條件插入的機制；
第二步和第一步其實沒有本質的區別，只是進一步確認；
第三部url後面追加的編程了1=2，同第二部一個原理，只不過這次測試的是asp代碼沒有屏蔽掉資料庫報錯信息，而黑客可以通過這些信息得到很多系統信息以方便下一步的動作。
綜上三步，當然可以知道這里可以作為入住點。LZ應該能明白了吧
6. 滲透測試的步驟有哪些
滲透測試步驟
明確目標
· 確定范圍：測試目標的范圍，ip，域名，內外網。
· 確定規則：能滲透到什麼程度，時間?能否修改上傳?能否提權等。
· 確定需求：web應用的漏洞、業務邏輯漏洞、人員許可權管理漏洞等等。
信息收集
方式：主動掃描，開放搜索等。
開放搜索：利用搜索引擎獲得，後台，未授權頁面，敏感url等。
漏洞探索
利用上一步中列出的各種系統，應用等使用相應的漏洞。
方法：
1.漏掃，awvs，IBM appscan等。
2.結合漏洞去exploit-db等位置找利用。
3.在網上尋找驗證poc。
內容：
系統漏洞：系統沒有及時打補丁
Websever漏洞：Websever配置問題
Web應用漏洞：Web應用開發問題
其它埠服務漏洞：各種21/8080(st2)/7001/22/3389
通信安全：明文傳輸，token在cookie中傳送等。
漏洞驗證
將上一步中發現的有可能可以成功利用的全部漏洞都驗證一遍，結合實際情況，搭建模擬環境進行試驗。成功後再應用於目標中。
自動化驗證：結合自動化掃描工具提供的結果
手工驗證，根據公開資源進行驗證
試驗驗證：自己搭建模擬環境進行驗證
登陸猜解：有時可以嘗試猜解一下登陸口的賬號密碼等信息
業務漏洞驗證：如發現業務漏洞，要進行驗證
公開資源的利用
信息分析
為下一步實施滲透做准備：
精準打擊：准備好上一步探測到的漏洞的exp，用來精準打擊
繞過防禦機制：是否有防火牆等設備，如何繞過
定製攻擊路徑：最佳工具路徑，根據薄弱入口，高內網許可權位置，最終目標
繞過檢測機制：是否有檢測機制，流量監控，殺毒軟體，惡意代碼檢測等
攻擊代碼：經過試驗得來的代碼，包括不限於xss代碼，sql注入語句等
獲取所需
實施攻擊：根據前幾步的結果，進行攻擊
獲取內部信息：基礎設施
進一步滲透：內網入侵，敏感目標
持續性存在：一般我們對客戶做滲透不需要。rookit，後門，添加管理賬號，駐扎手法等
清理痕跡：清理相關日誌，上傳文件等
信息整理
整理滲透工具：整理滲透過程中用到的代碼，poc，exp等
整理收集信息：整理滲透過程中收集到的一切信息
整理漏洞信息：整理滲透過程中遇到的各種漏洞，各種脆弱位置信息
形成報告
按需整理：按照之前第一步跟客戶確定好的范圍，需求來整理資料，並將資料形成報告
補充介紹：要對漏洞成因，驗證過程和帶來危害進行分析
修補建議：當然要對所有產生的問題提出合理高效安全的解決辦法
7. 如何判斷資料庫被SQL注入漏洞
SQL注入一般會在http://xxx.xxx.xxx/abc.asp?id=XX這樣等帶有參數的ASP動態網頁中，有些動態網頁中可能只有一個參數，有些可能有n個參數；有些參數是整型，有些參數是字元串型。只要是帶有參數的動態網頁訪問了資料庫就有可能存在SQL注入。
我們首選要修改瀏覽器的設置，以便更好的了解動態網頁參數里包含的信息。以IE瀏覽器為例，把IE菜單-工具-Internet選項－高級－顯示友好HTTP錯誤信息前面的勾去掉。
下面以http://xxx.xxx.xxx/abc.asp?p=YY為例進行分析，「YY」可能是整型，也有可能是字元串。
1、整型參數的判斷
當輸入的參數YY為整型時，通常abc.asp中SQL語句原貌大致如下：
select * from 表名 where 欄位=YY，所以可以用以下步驟測試SQL注入是否存在。
（1）http://xxx.xxx.xxx/abc.asp?p=YY and 1=2, abc.asp運行異常；
（2）http://xxx.xxx.xxx/abc.asp?p=YY』(附加一個單引號)，此時abc.ASP中的SQL語句變成了select * from 表名 where 欄位=YY』，abc.asp運行異常；
（3）http://xxx.xxx.xxx/abc.asp?p=YY and 1=1, abc.asp運行正常，而且與http://xxx.xxx.xxx/abc.asp?p=YY運行結果相同；
如果這三個方面全部滿足，abc.asp中一定存在SQL注入漏洞！
2、字元串型參數的判斷
當輸入的參數YY為字元串時，通常abc.asp中SQL語句原貌大致如下：
select * from 表名 where 欄位=』YY』，所以可以用以下步驟測試SQL注入是否存在。
（1）http://xxx.xxx.xxx/abc.asp?p=YY&nb … 39;1』=』2′, abc.asp運行異常；
（2）http://xxx.xxx.xxx/abc.asp?p=YY&nb … 39;1』=』1′, abc.asp運行正常，而且與http://xxx.xxx.xxx/abc.asp?p=YY運行結果相同；
（3）http://xxx.xxx.xxx/abc.asp?p=YY』(附加一個單引號)，此時abc.ASP中的SQL語句變成了select * from 表名 where 欄位=YY』，abc.asp運行異常；
如果這三個方面全部滿足，abc.asp中一定存在SQL注入漏洞！
3、字元被過濾的判斷
有安全意識的ASP程序員會過濾掉單引號等字元，以防止SQL注入。這種情況可以用下面幾種方法嘗試。
（1）ASCII方法:所有的輸入部分或全部字元的ASCII代碼,如U = CRH(85),一個= CRH(97),等等。
(2)UNICODE方法:在IIS UNICODE字元集實現國際化,我們可以在輸入字元串即輸入UNICODE字元串。如+ = % 2 b,空格= % 20,等;
(1)混合設置方法:大小是大小寫不敏感的,因為根據當時和過濾器的程序員通常要麼過濾所有大寫字母的字元串,或過濾所有小寫的字元串,大小寫混合往往會被忽略。如用SelecT代替select,SELECT等。
8. 測試登陸頁面時，如何測試SQL注入漏洞呢
許多網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼(一般是在瀏覽器地址欄進行,通過正常的www埠訪問)，根據程序返回的結果，獲得某些想得知的數據，這就是所謂的SQL Injection，即SQL注入。
網站的惡夢——SQL注入
SQL注入通過網頁對網站資料庫進行修改。它能夠直接在資料庫中添加具有管理員許可權的用戶，從而最終獲得系統管理員許可權。黑客可以利用獲得的管理員許可權任意獲得網站上的文件或者在網頁上加掛木馬和各種惡意程序，對網站和訪問該網站的網友都帶來巨大危害。
防禦SQL注入有妙法
第一步:很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用來防止別人進行手動注入測試。
可是如果通過SQL注入分析器就可輕松跳過防注入系統並自動分析其注入點。然後只需要幾分鍾，你的管理員賬號及密碼就會被分析出來。
第二步:對於注入分析器的防範，通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟體並不是沖著「admin」管理員賬號去的，而是沖著許可權(如flag=1)去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。
第三步:既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，如果找一個許可權最大的賬號製造假象，吸引軟體的檢測，而這個賬號里的內容是大於千字以上的中文字元，就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。
1.對表結構進行修改。將管理員的賬號欄位的數據類型進行修改，文本型改成最大欄位255(其實也夠了，如果還想做得再大點，可以選擇備注型)，密碼的欄位也進行相同設置。
2.對表進行修改。設置管理員許可權的賬號放在ID1，並輸入大量中文字元(最好大於100個字)。
3.把真正的管理員密碼放在ID2後的任何一個位置(如放在ID549上)。
我們通過上面的三步完成了對資料庫的修改。
另外要明白您做的ID1賬號其實也是真正有許可權的賬號，現在計算機處理速度那麼快，要是遇上個一定要將它算出來的軟體，這也是不安全的。只要在管理員登錄的頁面文件中寫入字元限制就行了，就算對方使用這個有上千字元的賬號密碼也會被擋住的，而真正的密碼則可以不受限制。
9. 滲透測試應該怎麼做呢
01、信息收集
1、域名、IP、埠
域名信息查詢：信息可用於後續滲透
IP信息查詢：確認域名對應IP，確認IP是否真實，確認通信是否正常
埠信息查詢：NMap掃描，確認開放埠
發現：一共開放兩個埠，80為web訪問埠，3389為windows遠程登陸埠，嘿嘿嘿，試一下
發現：是Windows Server 2003系統，OK，到此為止。
2、指紋識別
其實就是網站的信息。比如通過可以訪問的資源，如網站首頁，查看源代碼:
看看是否存在文件遍歷的漏洞（如圖片路徑，再通過…/遍歷文件）
是否使用了存在漏洞的框架（如果沒有現成的就自己挖）
02、漏洞掃描
1、主機掃描
Nessus
經典主機漏掃工具，看看有沒有CVE漏洞：
2、Web掃描
AWVS（Acunetix | Website Security Scanner）掃描器
PS：掃描器可能會對網站構成傷害，小心謹慎使用。
03、滲透測試
1、弱口令漏洞
漏洞描述
目標網站管理入口（或資料庫等組件的外部連接）使用了容易被猜測的簡單字元口令、或者是默認系統賬號口令。
滲透測試
① 如果不存在驗證碼，則直接使用相對應的弱口令字典使用burpsuite 進行爆破
② 如果存在驗證碼，則看驗證碼是否存在繞過、以及看驗證碼是否容易識別
風險評級：高風險
安全建議
① 默認口令以及修改口令都應保證復雜度，比如：大小寫字母與數字或特殊字元的組合，口令長度不小於8位等
② 定期檢查和更換網站管理口令
2、文件下載（目錄瀏覽）漏洞
漏洞描述
一些網站由於業務需求，可能提供文件查看或下載的功能，如果對用戶查看或下載的文件不做限制，則惡意用戶就能夠查看或下載任意的文件，可以是源代碼文件、敏感文件等。
滲透測試
① 查找可能存在文件包含的漏洞點，比如js，css等頁面代碼路徑
② 看看有沒有文件上傳訪問的功能
③ 採用…/來測試能否誇目錄訪問文件
風險評級：高風險
安全建議
① 採用白名單機制限制伺服器目錄的訪問，以及可以訪問的文件類型(小心被繞過)
② 過濾【./】等特殊字元
③ 採用文件流的訪問返回上傳文件（如用戶頭像），不要通過真實的網站路徑。
示例：tomcat，默認關閉路徑瀏覽的功能：
<param-name>listings</param-name>
<param-value>false</param-value>
3、任意文件上傳漏洞
漏洞描述
目標網站允許用戶向網站直接上傳文件，但未對所上傳文件的類型和內容進行嚴格的過濾。
滲透測試
① 收集網站信息，判斷使用的語言（PHP，ASP，JSP）
② 過濾規則繞過方法：文件上傳繞過技巧
風險評級：高風險
安全建議
① 對上傳文件做有效文件類型判斷，採用白名單控制的方法，開放只允許上傳的文件型式；
② 文件類型判斷，應對上傳文件的後綴、文件頭、圖片類的預覽圖等做檢測來判斷文件類型，同時注意重命名（Md5加密）上傳文件的文件名避免攻擊者利用WEB服務的缺陷構造畸形文件名實現攻擊目的；
③ 禁止上傳目錄有執行許可權；
④ 使用隨機數改寫文件名和文件路徑，使得用戶不能輕易訪問自己上傳的文件。
4、命令注入漏洞
漏洞描述
目標網站未對用戶輸入的字元進行特殊字元過濾或合法性校驗，允許用戶輸入特殊語句，導致各種調用系統命令的web應用，會被攻擊者通過命令拼接、繞過黑名單等方式，在服務端運行惡意的系統命令。
滲透測試
風險評級：高風險
安全建議
① 拒絕使用拼接語句的方式進行參數傳遞；
② 盡量使用白名單的方式（首選方式）；
③ 過濾危險方法、特殊字元，如：【|】【&】【；】【』】【"】等
5、SQL注入漏洞
漏洞描述
目標網站未對用戶輸入的字元進行特殊字元過濾或合法性校驗，允許用戶輸入特殊語句查詢後台資料庫相關信息
滲透測試
① 手動測試：判斷是否存在SQL注入，判斷是字元型還是數字型，是否需要盲注
② 工具測試：使用sqlmap等工具進行輔助測試
風險評級：高風險
安全建議
① 防範SQL注入攻擊的最佳方式就是將查詢的邏輯與其數據分隔，如Java的預處理，PHP的PDO
② 拒絕使用拼接SQL的方式
6、跨站腳本漏洞
漏洞描述
當應用程序的網頁中包含不受信任的、未經恰當驗證或轉義的數據時，或者使用可以創建 HTML或JavaScript 的瀏覽器 API 更新現有的網頁時，就會出現 XSS 缺陷。XSS 讓攻擊者能夠在受害者的瀏覽器中執行腳本，並劫持用戶會話、破壞網站或將用戶重定向到惡意站點。
三種XSS漏洞：
① 存儲型：用戶輸入的信息被持久化，並能夠在頁面顯示的功能，都可能存在存儲型XSS，例如用戶留言、個人信息修改等。
② 反射型：URL參數需要在頁面顯示的功能都可能存在反射型跨站腳本攻擊，例如站內搜索、查詢功能。
③ DOM型：涉及DOM對象的頁面程序，包括：document.URL、document.location、document.referrer、window.location等
滲透測試
存儲型，反射型，DOM型
風險評級：高風險
安全建議
① 不信任用戶提交的任何內容，對用戶輸入的內容，在後台都需要進行長度檢查，並且對【<】【>】【"】【』】【&】等字元做過濾
② 任何內容返回到頁面顯示之前都必須加以html編碼，即將【<】【>】【"】【』】【&】進行轉義。
7、跨站請求偽造漏洞
漏洞描述
CSRF，全稱為Cross-Site Request Forgery，跨站請求偽造，是一種網路攻擊方式，它可以在用戶毫不知情的情況下，以用戶的名義偽造請求發送給被攻擊站點，從而在未授權的情況下進行許可權保護內的操作，如修改密碼，轉賬等。
滲透測試
風險評級：中風險（如果相關業務極其重要，則為高風險）
安全建議
① 使用一次性令牌：用戶登錄後產生隨機token並賦值給頁面中的某個Hidden標簽，提交表單時候，同時提交這個Hidden標簽並驗證，驗證後重新產生新的token，並賦值給hidden標簽；
② 適當場景添加驗證碼輸入：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字元串；
③ 請求頭Referer效驗，url請求是否前部匹配Http(s)😕/ServerHost
④ 關鍵信息輸入確認提交信息的用戶身份是否合法，比如修改密碼一定要提供原密碼輸入
⑤ 用戶自身可以通過在瀏覽其它站點前登出站點或者在瀏覽器會話結束後清理瀏覽器的cookie；
8、內部後台地址暴露
漏洞描述
一些僅被內部訪問的地址，對外部暴露了，如：管理員登陸頁面；系統監控頁面；API介面描述頁面等，這些會導致信息泄露，後台登陸等地址還可能被爆破。
滲透測試
① 通過常用的地址進行探測，如login.html，manager.html，api.html等；
② 可以借用burpsuite和常規頁面地址字典，進行掃描探測
風險評級：中風險
安全建議
① 禁止外網訪問後台地址
② 使用非常規路徑（如對md5加密）
9、信息泄露漏洞
漏洞描述
① 備份信息泄露：目標網站未及時刪除編輯器或者人員在編輯文件時，產生的臨時文件，或者相關備份信息未及時刪除導致信息泄露。
② 測試頁面信息泄露：測試界面未及時刪除，導致測試界面暴露，被他人訪問。
③ 源碼信息泄露：目標網站文件訪問控制設置不當，WEB伺服器開啟源碼下載功能，允許用戶訪問網站源碼。
④ 錯誤信息泄露：目標網站WEB程序和伺服器未屏蔽錯誤信息回顯，頁面含有CGI處理錯誤的代碼級別的詳細信息，例如SQL語句執行錯誤原因，PHP的錯誤行數等。
⑤ 介面信息泄露：目標網站介面訪問控制不嚴，導致網站內部敏感信息泄露。
滲透測試
① 備份信息泄露、測試頁面信息泄露、源碼信息泄露，測試方法：使用字典，爆破相關目錄，看是否存在相關敏感文件
② 錯誤信息泄露，測試方法：發送畸形的數據報文、非正常的報文進行探測，看是否對錯誤參數處理妥當。
③ 介面信息泄露漏洞，測試方法：使用爬蟲或者掃描器爬取獲取介面相關信息，看目標網站對介面許可權是否合理
風險評級：一般為中風險，如果源碼大量泄漏或大量客戶敏感信息泄露。
安全建議
① 備份信息泄露漏洞：刪除相關備份信息，做好許可權控制
② 測試頁面信息泄露漏洞：刪除相關測試界面，做好許可權控制
③ 源碼信息泄露漏洞：做好許可權控制
④ 錯誤信息泄露漏洞：將錯誤信息對用戶透明化，在CGI處理錯誤後可以返回友好的提示語以及返回碼。但是不可以提示用戶出錯的代碼級別的詳細原因
⑤ 介面信息泄露漏洞：對介面訪問許可權嚴格控制
10、失效的身份認證
漏洞描述
通常，通過錯誤使用應用程序的身份認證和會話管理功能，攻擊者能夠破譯密碼、密鑰或會話令牌， 或者利用其它開發缺陷來暫時性或永久性冒充其他用戶的身份。
滲透測試
① 在登陸前後觀察，前端提交信息中，隨機變化的數據，總有與當前已登陸用戶進行綁定的會話唯一標識，常見如cookie
② 一般現在網站沒有那種簡單可破解的標識，但是如果是跨站認證，單點登錄場景中，可能為了開發方便而簡化了身份認證
風險評級：高風險
安全建議
① 使用強身份識別，不使用簡單弱加密方式進行身份識別；
② 伺服器端使用安全的會話管理器，在登錄後生成高度復雜的新隨機會話ID。會話ID不能在URL中，可以安全地存儲，在登出、閑置超時後使其失效。
11、失效的訪問控制
漏洞描述
未對通過身份驗證的用戶實施恰當的訪問控制。攻擊者可以利用這些缺陷訪問未經授權的功能或數據，例如：訪問其他用戶的帳戶、查看敏感文件、修改其他用戶的數據、更改訪問許可權等。
滲透測試
① 登入後，通過burpsuite 抓取相關url 鏈接，獲取到url 鏈接之後，在另一個瀏覽器打開相關鏈接，看能夠通過另一個未登入的瀏覽器直接訪問該功能點。
② 使用A用戶登陸，然後在另一個瀏覽器使用B用戶登陸，使用B訪問A獨有的功能，看能否訪問。
風險評級：高風險
安全建議
① 除公有資源外，默認情況下拒絕訪問非本人所有的私有資源；
② 對API和控制器的訪問進行速率限制，以最大限度地降低自動化攻擊工具的危害；
③ 當用戶注銷後，伺服器上的Cookie，JWT等令牌應失效；
④ 對每一個業務請求，都進行許可權校驗。
12、安全配置錯誤
漏洞描述
應用程序缺少適當的安全加固，或者雲服務的許可權配置錯誤。
① 應用程序啟用或安裝了不必要的功能（例如：不必要的埠、服務、網頁、帳戶或許可權）。
② 默認帳戶的密碼仍然可用且沒有更改。
③ 錯誤處理機制向用戶披露堆棧跟蹤或其他大量錯誤信息。
④ 對於更新的系統，禁用或不安全地配置最新的安全功能。
⑤ 應用程序伺服器、應用程序框架（如：Struts、Spring、ASP.NET）、庫文件、資料庫等沒有進行相關安全配置。
滲透測試
先對應用指紋等進行信息搜集，然後針對搜集的信息，看相關應用默認配置是否有更改，是否有加固過；埠開放情況，是否開放了多餘的埠；
風險評級：中風險
安全建議
搭建最小化平台，該平台不包含任何不必要的功能、組件、文檔和示例。移除或不安裝不適用的功能和框架。在所有環境中按照標準的加固流程進行正確安全配置。
13、使用含有已知漏洞的組件
漏洞描述
使用了不再支持或者過時的組件。這包括：OS、Web伺服器、應用程序伺服器、資料庫管理系統（DBMS）、應用程序、API和所有的組件、運行環境和庫。
滲透測試
① 根據前期信息搜集的信息，查看相關組件的版本，看是否使用了不在支持或者過時的組件。一般來說，信息搜集，可通過http返回頭、相關錯誤信息、應用指紋、埠探測（Nmap）等手段搜集。
② Nmap等工具也可以用於獲取操作系統版本信息
③ 通過CVE，CNVD等平台可以獲取當前組件版本是否存在漏洞
風險評級：按照存在漏洞的組件的安全風險值判定當前風險。
安全建議
① 移除不使用的依賴、不需要的功能、組件、文件和文檔；
② 僅從官方渠道安全的獲取組件(盡量保證是最新版本)，並使用簽名機制來降低組件被篡改或加入惡意漏洞的風險；
③ 監控那些不再維護或者不發布安全補丁的庫和組件。如果不能打補丁，可以考慮部署虛擬補丁來監控、檢測或保護。
詳細學習可參考：
10. 哪些工具可以用來測試sql注入漏洞
SQL注入漏洞有哪些 SQL注入攻擊是當今最危險、最普遍的基於Web的攻擊之一。所謂注入攻擊，是攻擊者把SQL命令插入到Web表單的輸入域頁面請求的查詢字元串中，如果要對一個網站進行SQL注入攻擊，首先需要找到存在SQL注入漏洞的地方