***使用的幾種常見***方式

SQL注入

• SQL注入，就是經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

• 而SQL***就是在用戶輸入數據特徵的時候，注入一些特殊的指令來破壞本來的SQL語句查詢功能，從而使得一些功能失效或者查詢到原本沒法查詢到的重
  要數據。

跨站腳本***(XSS)

• 跨站腳本***（XSS，Cross-site scripting）是最多見和基本的***WEB網站的方法。***者在網頁上發佈包含***性代碼的數據。當瀏覽者看到此網頁時，特定的腳本就會以瀏覽者用戶的身份和權限來執行。經過XSS能夠比較容易地修改用戶數據、竊取用戶信息，以及形成其它類型的***，例如CSRF***。
  常看法決辦法:確保輸出到HTML頁面的數據以HTML的方式被轉義

出錯的頁面的漏洞也可能形成XSS***.好比頁面/gift/giftList.htm?page=2找不到,出錯頁面直接把該url原樣輸出,若是***者在url後面加上***代碼發給受害者,就有可能出現XSS***

跨站請求僞造***（CSRF)

跨站請求僞造（CSRF，Cross-site request forgery）是另外一種常見的***。***者經過各類方法僞造一個請求，模仿用戶提交表單的行爲，從而達到修改用戶的數據，或者執行特定任務的目的。爲了假冒用戶的身份，CSRF***經常和XSS***配合起來作，但也能夠經過其它手段，例如誘使用戶點擊一個包含***的連接

解決的思路有:

採用POST請求,增長***的難度.用戶點擊一個連接就能夠發起GET類型的請求。而POST請求相對比較難，***者每每須要藉助JavaScript才能實現
對請求進行認證，確保該請求確實是用戶本人填寫表單並提交的，而不是第三者僞造的.具體能夠在會話中增長token,確保看到信息和提交信息的是同一我的
與XSS***相比，CSRF***每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。

網頁***

網頁***的防禦

• 網頁***的防範只靠殺毒軟件和防火牆是遠遠不夠的，由於一旦***使用了反彈端口的我的版***（我的反彙編的一些殺毒軟件沒法識別的***），那麼殺毒軟件和防火牆就迫不得已，因此，網頁***的防範要從它的原理入手，從根子上進行防範。

• 安裝補丁 更名或卸載（反註冊）最不安全的ActiveXObject（IE插件）

• 在系統中有些ActiveXObject會運行EXE程序，好比本文中「自動運行程序」代碼中的Shell.application控件，這些控件一旦在網頁中得到了執行權限，那麼它就會變爲***運行的「溫牀」，因此把這些控件更名或卸載能完全防範利用這些控件的網頁***。可是ActiveXObject是爲了應用而出現的，而不是爲了***而出現的，全部的控件都有它的用處，因此在更名或卸載一個控件以前，你必須確認這個控件是你不須要的，或者即便卸載了也不關大致的。
  重定向***

• 一種經常使用的***手段是「釣魚」。釣魚***者，一般會發送給受害者一個合法連接，當連接被點擊時，用戶被導向一個似是而非的非法網站，從而達到騙取用戶信任、竊取用戶資料的目的。爲防止這種行爲,咱們必須對全部的重定向操做進行審覈,以免重定向到一個危險的地方.常看法決方案是白名單,將合法的要重定向的url加到白名單中,非白名單上的域名重定向時拒之,第二種解決方案是重定向token,在合法的url上加上token,重定向時進行驗證.
  卸載（反註冊）ActiveXObject過程以下：

• 第一步：在「開始」菜單上單擊「運行」，輸入「CMD」命令打開命令提示符窗口。
• 第二步：在命令提示符下輸入「regsvr32.exe shell32.dll
• /u/s」，而後回車就能將Shell.application控件卸載。若是往後咱們但願繼續使用這個控件的話，能夠在命令提示符窗口中輸入「regsvr32.exe shell32.dll/i/s」命令將它們從新安裝（註冊）。在上述命令中：「regsvr32.exe」是註冊或反註冊OLE對象或控件的命令，[/u]是反註冊參數，[/s]是寂靜模式參數，[/I]爲安裝參數。
  更名

須要說明的是，更名一個控件時，控件的名稱和CLSID（Class
ID）都要改，而且要改完全。下面仍以Shell.application爲例來介紹方法。

• 第一步：打開註冊表編輯器，查找「Shell.application」。用這個方法能找到兩個註冊表項：「{13709620-C279-11CE-A49E-444553540000}」和「Shell.application」。
• 第二步：把{13709620-C279-11CE-A49E-444553540000}改成{13709620-C279-11CE-A49E-444553540001}，注意，不要和系統中的其它CLSID重複。
• 第三步：把「Shell.application」更名爲「Shell.application_xxx」。之後用到這個控件的時候你使用這個名稱就能夠正常調用此控件了。
  安全級別

有些網馬只要調高IE的安全級別，或者禁用腳本，該網頁***就不起做用了。從***的***原理咱們能夠看出，網頁***是利用IE腳本和ActiveX控件上的一些漏洞下載和運行***的，只要咱們禁用了腳本和ActiveX控件，就能夠防止***的下載和運行。

