Not all of us
We all dodged a bullet
471–480 of 498 posts
Re: We all dodged a bullet
#472Earlier quoted context omitted.
Corollary: dont click on any emails links. (Most use some dumb domain name that could be phishing)
There are many sites, which provide ONLY links, eg. with token in URL. What with those?
This is the problem. Those need to be very carefully clicked.
The whole web is a darn mess! I have no ideas for solutions.
Re: We all dodged a bullet
#473Earlier quoted context omitted.
the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no…
> the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's. > but, ok, you click the link, you get a new tab, and you're asked to fill…
huh?
the from: address in every email is an arbitrary and unverified text string that the sender provides, anyone can send an email to anyone else and specify a from: president@whitehouse.gov and that's how it will show up to the recipient
what do you mean by the URL scheme? a URL scheme is the http or https part of it? and for sure the host part of the URL was not the same as the real npm's host part of their URL?
i'm not sure what this comment is trying to accomplish, it parses as FUD
Re: We all dodged a bullet
#474Earlier quoted context omitted.
Totally agreed, and I'm surprised this idea hasn't become more mainstream yet. If a package wants to access the filesystem, shell, OS API's, sockets, etc., those should be permissions you have to explicitly grant in your code.
This exact idea has already been mainstream. Both Java and .NET used to have mechanisms like that, e.g.: https://en.wikipedia.org/wiki/Code_Access_Security
"it exists as a niche feature that few use and fewer understand" isn't exactly "mainstream" IMO (it's significantly less common from what I've seen than manual classloader shenanigans, for example). But yes, it's nice that it exists, and I wish it were used more - it'd catch low-effort stuff like this one was.
Re: We all dodged a bullet
#475Earlier quoted context omitted.
most teams I've been around have zero or one person who handles that (because they're passionate) (this is usually me) - tbh I think that's probably the majority case. exceptions totally exist, I've seen them too. I just don't think they're enough to move the median away from "total chaotic garbage" regardless of the system
This is why I secretly hate the term software engineer. "Software tinker" would be more appropriate.
ha, I like that one - it evokes the right mental image.
Re: We all dodged a bullet
#476Earlier quoted context omitted.
> the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's. > but, ok, you click the link, you get a new tab, and you're asked to fill…
huh? the from: address in every email is an arbitrary and unverified text string that the sender provides, anyone can send an email to anyone else and specify a from: president@whitehouse.gov and that's how it will show up to the recipient what do you mean by the URL scheme? a URL scheme is the http or https part of it? and for sure the host part of the URL was not the same as the real npm's host part of their URL? i…
> the from: address in every email is an arbitrary and unverified text string that the sender provides
DKIM et al came back clean.
As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1.
Re: We all dodged a bullet
#477Earlier quoted context omitted.
That's what the Australian Tax Office does. Just a plaintext message that's effectively "you've got a new message. Go to the website to read it."
All my medical places I use do that, with the note that you can also use their app. Good system.
Personally, I'd rather they put the HIPAA message content straight into the email, and let Gmail sort out the priority. About 90% "you have received a message" notifications are not actionable: "you made an appointment" or "take this survey nobody cares about."
Re: We all dodged a bullet
#478Earlier quoted context omitted.
This exact idea has already been mainstream. Both Java and .NET used to have mechanisms like that, e.g.: https://en.wikipedia.org/wiki/Code_Access_Security
"it exists as a niche feature that few use and fewer understand" isn't exactly "mainstream" IMO (it's significantly less common from what I've seen than manual classloader shenanigans, for example). But yes, it's nice that it exists, and I wish it were used more - it'd catch low-effort stuff like this one was.
No, C# had it: past tense. CAS was neutered in .NET Framework 4.0 then removed in dotnet core.
Re: We all dodged a bullet
#479Always use password manager to automatically fill in your credentials. If password manager doesn't find your credentials, check the domain. On top of that, you can always go directly to the website, to make any needed changes there, without following the link.
> Always use password manager to automatically fill in your credentials Absolutely not. https://www.malwarebytes.com/blog/news/2025/08/clickjack-att... https://thehackernews.com/2025/08/dom-based-extension-clickj... https://www.intercede.com/the-dangers-of-password-autofill-a...
What's more likely, the real npm site has a subdomain with XSS (IIRC the issue you linked) or you are manually filling your password into a phishing site?
There's strong evidence that the latter is a more common concern.
Re: We all dodged a bullet
#480Earlier quoted context omitted.
> Always use password manager to automatically fill in your credentials Absolutely not. https://www.malwarebytes.com/blog/news/2025/08/clickjack-att... https://thehackernews.com/2025/08/dom-based-extension-clickj... https://www.intercede.com/the-dangers-of-password-autofill-a...
What's more likely, the real npm site has a subdomain with XSS (IIRC the issue you linked) or you are manually filling your password into a phishing site? There's strong evidence that the latter is a more common concern.
What I'm saying is that autofill is a current method of credential extraction that should be avoided.
You don't have to believe me, read the links.