Usually **PKCS7** is used, which generates a padding **repeating** the **number** of **bytes****needed** to **complete** the block. For example, if the last block is missing 3 bytes, the padding will be `\x03\x03\x03`.
When an application decrypts encrypted data, it will first decrypt the data; then it will remove the padding. During the cleanup of the padding, **if **an **invalid****padding **triggers a detectable **behaviour**, you have a **padding oracle vulnerability**. The detectable behaviour can be an **error**, a **lack **of **results**, or a **slower response**.
You could also **abuse **this **vulnerability **to **encrypt new data**. For example, imagine that the content of the cookie is "_user=MyUsername_", then you may change it to "_**user=administrator**_" and escalate privileges inside the application. You could also do it using `paduster`specifying the** -plaintext** parameter:
If the site is vulnerable `padbuster`will automatically try to find when the padding error occurs, but you can also indicating the error message it using the **-error** parameter.
In **summary**, you can start decrypting the encrypted data by **guessing **the correct **values **that can be used to **create **all the **different paddings**. Then, the padding oracle attack will start **decrypting **bytes **from **the **end **to the start by **guessing **which will be the correct **value **that **creates a padding of 1, 2, 3, etc**.
Imagine you have some encrypted text that occupies **2 blocks** formed by the bytes from **E0 to E15**.\
In order to **decrypt** the **last****block** (**E8** to **E15**), the whole block passes through the "block cipher decryption" generating the** intermediary bytes I0 to I15**.\
Finally, each intermediary byte is **XORed** with the previous encrypted bytes (E0 to E7). So:
This BF is as complex as the previous one as it's possible to calculate the the `E''15` whose value is 0x02: `E''7 = \x02 ^ I15` so it's just needed to find the **`E'14`** that generates a **`C14` equals to `0x02`**.\
If you **log in many times** and always get the **same cookie**, there is probably **something****wrong** in the application. The **cookie sent back should be unique** each time you log in. If the cookie is **always** the **same**, it will probably always be valid and there **won't be anyway to invalidate i**t.
Now, if you try to **modify** the **cookie**, you can see that you get an **error** from the application.\
But if you BF the padding (using padbuster for example) you manage to get another cookie valid for a different user. This scenario is highly probably vulnerable to padbuster.