Imagine I'm telling you how awesome it was to be tweeted about by a page on twitter, and I show you this image:
That seems innocent enough. You ...
For further actions, you may consider blocking this person and/or reporting abuse
there are informations to add :
All true! Here is how people can make the URL have a fake file extension. I'd also add to the "more about this" list that people like to use this technique to track whether you've opened their emails or not.
I think a normal pixel tracker (like Facebook's) doesn't do this. It only sends it's own (Facebook's) cookies together with the request, so it doesn't need to "steal" any cookies since this is normal browser behavior (not anymore on Safari)
Now what worries me is that a lot of sites probably still use things that can be exploited and so could I be as a customer. It's worrying to know that you protect your software as much as possible but if you have integrations to external systems your users might get hacked through external parties. I don't know any other professions worrying so much about security while not being security branches.
Does a car mechanic care that you might leave your keys exposed to get copied? No they tell you to take care of it.
All true, but remember that the frameworks protects you when you use the proper built-in methods for it and not "as is" most of time. By the way each week vulnerabilities on frameworks are published and they can catch you by surprise.
Also a framework or language upgrade is not a minor patch sometimes, it can break up your APP so you'll need to stay tunned to your framework/s updates and vulnerabilities and patch your app the best way possible.
Let's say you have a very big python 2.x app and it becomes unsupported and the next python 3.x version is not retro-compatible so you cannot upgrade from one to another as it will cost too much time, resources and money. You'll need to manually patch every single security hole that is found on next versions by your own and it's not an easy process, that's why most companies performs passive upgrades (if a hack happens, we'll patch it). Sad but true
As far as I know these kind of things are popular or widely known by developers from the begging of 2000s and there's nothing surprising about it. No upgrade or anything regards to these kinds of attack is necessary at least not on JVM platform or any other that has well established community, maintainers, and practices. Now I know people tend to npm install everything but I don't consider them in these statements as most of those project fail or are not so big anyways.
The thing I'm discussing here is basically attack as described in the post and basically any XSS, SQL injection, CSRF, and similar. Most of the stories that I've heard is "Who would ever try it on this site" + "we don't have time for that but as soon as we finish other stuff" and then hell breaks loose.
Here's an example: "Never use local storage for JWT" and then you ask them to "hack" your web app as they're 100% it will hacked. Now they usually can't as you don't rely on all npm packages that exist nor do you keep any info in there that might be sensitive if leaked. Also you store your own stuff and don't have any img's and stuff like author said. Why? Well at least from what I've seen most of us don't create social platforms with comment features but rather closed community tools which you can't even access in some cases without VPN. I get that sometimes you need to use images from external sources but would you allow adding unverified ones that easily? Most times not.
I just wonder is it only me or is it actually like this, most people that work don't blog nor care about some stuff as they never have to deal with them like I described?
Yes totally agree, I just wanted to point out that the comfortability of frameworks are not a place to rely without doing anything extra to secure your projects and that even having some methods that we use like a ritual (real_escape_string on mysqli query params that comes from user interaction for example) it could be that day that someone forget it and it keeps on the project for months if nobody takes care of that. In fact I've been thinking for years that security methods must apply by default and if you don't want them on a given situation you must be able to avoid them specifically. This will make our life easier and avoid human errors (of course you can write tests and so but...)
I agree with that, and what you described is how most frameworks I used work. We'll at least in such popular security issues. Like take a look at Spring Data and how to query stuff. You can pass in string directly from the GET query to repository and it will apply all well known security filters. Or Micronaut or Quarkus. BTW I read recently that it's about ~80% hacks that come from indirect dependencies and I can only assume npm in that case with example of 'event-stream' incident. Those things is impossible to fix since you always rely on something and that something could go wrong just like this.
Yup, I'm on front end and we use to use custom security methods for the entry points on it, then the server takes care about the rest
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.
Nice article.
There was also something similar when using SVGs.
owasp.org/www-pdf-archive/Mario_He...
Interesting, is the result supposed to display on google maps? I'm in China behind the great firewall so if it's google then I need my vpn to see the map but then you can't grab my data. Is that near the mark or am I way off? Either way I'm seeing a blank window.
Yep, just a google map of wherever your IP traces to :)
This is really interesting!
a bit ot maybe but what is the
if(i++)doing?does this only work on images or can it work on other requests too?
It'll work on other requests too.
Thanks for highlighting this.
I read all of this and anticipated the part where you tell me how to avoid it and instead only got "go investigate htmlentities" :/
Thanks for checking the article out! I've updated the article to be more detailed in this area, but I'll include that in this reply as well. When you allow a user to post text to your site, you take the text they posted on the backend and escape it with the htmlentities function if you're using PHP.
It's just that simple. This will get rid of any img tags that users try to inject.
thank you
Super interesting. Thanks !
Unclean input unclean!! ๐ฅ
Interesting.
Nice article! Sometimes I feel like the web is just too powerful for its own good...
Pretty Interesting!!
Good info to be aware of! Always good to know where to better check for vulnerabilities in my code
Forgetting escaping and the other security measures is not tolerate for BIG guys. ๐