Update cookie-tossing.md

pentesting-web/hacking-with-cookies/cookie-tossing.md

@@ -19,17 +19,17 @@
 
 ## Description
 
-If an attacker is able to **control a subdomain of the domain of a company or finds a XSS in a subdomain** he will be able to perform this attack.
+If an attacker can **control a subdomain of the domain of a company or finds an XSS in a subdomain** he will be able to perform this attack.
 
-As it was indicated in the Cookies Hacking section, when a **cookie is set to a domain (specifying it) it will be used in the domain and in subdomains.**
+As it was indicated in the Cookies Hacking section, when a **cookie is set to a domain (specifying it) it will be used in the domain and subdomains.**
 
 {% hint style="danger" %}
-Therefore, **an attacker is going to be able to set to the domain and subdomains an specific cookie doing something like** `document.cookie="session=1234; Path=/app/login; domain=.example.com"`
+Therefore, **an attacker is going to be able to set to the domain and subdomains a specific cookie doing something like** `document.cookie="session=1234; Path=/app/login; domain=.example.com"`
 {% endhint %}
 
-This can be really dangerous as the attacker may be able to:
+This can be dangerous as the attacker may be able to:
 
-* **Fixate the cookie of the victim to the attackers account** so if the user doesn't notice, **he will perform the actions in the attackers account** and the attacker may obtain some interesting information (check the history of the searches of the user in the platform, the victim may set his credit card in the account...)
+* **Fixate the cookie of the victim to the attacker's account** so if the user doesn't notice, **he will perform the actions in the attacker's account** and the attacker may obtain some interesting information (check the history of the searches of the user in the platform, the victim may set his credit card in the account...)
 * If the **cookie doesn't change after login**, the attacker may just **fixate a cookie**, wait until the victim logs in and then **use that cookie to log in as the victim**.
 * If the **cookie is setting some initial value** (like in flask where the **cookie** may **set** the **CSRF token** of the session and this value will be maintained after the victim logs in), the **attacker may set this known value and then abuse it** (in that scenario, the attacker may then make the user perform a CSRF request as he knows the CSRF token).
 
@@ -39,7 +39,7 @@ When a browser receives two cookies with the same name **partially affecting the
 
 Depending on who has **the most specific path** or which one is the **oldest one**, the browser will **set the value of the cookie first** and then the value of the other one like in: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
 
-Most **web sites will only use the first value**. Then, if an attacker wants to set a cookie it's better to set it before another one if set or set it with a more specific path.
+Most **websites will only use the first value**. Then, if an attacker wants to set a cookie it's better to set it before another one if set or set it with a more specific path.
 
 {% hint style="warning" %}
 Moreover, the capability to **set a cookie in a more specific path** is very interesting as you will be able to make the **victim work with his cookie except in the specific path where the malicious cookie set will be sent before**.
@@ -47,7 +47,7 @@ Moreover, the capability to **set a cookie in a more specific path** is very int
 
 ## Protection Bypass
 
-A possible protection against this attack would be that the **web server won't accept requests with two cookies with the same name but two different values**.
+Possible protection against this attack would be that the **web server won't accept requests with two cookies with the same name but two different values**.
 
 To bypass the scenario where the attacker is setting a cookie after the victim was already given the cookie, the attacker could cause a **cookie overflow** and then, once the **legit cookie is deleted, set the malicious one**.
 
@@ -59,7 +59,7 @@ Another useful **bypass** could be to **URL encode the name of the cookie** as s
 
 ## Cookie Bomb
 
-A Cookie Tossin attack may be used also to perform **Cookie Bomb** attack:
+A Cookie Tossin attack may be used also to perform a **Cookie Bomb** attack:
 
 {% content-ref url="cookie-bomb.md" %}
 [cookie-bomb.md](cookie-bomb.md)