Cross-Site Request Forgery Attack A browser sends out cookies as a response to a request, irrespective of where it came from. This is where the issue arises. When the site gets a request, it's unable to distinguish if it's an action prompted by the user. The site looks for the cookie. In case it's available, it purposely acts, no matter the user-initiated it or not.
Cross-Site Scripting To perform a cross-site scripting exploit, a hacker needs to place the exploit in the cookie. After that, the exploit vector is going to fetch the payload from the cookie. That's how they exploit the users. If the cookie is set already, it can be difficult to attack. Also, the attacker needs to control the first cookie in the cookie string. Only then can they carry out the attack.
Session Fixation These attacks depend on the application level. In this, the attacker induces the user to use another person's or the attacker's session ID. It uses the cookie's directive path to do this. So, the user pretends to be someone else. Using the method, the attackers can request the user to log in as the attacker on different application levels.
Cookie Overflow Attack In this kind of attack, the parent domain's cookie is substituted by the sub-domain cookie using JavaScript in the subdomain. Web browsers have a limitation on the total cookies to set. Browsers such as Chrome do not verify if the cookies that it is storing are from the sub-domain or domain. It just holds the website cookies that it gets. The substituted sub-domain cookies are not secure, or HTTP only type. After storing this cookie, the attacker can change its expiry date, and it will become useless. Attackers will now have the option to create new malicious cookies and then forward them to the web browser. A web browser cannot detect if it belongs to the HTTP Only or secure category. So, the attackers use fabricated cookies to carry out the attack.