I also saw this as Google feeling threatened by users knowing the url and going directly to websites other than Google. Remove the URL and all browsing is on Google.
It's because they're a web-based, thus fairly open platform. Facebook et al do far more things to keep you in because most use is app-based. Google isn't threatened by users. It's threatened by competitors.
> Cloudflare CAPTCHA – The abuse of Cloudflare’s CAPTCHA service has become a popular anti-analysis tactic. Cloudflare is a legitimate domain security service used to keep websites secure from bots or other automated visitors. This has proven to be a very effective tactic at evading email security because the CAPTCHAs often come prior to any actual-malicious URLs.
Besides the obvious schadenfreude at AMP being abused, this stood out to me. It's just so delicious, malicious actors thwarting automated analysis of their shady links by including CAPTCHAs...
I've been complaining about this for a while. Everything I try to test with urlscan.io (as a safe sandbox to view a phishing site) has for a while just given me a Cloudflare captcha. Everything I submit to certain automated malware services just come back as "not malicious" despite being clearly malicious, I'm guessing because automation doesn't get past the catpcha.
CEO of urlscan.io here: We will be evaluating the use of captcha bypass services soon, we are fully aware of the growing problem of captchas being abused by threat actors to hide their malicious websites from automated analysis tools such as ours.
It's honestly a frustrating problem as we're effectively in an arms race with the likes of Cloudflare, Google et al, and we're in the same boat with less reputable services like scrapers and bots. The recent developments around Web Environment Integrity are concerning to us for the same reasons. Feel free to reach out with any questions or suggestions you might have!
Given the volume of automated link scraping that you do, would it be possible for your company to arrange for a deal with Cloudflare allowing your servers past their Captcha gate, at least around the free-tier Captcha which the scammers most likely use?
If you don't run adblocker pretty much any website is loaded with malware. New York Times was infecting people with Bahama botnet some years ago. What's stopping other (non)shady websites from doing just the same?
I want to browse the net with only bitmaps being sent to me. I do not want to execute your javascript or markup or make requests other than what i have initiated. Please god someone make a docker container i can spin up on a throwaway computer that renders pages and sends bitmaps of the site to my main computer
Edit: even better, every tab is a separate container instance, i close tab, it nukes the container
To render pages on a throwaway computer and send only bitmaps, connect to the throwaway computer via VNC and run an ordinary browser.
As for improving on tab isolation over what existing browser sandboxes already offer, lightweight virtualization a la Firecracker seems like a more useful increment than containerization, and, assuming each tab has a similar VNC-like connection to its browser VM, virtualization would also make the whole "throwaway computer" setup less necessary to provide a meaningful security improvement.
I would say that you don't absolutely need a service like urlscan.io to look at a single suspicious URL, but running a URL through our sandbox will create a point of time snapshot that you can share with others, compare to existing scans and use as evidence for further actions like takedown.
the phishing attempt from the url that looks like it comes from your bank can also have exploits to attack your browser, other than getting you to enter your credit card details.
This is going to get 10x as 'fun' once Web Environment Integrity means that malware developers can demand attestation that you're a real victim and not a URL scanner
That is exactly my worry. It's hard enough as it is with VPN / IP detection, headless detection, Captchas, etc. WEI would probably mean game over for all but a handful of Google-sanctioned bots.
One more step
Please complete the security check to access
Why do I have to complete a CAPTCHA?
Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.
What can I do to prevent this in the future?
If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.
If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.
Yes, great idea. And to be safe you could turn on Enhanced Google Safe Browsing so Google can scan the URLs in real-time to protect you against malicious Google AMP URLs.
Remember: Letting Google* decide what software you can run is for YOUR safety. Report anyone you see running unsafe software. Be safe. Let big Google watch over you.
It has ceased development and Google no longer tries to push it, but unfortunately many large and slow-moving publications already hitched themselves to the wagon.
I was about to point at The Guardian as an example, but it looks like they managed to migrate off. Good riddance.
We <<heart emoji>> working with you and your team at Allianz. How can we help you today?"
I do not work at Allianz, but at another large German company that appears to share a web proxy service with Allianz, who are apparently Cofense customers (or Cofense believes they ought to be).
It's not obsolete at all. It's more relevant than ever, imo. I do all of my browsing through a proxy (so that I can strip DoH requests out of the stream).
You probably don't want to do it my way -- I've cobbled it together and it works, but it's not pretty.
In essence, what I've done is set up my router to intercept all HTTPS traffic and direct it to a proxy program that I wrote myself. All the program does is look for DoH traffic and drop it on the floor, just passing the rest on to its proper destination. This requires installing a custom cert on each browser so the proxy can decrypt the HTTPS stream.
If I were to do this today, I'd look into formal tools to do this, such as mitmproxy or somesuch. That's not a specific recommendation, I've never used it. But there are a number of similar tools available. One of them is likely to be a good solution!
Thats fair, but an enterprise instalation I saw used a transparent proxy and certs on client machines. By transparent proxy I mean a DPI firewall that somehow "hijacked" normal TLS sessions. I don't really know why, a HTTP proxy would be the obvious solution ...
I'm unable to browse that site without turning JavaScript off.
On mobile there's a cookie notification that takes up two thirds of the screen and only has an Accept option (yeahnah from me), and if I scroll down the page ever so slightly I get some kind of subscription advertising pop up.
Why not? It comments on the presentation of the content. Can't we judge here on HN the font, CSS layout, animations, javascript, popups? Can we only rate raw content, text, presented on a page? Where do you draw the line? It it okay by you to comment on images?
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
visiting not well known infosec related sites without JS is good form in general. Especially if they ask to click on something, I recall user interaction is necessary for some exploits to work
It's just a redirect, this isn't an issue. The browser will use the final URL to decide which passwords to look up.
The issue is for clients that don't follow URLs and also manage abuse reputation by domain name. For example, if your webmail client knows that "evilsite.com" is bad because it's frequently reported spam, then you just start using links to "google.com/amp/evilsite.com" and the webmail client's reputation score resets.
Google tried to solve this by having the URL bar show the cryptographic origin of the page being displayed, rather than the URL it was fetched from (the delivery provider).
There was strong pushback here on HN - people cared more about who delivered the page than who wrote it. To me that argument is non-sensical - if you take it to the extreme, the URL bar should always just display 'data from Comcast via 192.168.0.1'
This is a strawman argument. You're misrepresenting the pushback and then argue against that misrepresentation.
A large part of the pushback can be summerized as such: "Google created a technology that is incompatible with the open web. Now they want browsers to change their behavior to solve some of the ways this breaks the web."
Google is the only company that can get away with this, due to their incredible market share in browser, mobile and web. Browser vendors serve as the gatekeepers deciding what the operating space is for web developers. As a result, web developers can't fundamentally change how the web works, for better or for worse. Google can, and did, and is now cleaning up the mess this left behind.
The entire argument comes down to whether you think AMP is a good or a bad thing. Either you believe it's good, and you believe browsers should change to make it work, or you believe it's bad, and it's a problem that google has so much leverage to push this tech onto us.
Signed exchanges don't prove that that is the CURRENT content from the purpoted website while hiding the true (hosting) URL would give that impression.
Within epsilon yes it does because the signer chooses the signature expiration and it's no more than 7 days.
If you don't like this you should also take issue with Cache-Control.
You, the website operator, opt in to signed exchanges and define exactly what resources are valid for how long. If you're okay with the browser caching pages there really should be no reason to be weirded out by any 3rd party caching them too.
How do they protect against websites stealing cookies and executing javascript on google.com origin? This was a stupid idea altogether. They have the googleusercontent.com domain for thus very reason. Why didn't they host amp on per-remote-origin origins?
Another pretty bad aspect of their domain handling (replacing dot with -) is that they can't support really long domains that exceed the length of a label. Secondly, this breaks punycode parsers and instead of "šijanec" as a label you get some garbled unreadable punycode.
EDIT: they seem to add a get parameter _x_tr_hp=s, so this is probably how they work around the limitation. Nice!
They could've done www.website.example.translate.goog, but that would add issues with TLS, since a wildcard subject alternative name only matches one label. But by getting a CA signed cert, limited to translate.goog (which is possible), they could just issue certs on the fly.
Stop playing cat vs mouse and start using a physical hardware token as a 2fa. This makes it impossible to phish people because anything but the right domain gets a wrong key.
I know that it's kind of OT, but why does this website force the user to accept third-party cookies? There's only the "Accept" button with no possibility to reject anything. Is this even legal?
Serving a Scam URL with a giant amount of text after the # sign is genius. You can have something that looks completely clean for anyone else, then the actual payload if they provided the # data, or even the payload encoded as the # data.
89 comments
[ 3.8 ms ] story [ 147 ms ] threadFiddling up with the server addresses in an unintended way opens-up new doors for scams.
Besides the obvious schadenfreude at AMP being abused, this stood out to me. It's just so delicious, malicious actors thwarting automated analysis of their shady links by including CAPTCHAs...
Many scraping products and the internal scraping systems of companies (especially retailers) implement such mechanisms.
It's honestly a frustrating problem as we're effectively in an arms race with the likes of Cloudflare, Google et al, and we're in the same boat with less reputable services like scrapers and bots. The recent developments around Web Environment Integrity are concerning to us for the same reasons. Feel free to reach out with any questions or suggestions you might have!
A captcha might serve as a strong negative signal.
Disclaimer: I work at CF
https://nvd.nist.gov/vuln/detail/CVE-2023-3079
https://nvd.nist.gov/vuln/detail/CVE-2023-37450
https://nvd.nist.gov/vuln/detail/CVE-2023-32439
Edit: even better, every tab is a separate container instance, i close tab, it nukes the container
As for improving on tab isolation over what existing browser sandboxes already offer, lightweight virtualization a la Firecracker seems like a more useful increment than containerization, and, assuming each tab has a similar VNC-like connection to its browser VM, virtualization would also make the whole "throwaway computer" setup less necessary to provide a meaningful security improvement.
1. To bypass your corporate proxy (ok, not the best reason);
2. urlscan also allows you to pivot easily and find the same phishing kit as they have a nice database of scans;
3. urlscan also allows you to see the website from different proxies, which can be useful if there is geofencing.
It isn't that simple and threat actors are far from being dumb :)
Disclaimer: I'm the CEO of urlscan.io
[0] https://blog.cloudflare.com/eliminating-captchas-on-iphones-...
* Applies to any other walled garden megacorp.
https://support.brave.com/hc/en-us/articles/8611298579981
Google is probably the prime example of this...
I was about to point at The Guardian as an example, but it looks like they managed to migrate off. Good riddance.
Thank you for being a Cofense customer.
We <<heart emoji>> working with you and your team at Allianz. How can we help you today?"
I do not work at Allianz, but at another large German company that appears to share a web proxy service with Allianz, who are apparently Cofense customers (or Cofense believes they ought to be).
In essence, what I've done is set up my router to intercept all HTTPS traffic and direct it to a proxy program that I wrote myself. All the program does is look for DoH traffic and drop it on the floor, just passing the rest on to its proper destination. This requires installing a custom cert on each browser so the proxy can decrypt the HTTPS stream.
If I were to do this today, I'd look into formal tools to do this, such as mitmproxy or somesuch. That's not a specific recommendation, I've never used it. But there are a number of similar tools available. One of them is likely to be a good solution!
I'm unable to browse that site without turning JavaScript off.
On mobile there's a cookie notification that takes up two thirds of the screen and only has an Accept option (yeahnah from me), and if I scroll down the page ever so slightly I get some kind of subscription advertising pop up.
This link is more spam and ad than content.
Lord knows how it got to the top of HN today.
(Hint: clearly pros at scams and phishing)
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
[1] https://news.ycombinator.com/newsguidelines.html
The issue is for clients that don't follow URLs and also manage abuse reputation by domain name. For example, if your webmail client knows that "evilsite.com" is bad because it's frequently reported spam, then you just start using links to "google.com/amp/evilsite.com" and the webmail client's reputation score resets.
There was strong pushback here on HN - people cared more about who delivered the page than who wrote it. To me that argument is non-sensical - if you take it to the extreme, the URL bar should always just display 'data from Comcast via 192.168.0.1'
A large part of the pushback can be summerized as such: "Google created a technology that is incompatible with the open web. Now they want browsers to change their behavior to solve some of the ways this breaks the web."
Google is the only company that can get away with this, due to their incredible market share in browser, mobile and web. Browser vendors serve as the gatekeepers deciding what the operating space is for web developers. As a result, web developers can't fundamentally change how the web works, for better or for worse. Google can, and did, and is now cleaning up the mess this left behind.
The entire argument comes down to whether you think AMP is a good or a bad thing. Either you believe it's good, and you believe browsers should change to make it work, or you believe it's bad, and it's a problem that google has so much leverage to push this tech onto us.
If you don't like this you should also take issue with Cache-Control.
You, the website operator, opt in to signed exchanges and define exactly what resources are valid for how long. If you're okay with the browser caching pages there really should be no reason to be weirded out by any 3rd party caching them too.
Chrome’s URL bar? When was this?
https://_https.www.remote-website.com.amp.googleusercontent....
For example, my website translated with their service:
https://splet-4a-si.translate.goog/?_x_tr_sch=http&_x_tr_sl=...
Clicking on the link "version control" leads to the page
https://ni-xn----ijanec--9jb-eu-.translate.goog/?_x_tr_sch=h...
(note the second label ending with -) and this page can't be reached according to google, but on the real site (http://splet.4a.si), the link is valid: https://ni.xn--ijanec-9jb.eu/
Another pretty bad aspect of their domain handling (replacing dot with -) is that they can't support really long domains that exceed the length of a label. Secondly, this breaks punycode parsers and instead of "šijanec" as a label you get some garbled unreadable punycode.
Label length problem:
Website http://splet.sijanec.sijanec.sijanec.sijanec.sijanec.sijanec... cannot be unambiguously page-translated with their service. -- they remove the first s in the hostname, yielding:
https://plet-sijanec-sijanec-sijanec-sijanec-sijanec-sijanec...
EDIT: they seem to add a get parameter _x_tr_hp=s, so this is probably how they work around the limitation. Nice!
They could've done www.website.example.translate.goog, but that would add issues with TLS, since a wildcard subject alternative name only matches one label. But by getting a CA signed cert, limited to translate.goog (which is possible), they could just issue certs on the fly.
https://amp.dev/documentation/guides-and-tutorials/learn/amp...
Not in the EU it's not.
EU regulators are a joke.
[0] https://news.ycombinator.com/item?id=23324576