3 ms·
Synode: understanding and automatically preventing injection attacks on Node.js
- orf 9y agoEverything old is new again. Just when you thought we where done with all the PHP injection madness...
- wesleytodd 9y agoRe-writing dependency source files with another dependency is a much worse idea than vetting your dependencies before you add them to your project IMHO
- jessaustin 9y agoMaybe there's a setting to roll back the install if it finds vulnerable dependencies, rather than trying to fix them?
- calibas 9y agoIf 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.
- devwinportable 9y agowhy 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 9y agoIsn't the first part of your suggestion handled on OS level anyways? Aka. restricted user access, SELinux, AppArmor etc.
- adumbledore 9y agoThe 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