141–150 of 329 posts
Earlier quoted context omitted.
It doesn’t seem like there is a fix, short of removing the history API.
Maybe restrict the history API to the same-origin-policy? Javascript could/should be allowed to manipulate browser-history only for the same domain. Just an idea.
And it would be very limited if JS can't change `window.location` to outside its current domain.
Hi everyone! I did this. It was just a random cool idea I wanted to try. It worked a little too well and I quickly moved it to a disposable site to test if the page will get penalised by Google. I got busy with other things and forgot about it. When I bumped into it again I decided to write about it, for two reasons: 1) To me it's hard to believe that Chrome would allow for this to happen in the first place and 2) th…
Yes you could have handled it more appropriately and you probably will in the future too. I just don't understand the harsh attitude and all this legal nonsense and insults being hurled at you for no big reason.
Earlier quoted context omitted.
When you do security work, that's an important part of your job. Sure, in many scenarios like traditional pentesting you can probably do fine within the legal boundaries in most jurisdictions, but as soon as you do serious security research when you actually test your ideas in practice, you're likely to cross the line sooner or later. It's a difference between "it should probably work" and "yes, it worked, I tried it…
> you're likely to cross the line sooner or later. That's basically the opposite of what security researchers working for companies and research institutes are doing. Document everything, get written consent of involved parties and sometimes even inform the police about a planned action. Make sure that you (a) don't cross the line or (b) move the line legally further away. Of course, there are security experts who do…
How does a person get so much flak for hacking - on Hacker News?
People linking to fake sites as a dark pattern is nothing novel, you just did so too capture analytics instead of, say, installing a virus or taking someone's credentials. That said, you certainly could have done the latter and gotten views into your competitors' user portals. In my head that's not fundamentally different or more unethical from what you ended up doing.
I don't necessarily begrudge you for trying it, but I don't think it's for a noble reason nor do I think it was particularly innovative and the end result is Google doing something unsurprising.
Earlier quoted context omitted.
Copying someone elses site and tricking their users to use your copy is a copyright violation and fraud. Nothing cool about it.
It's a POC with no intention other than seeing if it would be possible, isn't it?
Hi everyone! I did this. It was just a random cool idea I wanted to try. It worked a little too well and I quickly moved it to a disposable site to test if the page will get penalised by Google. I got busy with other things and forgot about it. When I bumped into it again I decided to write about it, for two reasons: 1) To me it's hard to believe that Chrome would allow for this to happen in the first place and 2) th…
Copying someone elses site and tricking their users to use your copy is a copyright violation and fraud. Nothing cool about it.
Hi everyone! I did this. It was just a random cool idea I wanted to try. It worked a little too well and I quickly moved it to a disposable site to test if the page will get penalised by Google. I got busy with other things and forgot about it. When I bumped into it again I decided to write about it, for two reasons: 1) To me it's hard to believe that Chrome would allow for this to happen in the first place and 2) th…
It's sad that everyone is being so harsh to you just because you decided to post about a vulnerability that who knows thousands of other people are quietly exploiting for their own benefit. If anything I am happy that instead of trying to misuse it or keeping it a secret you made it public knowledge so that there can be something done about it. Yes you could have handled it more appropriately and you probably will in…
FWIW, I would probably have done something similar to them before I'd worked in the security industry. It's an easy mistake to make, because it's one you make by default: intellectual curiosity doesn't absolve you from legal judgement, and people on the internet tend to flip out if you do something illegal and say anything but "You're right, I was mistaken. I've learned my lesson."
To the author: The reason you pattern-matched into the blackhat category instead of whitehat/grayhat (grayhat?) category is that in the security industry, whenever we discover a vuln, we PoC it and then write it up in the report and tell them immediately. The report typically includes background info, reproduction steps, and recommended actions. The whole thing is typically clinical and detached.
Most notably, the PoC is usually as simple as possible. alert(1) suffices to demonstrate XSS, for example, rather than implementing a fully-working cookie swipe. The latter is more fun, but the former is more impactful.
One interesting idea would've been to create a fake competitor -- e.g. "VirtualBagel: Just download your bagels and enjoy." Once it's ranking on Google, run this same experiment and see if you could rank higher.
That experiment would demonstrate two things: (1) the history vulnerability exists, and (2) it's possible for someone to clone a competitor and outrank them with this vulnerability, thereby raising it from sev:low to sev:hi.
So to be clear, the crux of the issue was running the exploit on a live site without their blessing.
But again, don't worry too much. I would have made similar errors without formal training. It's easy for everyone to say "Oh well it's obvious," but when you feel like you have good intent, it's not obvious at all.
I remind everyone that RTM once ran afoul of the law due to similar intellectual curiosity. (In fairness, his experiment exploded half the internet, but still.)
Earlier quoted context omitted.
It doesn’t seem like there is a fix, short of removing the history API.
Maybe restrict the history API to the same-origin-policy? Javascript could/should be allowed to manipulate browser-history only for the same domain. Just an idea.
> The new URL does not need to be absolute; if it's relative, it's resolved relative to the current URL. The new URL must be of the same origin as the current URL; otherwise, pushState() will throw an exception. This parameter is optional; if it isn't specified, it's set to the document's current URL.
https://developer.mozilla.org/en-US/docs/Web/API/History_API...
The exploit in this article clones the appearance of Google results and competitor websites but leaves the user on the exploiter’s domain, so users who are savvy enough to notice the URL wouldn’t be fooled.