Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I recorded user behaviour on my competitor’s websites

dejanseo.com.au

Post reply on HN
Print view View original

321–329 of 329 posts

Re: How I recorded user behaviour on my competitor’s websites

#321

Post by dvfjsdhgfv »

tralarpa wrote: post #153
dvfjsdhgfv wrote: post #143

Earlier quoted context omitted.

I'd argue the most interesting and important research is done in this way. It's not that these security experts "don't care", it's just the very nature of certain problems that you need to test them against real users (as opposed to, say, testing an exploit against a system). Consider, for example, honeypot research the very nature of such scenarios is that you can't even hint that users are tracked, let alone asking…

The legal aspects of honeypots were discussed a lot when they became popular. Just two examples: https://www.symantec.com/connect/articles/honeypots-are-they... https://www.researchgate.net/profile/William_Yurcik/publicat... And they are still discussed, for example in the light of the new EU laws: https://jis-eurasipjournals.springeropen.com/articles/10.118...

And they show quite well you can't have the cake and eat it. For example, Spitzner suggests displaying a banner... With all due respect, it's ridiculous. The whole point of this game is to make the attacker believe they're attacking the real system, not to make sure they "waive their privacy rights." I don't think anyone serious about really analyzing the behavior of attackers would ever care about these things. What is more dangerous is if a honeypot is used to attack another resource and you're sued by the owner, for example. It's really hard to avoid breaking a couple of eggs, no matter how you try.

Re: How I recorded user behaviour on my competitor’s websites

#322

Post by C4stor »

bdamm wrote: post #273
C4stor wrote: post #268

Earlier quoted context omitted.

I fail to see how dejanseo put the people at risk. Exposing how a tool is dangerous and poorly conceived isn't the same as conceiving a dangerous tool. In this case, Google put millions of people at risk, and dejanseo actually contributed saving them.

Right; but sometimes someone is the first to have an idea or realize a vulnerability, even if it seems trivial to them. Once it's public, novelty is no longer a factor, and it is a good idea to allow the vendor a chance to remove that vulnerability before the novelty is clearly eliminated. Obscurity does actually matter in the real world, even though it is a useless design principle.

That's right.

But while there are a lot of domain where I don't accept the reasoning "someone else must have thought about this before", finding vulnerabilities is somewhere where I can't help but believe that every publicly disclosed vuln has probably been secretly exploited and sold for years.

(The only data point I have behind that is that there are nations level agencies pretty much dedicated to finding those, and they've gotten really good at this (cf Stuxnet !)).

So, while by conviction only, I highly doubt any independent white/gray hat vuln finder will ever be the first to find it, and I applaud any kind of disclosure.

Re: How I recorded user behaviour on my competitor’s websites

#324

Post by sattoshi »

Just remove the push state history api. Set state is fine.

Push state is totally unnecessary since we already had a technology for this: anchors!

Instead of site.com/my/page, it's site.com/#/my/page.

What is wrong with this? It does literally everything you need and is supported by most routers out of the box!

Re: How I recorded user behaviour on my competitor’s websites

#325

Post by technion »

joshuamorton wrote: post #283
chatmasta wrote: post #209

Somewhat related, Google AMP is also destroying the ability for users to trust URLs. In fact it’s kind of the inverse problem; the URL bar says google.com when the user expects to be on another website. I wouldn’t be surprised if observing the AMP pattern subconsciously made users less suspicious of the trick in OP. It’s also a bit rich to see all the outrage here and deranking by google, since hijacking/proxying to…

As far as I know, site owners essentially have to opt-in to AMP by restricting themselves to a subset of not-exactly-standard web design methods (and may need to explicitly opt-in, I forget). So I don't see a way to call AMP hijacking, since its done with developer permission.

My blog was built when AMP was new and looked cool. It was done with my permission - but the content was not vetted by Google in any way.

People have told me they asked Google to take down my blog, because they thought it was hosted there.

Re: How I recorded user behaviour on my competitor’s websites

#326

Post by SerLava »

geofft wrote: post #218
_gok2 wrote: post #188

Earlier quoted context omitted.

Allowing sites to intercept browser actions that should make a user leave the site, and inject other operations is obviously and plainly a security issue. I reported this to google several years ago, and it was never addressed.

Can't you do the same thing without JavaScript, by having the web page go through a brief redirect so the back button takes you to the redirect? And if so, how do you solve this? Ban server-side redirects? Make the Google SERP iframe all sites it takes you to? I agree this is a problem but I have no idea how to solve it in a way that's not worse.

Maybe if you visit a page for only two tenths of a second, the back button skips it.

It won't fix the whole problem but it's a start.

Re: How I recorded user behaviour on my competitor’s websites

#327

Post by bdamm »

C4stor wrote: post #322
bdamm wrote: post #273

Earlier quoted context omitted.

Right; but sometimes someone is the first to have an idea or realize a vulnerability, even if it seems trivial to them. Once it's public, novelty is no longer a factor, and it is a good idea to allow the vendor a chance to remove that vulnerability before the novelty is clearly eliminated. Obscurity does actually matter in the real world, even though it is a useless design principle.

That's right. But while there are a lot of domain where I don't accept the reasoning "someone else must have thought about this before", finding vulnerabilities is somewhere where I can't help but believe that every publicly disclosed vuln has probably been secretly exploited and sold for years. (The only data point I have behind that is that there are nations level agencies pretty much dedicated to finding those, an…

Yes, the reveal is required. But it doesn’t have to be without the vendor’s knowledge. The rush to get it out without allowing the vendor to respond is unjustified and reckless. The TLAs using the vuln are keeping it a secret, after all, and the script kiddies enjoy public trashing of people which I think is worse than the TLAs careful abuse.

Re: How I recorded user behaviour on my competitor’s websites

#328

Post by tabtab »

jstarfish wrote: post #311
tabtab wrote: post #309

If Chrome outright disables JavaScript's ability to alter the "Back" path, it may brake some (poorly designed) applications. A compromise is to prompt with a warning.

Break them then, with no warning. Letting Javascript trump browser controls (or spam confirmation popups) is a problem that never should have been allowed to live beyond the 90s.

But changing the behavior suddenly can make existing applications outright not function. That results in angry customers. A prompt is a decent compromise. Example prompt: "This website has altered the web address of the Back button. This can be risky. Do you want to use the application's version of the web address, or the original address? [Altered address, Original address, Cancel 'Back', More-info]"

Re: How I recorded user behaviour on my competitor’s websites

#329

Post by Herrera »

shawn wrote: post #149
superasn wrote: post #142

Earlier quoted context omitted.

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…

Howdy, former Matasano pentester here. 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 lesso…

Interesting... I reported a variation of this issue to Google back in 2015 and they said they weren't "concerned about the premise of the attack in the bug description. You can always make the back button go to a page under your control by doing a second navigation, e.g., with pushState".
Post reply on HN