I'm worried that there is some misinformation here.
Browsers won't send cookies to just any random host. The only cookies you can get are the ones you set from your host (you can't "hack things" to get google.com cookies sent to example.com). Same for localStorage. Of course there could be a browser vulnerability, but, by convention this is not something to worry about.
HTML, JS and SQL injection are all real and must be coded around. It again, this is very different than worrying about getting your cookies stolen.
Your example of the image that grabs your IP is 100% legit, and you correctly noted that this is how email trackers work. But, they aren't stealing cookies and getting access to credentials from other hosts. Conflating the two makes it sound like they are both exposing user information more egregiously than they are.
The reason the cookie stealing example works is that it loads document.cookie on the frontend of the website you inject the HTML into. document.cookie would be called from the website you'd attack, so there would be no cross-origin conflict. It would be as if the devs themselves had coded in a way to send you their users' cookies. If Google forgot to escape HTML entities anywhere they allowed you to post text to other users, you absolutely could steal everyone's Google cookies when they viewed the image you posted. document.cookie is just a string, and when it's loaded by the same domain, you can then send it to any website you want- just like you could with any other string.
Perhaps you didn't see the "onload" of the cookie-stealing image example?
You are right I didn't see the onload part because I'm on my phone haha.
So, how do you get that code in there? Allowing a user to put in a url to an image is VERY different than allowing them to add an HTML element (that has an onload). I conceded that sanitizing HTML, JS and SQL is still a very necessary practice. As others have pointed out the security provided by http-only cookies is also a must have on everyone web developer's checklist.
I'm sorry for sounding negative.... I just feel your post is making things sound scary unnecessarily. I do appreciate your work to expose how things work under the covers in an easily consumable way.
It's not scary if you know how to stop it from happening! It's important to note that this style of attack (cross-site scripting) is consistently rated the most commonly executed attack method. While it's easy to guard against (as noted at the end of this article), developers that aren't aware of it will almost certainly leave it unguarded. In an unguarded situation, all you'd have to do is paste that cookie-stealing image tag into the comment section, your username field, or wherever else you're meant to be adding text to the website. That's why it's so important to talk about it and not just assume all developers know about it already. It does pose a very real threat if not defended against correctly.
Thanks! I'm glad you're enjoying my content, especially enough to interact with it in the comment sections.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm worried that there is some misinformation here.
Browsers won't send cookies to just any random host. The only cookies you can get are the ones you set from your host (you can't "hack things" to get google.com cookies sent to example.com). Same for localStorage. Of course there could be a browser vulnerability, but, by convention this is not something to worry about.
HTML, JS and SQL injection are all real and must be coded around. It again, this is very different than worrying about getting your cookies stolen.
Your example of the image that grabs your IP is 100% legit, and you correctly noted that this is how email trackers work. But, they aren't stealing cookies and getting access to credentials from other hosts. Conflating the two makes it sound like they are both exposing user information more egregiously than they are.
The reason the cookie stealing example works is that it loads
document.cookieon the frontend of the website you inject the HTML into.document.cookiewould be called from the website you'd attack, so there would be no cross-origin conflict. It would be as if the devs themselves had coded in a way to send you their users' cookies. If Google forgot to escape HTML entities anywhere they allowed you to post text to other users, you absolutely could steal everyone's Google cookies when they viewed the image you posted.document.cookieis just a string, and when it's loaded by the same domain, you can then send it to any website you want- just like you could with any other string.Perhaps you didn't see the "onload" of the cookie-stealing image example?
You are right I didn't see the onload part because I'm on my phone haha.
So, how do you get that code in there? Allowing a user to put in a url to an image is VERY different than allowing them to add an HTML element (that has an onload). I conceded that sanitizing HTML, JS and SQL is still a very necessary practice. As others have pointed out the security provided by http-only cookies is also a must have on everyone web developer's checklist.
I'm sorry for sounding negative.... I just feel your post is making things sound scary unnecessarily. I do appreciate your work to expose how things work under the covers in an easily consumable way.
It's not scary if you know how to stop it from happening! It's important to note that this style of attack (cross-site scripting) is consistently rated the most commonly executed attack method. While it's easy to guard against (as noted at the end of this article), developers that aren't aware of it will almost certainly leave it unguarded. In an unguarded situation, all you'd have to do is paste that cookie-stealing image tag into the comment section, your username field, or wherever else you're meant to be adding text to the website. That's why it's so important to talk about it and not just assume all developers know about it already. It does pose a very real threat if not defended against correctly.
Thanks! I'm glad you're enjoying my content, especially enough to interact with it in the comment sections.