Update README.md

pentesting-web/hacking-with-cookies/README.md

@@ -18,7 +18,7 @@
 
 ## Hacking cookies
 
-If you find some kind of custom cookie containing sensitive data (sessionID, username, emails...) you should definitely try to exploit it
+If you find some kind of custom cookie containing sensitive data (sessionID, username, emails, etc.) you should definitely try to exploit it
 
 ### Decoding the cookie
 
@@ -30,9 +30,9 @@ Steal a cookie and use it to impersonate the user inside an application
 
 ### Session fixation
 
-The attacker get a cookie from a web page and send to the victim a link so the **victim logins using the cookie of the attacker**. If the cookie is not changed when a user logs in, this could be useful because the attacker could be able to impersonate the user using the cookie.
+The attacker gets a cookie from a web page and sends a link to the victim to **login using the very same cookie**. If the cookie is not changed when a user logs in, this could be useful because the attacker could be able to impersonate the user through a cookie.
 
-If you found a **XSS in a subdomain** or you **control a subdomain**, read:
+If you found an **XSS in a subdomain** or you **control a subdomain**, read:
 
 {% content-ref url="cookie-tossing.md" %}
 [cookie-tossing.md](cookie-tossing.md)
@@ -40,9 +40,9 @@ If you found a **XSS in a subdomain** or you **control a subdomain**, read:
 
 ### Session donation
 
-The attacker sends his own session to the victim. The victim will see that he is already loged and will suppose that he is inside his own account but **the actions will be performed inside the attackers account**.
+The attacker sends his own session to the victim. The victim will see that he is already logged in and will suppose that he is inside his account but **the actions will be performed inside the attacker's account**.
 
-If you found a **XSS in a subdomain** or you **control a subdomain**, read:
+If you found an **XSS in a subdomain** or you **control a subdomain**, read:
 
 {% content-ref url="cookie-tossing.md" %}
 [cookie-tossing.md](cookie-tossing.md)
@@ -56,20 +56,20 @@ Click on the previous link to access a page explaining possible flaws in JWT.
 
 #### **Basic checks**
 
-* The **cookie** are the **same** every time you **login**
-* Log out and try to use the same cookie
-* Try to login with 2 devices (or browsers) to the same account using the same cookie
+* The **cookie** is the **same** every time you **login**.
+* Log out and try to use the same cookie.
+* Try to log in with 2 devices (or browsers) to the same account using the same cookie.
 * Check if the cookie has any information in it and try to modify it
 * Try to create several accounts with almost the same username and check if you can see similarities.
-* Check "**remember me**" option if it exists and check how does it works. If it exists and could be vulnerable, always use the cookie of **remember me** without any other cookie.
-* If you change the password and previous cookie still works
+* Check the "**remember me**" option if it exists to see how it works. If it exists and could be vulnerable, always use the cookie of **remember me** without any other cookie.
+* Check if the previous cookie works even after you change the password.
 
 #### **Advanced cookies attacks**
 
 If the cookie remains the same (or almost) when you log in, this probably means that the cookie is related to some field of your account (probably the username). Then you can:
 
-* Try to create a lot of **accounts** with usernames very **similar** and try to **guess** how is working the algorithm
-* Try to **bruteforce the username**. If the cookie saves only as authentication method your username, then you can create an account with username "**Bmin**" and **bruteforce** every single **bit** of your cookie because one of the cookies that you will try will the one belonging to "**admin**".
+* Try to create a lot of **accounts** with usernames very **similar** and try to **guess** how the algorithm is working.
+* Try to **bruteforce the username**. If the cookie saves only as an authentication method for your username, then you can create an account with username "**Bmin**" and **bruteforce** every single **bit** of your cookie because one of the cookies that you will try will the one belonging to "**admin**".
 * Try **Padding** **Oracle** (you can decrypt the content of the cookie). Use **padbuster**.
 
 **Padding Oracle - Padbuster examples**
@@ -109,15 +109,15 @@ Maybe a cookie could have some value and could be signed using CBC. Then, the in
 **ECB**
 
 If the cookie is encrypted using ECB it could be vulnerable.\
-When you login the cookie that you receive has to be always the same.
+When you log in the cookie that you receive has to be always the same.
 
 **How to detect and attack:**
 
-Create 2 users with almost the same data (username, password, email...) and try to discover some pattern inside the given cookie
+Create 2 users with almost the same data (username, password, email, etc.) and try to discover some pattern inside the given cookie
 
-Create a user called form example "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).
+Create a user called for example "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).
 
-There should be a pattern (with the size of a used block). So, knowing how are a bunch of "a" encrypted you can create a username: "a"\*(size of block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "admin".
+There should be a pattern (with the size of a used block). So, knowing how are a bunch of "a" encrypted you can create a username: "a"\*(size of the block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "admin".
 
 ## Cookies Attributes
 
@@ -134,13 +134,13 @@ For example, if you set `Domain=mozilla.org`, cookies are available on subdomain
 
 ### **Path**
 
-The `Path` attribute indicates a **URL path that must exist in the requested URL in order to send the `Cookie` header**. The `%x2F` ("/") character is considered a directory separator, and subdirectories match as well.
+The `Path` attribute indicates a **URL path that must exist in the requested URL to send the `Cookie` header**. The `%x2F` ("/") character is considered a directory separator, and subdirectories match as well.
 
 ### SameSite
 
-This will indicate the browser if the **cookie** can be sent **from other domains**. It has 3 possible values:
+This will indicate to the browser if the **cookie** can be sent **from other domains**. It has 3 possible values:
 
-* **Strict**: The cookie will not be sent along with request by third party websites.
+* **Strict**: The cookie will not be sent along with a request by third party websites.
 * **Lax**: The cookie will be sent along with the GET request initiated by third party websites.
 * **None**: The cookie is sent from any third party domain
 
@@ -169,7 +169,7 @@ This avoids the **client** to access the cookie (Via **Javascript** for example:
 #### **Bypasses**
 
 * This could be Bypassed with **TRACE** **HTTP** requests as the response from the server (if this HTTP method is available) will reflect the cookies sent. This technique is called **Cross-Site Tracking**.
-  * This technique is avoided by **modern browsers by not permitting sending a TRACE** request from JS. However, some bypassed to this have been found in specific software like sending `\r\nTRACE` instead of `TRACE` to IE6.0 SP2.
+  * This technique is avoided by **modern browsers by not permitting sending a TRACE** request from JS. However, some bypasses to this have been found in specific software like sending `\r\nTRACE` instead of `TRACE` to IE6.0 SP2.
 * Another way is the exploitation of zero/day vulnerabilities of the browsers.
 * It's possible to **overwrite HttpOnly cookies** by performing a Cookie Jar overflow attack: