
Synode: understanding and automatically preventing injection attacks on Node.js - godelmachine
https://blog.acolyer.org/2018/03/12/synode-understanding-and-automatically-preventing-injection-attacks-on-node-js/
======
adumbledore
The article doesn't actually talk about preventing injection attacks, but
rather identifying potential attack surfaces by doing an AST search for
eval/exec in combination with mutable variables. The article does not explain
what limitations exist for their runtime check:

> This results in 5 false positives (out of 56 benign inputs), which are
> caused by limitations of the static analysis (3/5) or node types outside of
> the safe set (2/5).

Besides that, it's good to see more security tools - especially when the
research is open source: [https://github.com/sola-
da/Synode](https://github.com/sola-da/Synode)

------
wesleytodd
Re-writing dependency source files with another dependency is a much worse
idea than vetting your dependencies before you add them to your project IMHO

~~~
calibas
If the only other solution is creating your own custom version of a vulnerable
dependency, I can see how this could be useful. Not the "best" solution, but
certainly practical as far as making code more secure.

------
orf
Everything old is new again. Just when you thought we where done with all the
PHP injection madness...

------
devwinportable
why not add an android-style permission flags on nodeJS?

eg) nodejs profile with:

\- exec disabled

\- file write access limited to ./tmp, ./docs, ./tests

\- file read access limited to ./tmp, ./docs

\- network listening: port 1000~11000 allowed

And why not have a 'sesame points' system for dependencies?

eg)

\- ownership-change within 3 weeks: -20 points,

\- static analysis finds something wrong: -20 points

\- badges: 'file-read badge', 'exec-badge', etc.

~~~
mAritz
Isn't the first part of your suggestion handled on OS level anyways? Aka.
restricted user access, SELinux, AppArmor etc.