小提示：禁用腳本和ActiveX控件會使一些網頁的功能和效果失去做用，因此是否禁用，你要根據本身對安全的須要來定。

• 第一步：在IE瀏覽器的菜單欄上選擇「工具→Internet選項」打開「Internet選項」對話框。

• 第二步：在「安全」選項卡上，在Internet和本地Internet區域，分別把滑塊移動到最高，或者點擊「自定義級別」，在打開的對話框上禁用腳本，禁用ActiveX控件。
  DOS***和CC***的區別

• 不少朋友都知道木桶理論，一桶水的最大容量不是由它最高的地方決定的，而是由它最低的地方決定，服務器也是同樣，服務器的安全性也是由它最脆弱的地方決定的，最脆弱的地方有多危險服務器就有多危險。DDOS也是同樣，只要你的服務器存在一個很耗資源的地方，限制又不夠，就立刻成爲別人DDOS的對象。好比SYN-FLOOD，它就是利用服務器的半鏈接狀態比徹底鏈接狀態更耗資源，而SYN發動方只須要不停的發包，根本不須要多少資源。

• 一個好的DDOS***必須是經過本身極少資源的消耗帶來對方較大的資源消耗，不然好比ICMP-FLOOD和UDP-FLOOD都必須和別人同樣大的帶寬，對方服務器消耗多少資源本身也得賠上多少資源，效率極其低下，又很容易被人發現，如今基本沒有什麼人用了。
  ***原理

• CC主要是用來***頁面的。你們都有這樣的經歷，就是在訪問論壇時，若是這個論壇比較大，訪問的人比較多，打開頁面的速度會比較慢，對不？！通常來講，訪問的人越多，論壇的頁面越多，數據庫就越大，被訪問的頻率也越高，佔用的系統資源也就至關可觀，如今知道爲何不少空間服務商都說你們不要上傳論壇，聊天室等東西了吧。
• 一個靜態頁面不須要服務器多少資源，甚至能夠說直接從內存中讀出來發給你就能夠了，可是論壇就不同了，我看一個帖子，系統須要到數據庫中判斷我是否有讀帖子的權限，若是有，就讀出帖子裏面的內容，顯示出來——這裏至少訪問了2次數據庫，若是數據庫的體積有200MB大小，系統極可能就要在這200MB大小的數據空間搜索一遍，這須要多少的CPU資源和時間？若是我是查找一個關鍵字，那麼時間更加可觀，由於前面的搜索能夠限定在一個很小的範圍內，好比用戶權限只查用戶表，帖子內容只查帖子表，並且查到就能夠立刻中止查詢，而搜索確定會對全部的數據進行一次判斷，消耗的時間是至關的大。CC就是充分利用了這個特色，模擬多個用戶（多少線程就是多少用戶）不停的進行訪問（訪問那些須要大量數據操做，就是須要大量CPU時間的頁面）。不少朋友問到，爲何要使用代理呢？由於代理能夠有效地隱藏本身的身份，也能夠繞開全部的防火牆，由於基本上全部的防火牆都會檢測併發的TCP/IP鏈接數目，超過必定數目必定頻率就會被認爲是Connection-Flood。
• 　　使用代理***還能很好的保持鏈接，咱們這裏發送了數據，代理幫咱們轉發給對方服務器，咱們就能夠立刻斷開，代理還會繼續保持着和對方鏈接（我知道的記錄是有人利用2000個代理產生了35萬併發鏈接）。
  加深理解：

咱們假設服務器A對Search.asp的處理時間須要0.01S（多線程只是時間分割，對結論沒有影響），也就是說他一秒能夠保證100個用戶的Search請求，服務器容許的最大鏈接時間爲60s，那麼咱們使用CC模擬120個用戶併發鏈接，那麼通過1分鐘，服務器被請求了7200次，處理了6000次，因而剩下了1200個併發鏈接沒有被處理。有的朋友會說：丟鏈接！丟鏈接！問題是服務器是按先來後到的順序丟的，這1200個是在最後10秒的時候發起的，想丟？！還早，通過計算，服務器滿負開始丟鏈接的時候，應該是有7200個併發鏈接存在隊列，而後服務器開始120個/秒的丟鏈接，咱們發動的鏈接也是120個/秒，服務器永遠有處理不完的鏈接，服務器的CPU100%並長時間保持，而後丟鏈接的60秒服務器也判斷處理不過來了，新的鏈接也處理不了，這樣服務器達到了超級繁忙狀態。　　咱們假設服務器處理Search只用了0.01S，也就是10毫秒（這個速度你能夠去各個有開放時間顯示的論壇看看），咱們使用的線程也只有120，不少服務器的丟鏈接時間遠比60S長，咱們的使用線程遠比120多，能夠想象可怕了吧，並且客戶機只要發送了斷開，鏈接的保持是代理作的，並且當服務器收到SQL請求，確定會進入隊列，不論鏈接是否已經斷開，並且服務器是併發的，不是順序執行，這樣使得更多的請求進入內存請求，對服務器負擔更大。　>固然，CC也能夠利用這種方法對FTP進行***，也能夠實現TCP-FLOOD，這些都是通過測試有效的。