簡介
重放攻擊它是一種攻擊類型，這種攻擊會不斷惡意或欺詐性地重複一個有效的數據傳輸，重放攻擊可以由發起者，也可以由攔截並重發該數據的敵方進行。攻擊者利用網路監聽或者其他方式盜取認證憑據，之後再把它重新發給認證伺服器。從這個解釋上理解，加密可以有效防止會話劫持，但是卻防止不了重放攻擊。重放攻擊任何網路通訊過程中都可能發生。重放攻擊是計算機世界黑客常用的攻擊方式之一，它的書面定義對不了解密碼學的人來說比較抽象。
類型
根據訊息來源
1.協定輪內攻擊：一個協定輪內訊息重放2.協定輪外攻擊：一個協定不同輪次訊息重放根據訊息去向
1.偏轉攻擊：改變訊息的去向2.直接攻擊：將訊息傳送給意定接收方
偏轉攻擊分為
1.反射攻擊：將訊息返回給傳送者2.第三方攻擊：將訊息發給協定合法通信雙方之外的任一方
詳情
攻擊內容
重放攻擊是計算機世界黑客常用的攻擊方式之一，所謂重放攻擊就是攻擊者傳送一個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程。為了抵禦重放攻擊，現在的身份認證一般採用“挑戰應答”（Challenge/Response）方式。
用戶 系統
-----申請登入----〉
〈---傳送挑戰值----
客戶端計算相應的應答值
（可以用MD5算法計算應答值）
------傳送應答值--〉
系統通過同樣的算法
判斷應答值是否正確
〈---通過認證（正確）--
不正確則下線
這裡要注意的是挑戰值得熵值必須大（變化量要很大，一般為隨機數），若挑戰值變化量不大，攻擊者只需截獲足夠的挑戰應答關係，就可以進行重放攻擊了。（具體“挑戰應答”方式流程可見HMAC算法套用）
典型例子
重放攻擊與cookie我們監聽http數據傳輸的截獲的敏感數據大多數就是存放在cookie中的數據。其實在web安全中的通過其他方式（非網路監聽）盜取cookie與提交cookie也是一種重放攻擊。我們有時候可以輕鬆的複製別人的cookie直接獲得相應的許可權。關於cookie，我想應該用單獨的一篇文章來說明，在這裡就不重複了。
防禦方案
時間戳
“時戳”──代表當前時刻的數基本思想──A接收一個訊息若且唯若其包含一個對A而言足夠接近當前時刻的時戳
原理──重放的時戳將相對遠離當前時刻
時鐘要求──通信各方的計算機時鐘保持同步
處理方式──設定大小適當的時間窗（間隔），越大越能包容網路傳輸延時，越小越能防重放攻擊
適用性──用於非連線性的對話（在連線情形下雙方時鐘若偶然出現不同步，則正確的信息可能會被誤判為重放信息而丟棄，而錯誤的重放信息可能會當作最新信息而接收）
序號
通信雙方通過訊息中的序列號來判斷訊息的新鮮性要求通信雙方必須事先協商一個初始序列號，並協商遞增方法
提問與應答
“現時”──與當前事件有關的一次性隨機數N（互不重複即可）基本做法──期望從B獲得訊息的A 事先發給B一個現時N，並要求B應答的訊息中包含N或f(N)，f是A、B預先約定的簡單函式
原理──A通過B回復的N或f(N)與自己發出是否一致來判定本次訊息是不是重放的
時鐘要求──無
適用性──用於連線性的對話
重放攻擊是對協定的攻擊中危害最大、最常見的一種攻擊形式。
會話劫持
劫持原理
可以把會話劫持攻擊分為兩種類型：1、中間人攻擊(Man In The Middle，簡稱MITM)；2、注射式攻擊（Injection）；
並且還可以把會話劫持攻擊分為兩種形式：
1、被動劫持，
2、主動劫持；被動劫持實際上就是在後台監視雙方會話的數據流，從中獲得敏感數據；而主動劫持則是將會話當中的某一台主機"踢"下線，然後由攻擊者取代並接管會話。
TCP劫持
如果劫持一些不可靠的協定，那將輕而易舉，因為它們沒有提供一些認證措施；而TCP協定被欲為是可靠的傳輸協定，所以要重點討論它。根據TCP/IP中的規定，使用TCP協定進行通訊需要提供兩段序列號，TCP協定使用這兩段序列號確保連線同步以及安全通訊，系統的TCP/IP協定棧依據時間或線性的產生這些值。在通訊過程中，雙方的序列號是相互依賴的，這也就是為什麼稱TCP協定是可靠的傳輸協定（具體可參見RFC 793）。如果攻擊者在這個時候進行會話劫持，結果肯定是失敗，因為會話雙方"不認識"攻擊者，攻擊者不能提供合法的序列號；所以，會話劫持的關鍵是預測正確的序列號，攻擊者可以採取嗅探技術獲得這些信息。
TCP協定的序列號
現在來討論一下有關TCP協定的序列號的相關問題。在每一個數據包中，都有兩段序列號，它們分別為：
SEQ：當前數據包中的第一個位元組的序號
ACK：期望收到對方數據包中第一個位元組的序號
假設雙方現在需要進行一次連線：
S_SEQ：將要傳送的下一個位元組的序號
S_ACK：將要接收的下一個位元組的序號
S_WIND：接收視窗
//以上為伺服器（Server）
C_SEQ：將要傳送的下一個位元組的序號
C_ACK：將要接收的下一個位元組的序號
C_WIND：接收視窗
//以上為客戶端（Client）
它們之間必須符合下面的邏輯關係，否則該數據包會被丟棄，並且返回一個ACK包（包含期望的序列號）。
C_ACK <= C_SEQ <= C_ACK + C_WIND
S_ACK <= S_SEQ <= S_ACK + S_WIND
如果不符合上邊的邏輯關係，就會引申出一個"致命弱點"。
這個致命的弱點就是ACK風暴(Storm)。當會話雙方接收到一個不期望的數據包後，就會用自己期望的序列號返回ACK包；而在另一端，這個數據包也不是所期望的，就會再次以自己期望的序列號返回ACK包……於是，就這樣來回往返，形成了惡性循環，最終導致ACK風暴。比較好的解決辦法是先進行ARP欺騙，使雙方的數據包"正常"的傳送到攻擊者這裡，然後設定包轉發，最後就可以進行會話劫持了，而且不必擔心會有ACK風暴出現。當然，並不是所有系統都會出現ACK風暴。比如Linux系統的TCP/IP協定棧就與RFC中的描述略有不同。注意，ACK風暴僅存在於注射式會話劫持。
TCP會話劫持過程
假設主機A和主機B進行一次TCP會話，C為攻擊者，劫持過程如下：
A向B傳送一個數據包
SEQ(hex):XACK(hex):Y
FLAGS:-AP---Window:ZZZZ，包大小為:60
B回應A一個數據包
SEQ(hex):YACK(hex):X+60
FLAGS:-AP---Window:ZZZZ，包大小為:50
A向B回應一個數據包
SEQ(hex):X+60ACK(hex):Y+50
FLAGS:-AP---Window:ZZZZ，包大小為:40
B向A回應一個數據包
SEQ(hex):Y+50ACK(hex):X+100
FLAGS:-AP---Window:ZZZZ，包大小為:30
攻擊者C冒充主機A給主機B傳送一個數據包
SEQ(hex):X+100ACK(hex):Y+80
FLAGS:-AP---Window:ZZZZ，包大小為:20
B向A回應一個數據包
SEQ(hex):Y+80ACK(hex):X+120
FLAGS:-AP---Window:ZZZZ，包大小為:10
現在，主機B執行了攻擊者C冒充主機A傳送過來的命令，並且返回給主機A一個數據包；但是，主機A並不能識別主機B傳送過來的數據包，所以主機A會以期望的序列號返回給主機B一個數據包，隨即形成ACK風暴。如果成功的解決了ACK風暴（例如前邊提到的ARP欺騙或者其他方式），就可以成功進行會話劫持了。
HTTP劫持
Web應用程式是通過2種方式來判斷和跟蹤不同用戶的：Cookie或者Session（也叫做會話型Cookie）。其中Cookie是存儲在本地計算機上的，過期時間很長，所以針對Cookie的攻擊手段一般是盜取用戶Cookie然後偽造Cookie冒充該用戶；而Session由於其存在於服務端，隨著會話的註銷而失效（很快過期），往往難於利用。所以一般來說Session認證較之Cookie認證安全。會話型cookie也是可以通過程式獲得的，換句話說我們進行TCP會話劫持的時候如果針對http會話劫持的話可以截獲所有http內容包括Session信息。
