Malicious NPM packages are part of a malware "barrage" hitting repositories:
Researchers have found another 17 malicious packages in an open source repository, as the use of such repositories to spread malware continues to flourish.
This time, the malicious code was found in NPM, where 11 million developers trade more than 1 million packages among each other. Many of the 17 malicious packages appear to have been spread by different threat actors who used varying techniques and amounts of effort to trick developers into downloading malicious wares instead of the benign ones intended.
This latest discovery continues a trend first spotted a few years ago, in which miscreants sneak information stealers, keyloggers, or other types of malware into packages available in NPM, RubyGems, PyPi, or another repository. In many cases, the malicious package has a name that's a single letter different than a legitimate package. Often, the malicious package includes the same code and functionality as the package being impersonated and adds concealed code that carries out additional nefarious actions.
"We are witnessing a recent barrage of malicious software hosted and delivered through open-source software repositories," JFrog researchers Andrey Polkovnychenko and Shachar Menashe wrote on Wednesday. "Public repositories have become a handy instrument for malware distribution: the repository's server is a trusted resource, and communication with it does not raise the suspicion of any antivirus or firewall. In addition, the ease of installation via automation tools such as the npm client, provides a ripe attack vector."
Recently: Malware Downloaded from PyPI 41,000 Times Was Surprisingly Stealthy
(Score: 2) by bradley13 on Monday December 13 2021, @10:03PM (8 children)
Include random libraries, rather than writing your own code. If course, those libraries load other libraries, which in turn load more libraries. So your little web page winds up downloading 5MB of crap, in order to parse an email address...
Everyone is somebody else's weirdo.
(Score: 2) by vux984 on Monday December 13 2021, @11:15PM (2 children)
On the other hand a popular library probably does it right. I've been on WAY too many websites that rejected a perfectly valid email address because it was written by someone who thought they were smart enough but wasn't.
And I'm not even talking about those fun obscure cases. I'm talking pretty basic stuff like rejecting an underscore or hyphen in the name, or rejecting valid TLDs like .edu, or even rejecting addresses with more than 2 subdomains (e.g. rejecting example@sub.domain.co.uk), or rejecting a domain name that is numerical, like someone@777.com
(Score: 2) by Reziac on Tuesday December 14 2021, @02:34AM
I have an earthlink.net addy I've had since forever. It STILL gets rejected by the odd stupid form, even tho at one time it was the second most common email domain and you'd think after 27 years they'd have figured it out, but apparently not.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 0) by Anonymous Coward on Tuesday December 14 2021, @01:49PM
The hard task is finding third party libraries with stable APIs and zero transitive dependencies. Those are about as common as unicorns.
(Score: 1, Informative) by Anonymous Coward on Tuesday December 14 2021, @04:55AM (4 children)
Fools. Everybody knows that a regex is the best way to parse email addresses.
(Score: 0) by Anonymous Coward on Tuesday December 14 2021, @08:26AM (1 child)
(Score: 1, Touché) by Anonymous Coward on Tuesday December 14 2021, @09:48AM
If you are going to steal a regex from stack overflow, you might as well copy one that actually follows the specification.
(Score: 0) by Anonymous Coward on Tuesday December 14 2021, @01:51PM (1 child)
You can write sane complex regexes if you use named capture groups. Damian Conway has some videos on it.
(Score: 1, Interesting) by Anonymous Coward on Tuesday December 14 2021, @11:20PM
In addition to named groups, I like to build complex regular expressions explicitly from simpler ones using string formatting out of its component parts. To use an example leaving out the named groups, start with
Now you see that requires a local-part and a domain. So you add those
And you keep going until you build your regular expression. The nice thing about it is that it can make it much easier to go back and see what is going on. Another benefit is that modern "regex" engines support context-sensitive grammars which can be harder to reason about with named groups alone. Finally, you can use language features that can be clearer with long lists of disjuncts, highly-nested definitions, or more performant by building prefix trees and other harder to grasp structures as you go.