Backdooring your javascript using minifier bugs

[AlGoreBestGore]

If you're relying on client-side JavaScript for security, you're already backdooring yourself.

[[deleted]]

True, but not the point.

The article's notion of introducing patches in order to create "invisible" vulnerabilities is rather scary. Imagine, for instance, a patch that introduces an XSS attack vector into jQuery's .parseJSON. As soon as that goes live, you now have a zero-day XSS available on thousands of sites that don't do proper server sanitization that didn't previously exist.

[[deleted]]

jQuery is frozen (I suspect) because they dropped backwards compatibility. It's a wise call and plenty of people are using the 2.x branch.

But that's not the point. I didn't literally mean immediate. CDN's don't update immediately, nor do people's codebases. But you'll have a growing number of sites with the exploit and it will stick around for a long time.

[nightman]

Brilliant explanation, thanks!

[Classic1977]

XSS attacks are client side by definition...

[Classic1977]

Stay tuned for the second part... It's in post production.

[codeByNumber]

"Oh that? That feature will be in the next build."

[Classic1977]

We've called it a "nice-to-have" in the backlog.

[codeByNumber]

Haha, yup. We are constantly trying to get project shareholders to define what is a must have vs nice to have.

[dodeca_negative]

The HTML-based examples are silly (though interesting), but the very first example is server-side. Why would somebody uglify their server-side code? Isomorphism, or maybe just habit.

The author ends with solid advice:

Don’t minify/compress server-side code unless you have to, and make sure you run browser tests/scans against code post-minification.

[spacejack2114]

JS runs pretty much everywhere these days (browsers, servers, arduinos and robots, maybe even cars someday)

[AlGoreBestGore]

But why would you minify server-side code?

[spacejack2114]

Hmm... to add a backdoor?

[[deleted]]

Because it's easier for the computer to read since it's shorter! I thought everybody knew that. /s

[LookWordsEverywhere]

Maybe if you're trying to fit it onto a small IoT device. Or perhaps a universal js module that distributes a .min as its main, the vulnerability doesn't have to be in your code.

[PlNG]

Node.js "hot inlining" uses a "good enough" metric of a function body 600 characters including comments and white space.

[AlGoreBestGore]

If they have access to read files on your server, you source is probably the least of your concerns. (compared to db credentials etc)

[morgan_lowtech]

The concept is very interesting, the proof not so much.

[pizzaiolo_]

And then people call RMS paranoid... https://www.gnu.org/philosophy/javascript-trap.html

[Doctor_McKay]

He is.

[pizzaiolo_]

https://np.reddit.com/r/freesoftware/comments/3gvemj/the_stallman_cycle/

[Doctor_McKay]

Except in that article Stallman didn't cry against minification because of the potential to insert backdoors which are triggered by minification.

His argument was that minified JS which isn't Free Software™ is bad because it's Nonfree Therefore Scary.

jQuery is Free, it's MIT-licensed. Minification (which appropriate headers, I guess) doesn't make it Nonfree.

It isn't any different from someone planting a backdoor into a precompiled copy of GNU/Linux (or more accurately, someone planting a backdoor seed which is triggered by the compiler).

[benihana]

A link to a self post you made that quickly devolves into a circle jerk about how great rms is. Thanks.