貴賓犬填充多個塊？
我對這個主題很陌生，並且閱讀了一些關於貴賓犬和填充甲骨文的資訊。
我非常理解“正常”填充預言攻擊，用 block(n-1) 的最後一個字節來確定 block(n) 的最後一個字節 - 最後一個字節用“myguess” XOR 0x01 等等。
然而關於貴賓犬的文章指出，攻擊是基於放置我的目標塊來替換填充。由於未檢查填充，如果我替換的最後一個字節恰好是填充的長度，伺服器將接受該消息，因為伺服器將正確切割填充並能夠檢查 MAC。
現在，正如這裡所說，總是有 padding，否則你無法知道，如果消息恰好適合塊。
我理解貴賓犬是這樣工作的：
- 我用 javascript 偽造請求，迫使受害者的瀏覽器複製加密的 sessioncookie-block 作為填充
- 我最多創建 256 個這些請求，將我的 cookie 塊進一步向下移動，從而創建越來越長的填充，直到伺服器接受請求，告訴我解密的最後一個字節是偽造填充中最後一個字節的位置
- 我“寫下”最後一個字節，刪除它並用倒數第二個字節重複該過程，依此類推。
如果我的 sessioncookie 的最後一個字節現在恰好是 FF，則需要 255 字節長度的填充，這是多個填充塊。
sslv3.0 實現是否會接受我填充的內容超出了合理必要的範圍？
還是我誤解了這個概念？我還沒有找到一篇真正詳細解釋的文章。
我很高興有詳細的技術描述、影片的連結，最重要的是，如果它不正確，可以在我對過程的描述中進行簡單的更正。
如果塊中的最後一個字節大於塊大小，則會在 SSL 3.0 中產生填充錯誤。
SSL 3.0 填充高達 $ BlockSize-1 $ 未指定數據的字節，以及填充長度的一個字節（不包括長度字節本身）。TLS 1.0 及更高版本允許填充比塊大小更長，並且要求每個字節都包含長度。POODLE 攻擊針對 3.0（降級連接後）。
在 POODLE 攻擊中，你需要安排兩件事，消息（加上 MAC）的長度正好是塊大小的倍數，並且你想找出的字節被移動到塊中的最後一個字節。
如果您將填充塊替換為具有所需字節的塊，它偶爾會（256 中的 1 個）解碼為 15（對於 128 位塊大小），並且消息將被接受（因為填充字節現在導致正確的 MAC，位於前一個塊的末尾）。如果不被接受，則生成一條新的加密消息並重試（這將隨機更改最後一個字節解碼為的任何或全部新密鑰、新 IV 或明文中任何更改的欄位）。
如果你取最後一個字節，將它與前一個塊的密文的最後一個字節進行異或，然後再與該塊的原始位置之前的密文的最後一個字節進行異或，你將得到那個字節的正確值。
Repeat after manipulating the plaintext so that another (unknown) byte is in the last byte of a block (without changing the required padding amount).
An earlier version of my answer was describing a Padding Oracle attack against PKCS#7 style padding, which relies on being able to distinguish between a padding error and a MAC error, the POODLE attack distinguishes between error and no error.
With TLS, padding can be longer than one block, and the implementation shouldn’t distinguish between padding and MAC errors, but it’s still susceptible to timing attacks, even if it calculates a MAC after detecting a padding error.