當你打開百度新聞搜索“黑客”關鍵字時能看到什么?沒錯，有太多知名的網站被黑客攻破，有太多牛X的IT系統對黑客來說如入無人之境……
進入WEB2.0時代，我們的IT當真變得如此脆弱了嗎?記得在一次有關安全的研討會上，有專家談到了這樣的觀點：互聯網在設計之初，也沒能預想到互聯網會發展成現在的龐大規模，如果互聯網依然只應用于教育網、科研網，就不會有這么多的問題，難道我們真得需要在重新織一張網?雖然這只是一種假設，也可能是未來創新的一個星星之火，但在現階段，還是讓我們收回思想的翅膀，來解決實際中的問題吧!
網站安全在經歷了2011年底的泄密門之后，得到了各方面的重視，互聯網企業開始重新審視自身的安全性、安全廠商開始更多的關注這方面的問題并推出了相應的解決方案、政府也在從法律法規方面對網站安全進行了相關的規定(未證實消息：中國的薩班斯法案在今年也將出臺)。
近日，小編從國內知名的漏洞報告平臺WooYun.org上得到了以下幾張圖，圖中標注的是各企業網站所存在的漏洞類型和造成系統漏洞的主要原因：
從上圖我們可以不難找出企業網站存在安全風險的幾個同共點：XSS跨站腳本攻擊、SQL注入漏洞、后臺弱口令、系統/服務運維配置不當以及系統/服務補丁不及時……下面我們就從這主要的幾點開始和大家一起探討：
1、 XSS跨站腳本攻擊
上圖所列出的互聯網企業有門戶網站、行業網站、視頻網站、旅游網站等，從不同類型的網站我們可以看出，XSS跨站腳本攻擊是黑客使用最普遍的攻擊方式，這里我們為大家整理了XSS跨站腳本攻擊的原理，希望能對大家有幫助。
小白一下：XSS又叫CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的html代碼會被執行，從而達到惡意用戶的特殊目的。XSS屬于被動式的攻擊，因為其被動且不好利用，所以許多人常呼略其危害性。
跨站腳本攻擊最大的魅力是通過HTML注入劫持用戶的瀏覽器，任意構造用戶當前瀏覽的HTML內容，甚至可以模擬用戶當前的操作。這里介紹一種新式攻擊方法：XSS Phishing(跨站腳本釣魚攻擊)，利用這種方式可以直接盜取用戶的密碼，下面我就拿最近PHPWIND論壇所暴出的XSS做一下演示，PHPWIND對上傳文件名沒有處理嚴格，導致可以寫入跨站腳本。
先做一個簡單的測試，發一篇新帖，在附件中隨意寫入一個本地路徑加帶“<” 和“>”的文件名，如圖一
發帖成功后我們會發現，帖子附件名已經沒有了，如圖二
我們查看當前頁面的源代碼會發現已經寫到頁面內，如圖三
當然要寫入腳本，PHPWIND還是做了限制，文件名中出現"(","/"字符將會被過濾，不過可以利用HTML轉碼的方式繞過這個限制，如轉換成
>
這樣我們已經實現了跨站腳本的寫入，關鍵是怎么實現攻擊，這一處跨站腳本漏洞進行了HTML轉碼，我們不方便寫入過長的內容，那么就加載一個JS文件，動態創建一個script標記，代碼如下：
>
OK,到了這一步我們就可以在JS中任意構造我們的攻擊代碼，攻擊的思路是當用戶訪問帖子，利用腳本清空當前頁面，然后重新寫成釣魚頁面。
首先我們可以實驗一下，javacript有一個小特性,延時輸出將會清空當前頁面所有的內容，代碼如下：
function Phish(){
info = "我是來釣魚的！"
document.write(info);
}
function doit(){
setTimeout("Phish()", 1000 );
}doit()
如圖四，帖子頁面的代碼和內容全變成了“我是來釣魚的!”
想一想，如果我們把info變量的內容變成HTML代碼會怎樣，如圖五
嘿嘿，邪惡一點!我們完全可以把頁面變成一個自己操縱的登錄頁面，將表單的值指向遠程服務器上的程序，如圖六
然后遠程服務器上的程序將接受表單POST的用戶和密碼，當然我們可以做巧妙點，讓其訪問后又轉跳回論壇首頁，代碼如下：
最后我們便完成了釣魚的過程，管理員訪問我們的帖子，馬上重寫當前頁面，設置一個重新登錄的陷阱，盜取用戶名和密碼，全部過程只在沒有察覺的一瞬間.
這類攻擊方式危害很大，文中的原始代碼只是描敘一下思路，有很多破綻，當然如果你夠邪惡的話，完全可以自己重寫代碼，釣魚于無形之中。
提醒一下，跨站腳本不僅僅是簡單的掛馬，XSS Phishing(跨站腳本釣魚攻擊)只是一個簡單的開始!
2、 SQL注入漏洞
SQL注入漏洞的產生原因是網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，導致應用程序存在安全隱患。SQL注入漏洞攻擊的就是利用現有應用程序沒有對用戶輸入數據的合法性進行判斷，將惡意的SQL命令注入到后臺數據庫引擎執行的黑客攻擊手段。
下面總結了一位開發者對預防SQL注入的幾點建議：
開發者的觀點：SQL注入攻擊的本質是讓客戶端傳遞過去的字符串變成SQL語句，而且能夠被執行;每個程序員都必須肩負起防止SQL注入攻擊的責任。
說起防止SQL注入攻擊，感覺很郁悶，這么多年了大家一直在討論，也一直在爭論，可是到了現在似乎還是沒有定論。當不知道注入原理的時候會覺得很神奇，怎么就被注入了呢?會覺得很難預防。但是當知道了注入原理之后預防不就是很簡單的事情了嗎?
第一次聽說SQL注入攻擊的時候還是在2004年(好像得知的比較晚)，那是還是在寫asp呢。在一次寫代碼的時候，有同事問我，你的這段代碼防注入攻擊了嗎?什么攻擊?這是什么呀。后來到網上各種找，終于弄明白了是怎么攻擊進來的了。注入攻擊都是來自于客戶端，無論是表單提交、URL傳值還是Cookie等，其實原理都是一樣的。到了服務器端可以分成三種情況：數字、日期時間、字符串。
(1)、數字。
如何注入?
假設我們要實現一個顯示新聞的頁面，我們可能會隨手寫下下面的代碼：
string id = Request.QueryString["id"];
string sql = "select * from news where ColID=" + id;
如果傳遞過來的 id是我們想像的 數字(比如168)，那么自然不會有什么問題。但是如果傳遞過來的id是“168 delete from table ”的話，那么sql的值就變成了“select * from table where ColID=168 delete from news”。對于SQL Server來說是支持一次提交多條SQL語句的，這個為我們提供了方便之余也為SQL注入敞開了大門。顯然如果這條SQL語句被執行的話，那么news表里的記錄就都沒有了。
那么如何預防呢?很簡單，因為ColID字段的類型是int的，那么我們只需要驗證一下傳遞過來的id是不是整數就可以了。是整數就不存在注入;如果不是那么就有可能存在注入。即使不存在注入，把一個不是整數的id拼接進去也會造成執行錯誤。所以說不管是不是為了預防SQL注入，也都應該驗證id是不是整數。
驗證方法嘛，可以用TryParse，可以用正則，也可以自己寫函數驗證。但是不建議用try異常的方式，因為這個有效率問題。
這里還有一個特殊情況，就是對于批量刪除這類的會傳遞過來多個數字，比如“1，2，3，10”，這個也需要驗證一下，萬一有人利用這個漏洞呢。至于驗證方法也很簡單，自己寫個函數就ok了。
(2)、日期時間
這個和數字的情況是一樣的，驗證是不是日期時間即可。
(3)、字符串
最麻煩、爭議最大的就是這個了。
先看一下如何注入，比如我們先要按照新聞標題來進行查詢，可能寫的代碼：
string key = txtTitle.Text;
string sql = "select * from news where title like '%" + key + "%'";
這個又是如何注入的呢?我想先問大家一個問題：如果key的值永遠都不會包含單引號，那么會不會被注入進來?
那么用了單引號又是如何注入的呢?假設key=" ' delete from news --" ，那么sql的值就是“ select * from news where title like '%' delete from news -- ' ”。
先用一個單引號和前面的單引號組成一對封閉的單引號，這一對單引號內部('%')就作為字符串處理，而外面的就被作為SQL語句處理，而第二個單引號被 “--”給注釋掉了，這樣就保證了整個sql語句的正確性。
這是注入的一種方法，那么如何來防止呢?想想剛才的問題，如果沒有單引號是不是就天下太平了呢?對于這種情況(前面的“數字”的情況不算)，到目前為止我是沒發現不用單引號，還能夠注入進來的方法。也許是我孤陋寡聞吧，不知道各位高手是否知道對于這種情況，不用單引號還能注入進來的方法。
既然找到了罪魁禍首，那么就好辦了，把單引號干掉就ok了。key = key.Replace("'", "''");這時候sql的值就是” select * from news where title like '%'' delete from news --'”。
對于SQL 來說在一對單引號內部的兩個單引號表示一個字符串形式的單引號。這樣我們就把罪魁禍首改造成了字符串了。在一對單引號內的“--”也是普通的字符串而不代表注釋。
罪魁禍首是單引號，想不明白為什么有許多人都去過濾 “delete、update”這一類的關鍵字，他們都是安善良民呀，他們是很冤枉的。當然了，如果前提是程序都已經寫好了，不能修改內部代碼，那就另當別論了。至于“--”頂多算是幫兇，如果您不放心的話，把他處理了也行。
總結：數字、日期時間的，驗證類型;字符串的，處理好單引號。另外為了安全起見，不要用sa連接數據庫，xp_cmdshell這一類的有危險的擴展存儲過程也應該處理一下(比如刪除)。
3、其他需要關注的……
從第一頁給出的那張圖中，大家也許能看出些不同。沒錯，有的互聯網企業在系統/服務運維方面做的非常好，比如門戶網站的百度、騰訊;也有的互聯網企業在系統/服務運維上就差勁了許多。關于系統運維，各位都是大牛，小編就不在這里班門弄斧了。
京公網安備 11010502049343號