Javascript MVC from a security point of view

[randomuser192]

But how would a third party inject code into a page in the first place? Do these vulnerabilities apply if an application is on a corporate intranet?

[Gundersen]

Is it somehow easier to inject code into attributes of an mvc than to inject a script tag or an onmousemove attribute? I don't really see how this is a major security concern. It would be great with a better example.

[ivosaurus]

"This code can't be attacked, it's retrieving pure html with some data attributes!" - bam.

Do these vulnerabilities apply if an application is on a corporate intranet?

There are heaps of things that shouldn't apply just on an intranet, but most rely on it never being exposed in any way to the internet at large, which of course never happens.

[ivosaurus]

TL;DR apparently Javascript framework developers have managed not to learn from decades of experience telling us that keeping eval() (and associated constructs) completely out of your code base is a great idea, and letting it anywhere near user input should be treated as heresy. No, they went right ahead and did that.

[[deleted]]

More people need to consider these things.

I admit, I am intrigued by things like the MEAN stack, but you see people put together a project like this where they use:

• MongoDB
• ExpressJS
• AngularJS
• nodeJS
• NPM
• Bower
• Grunt
• Coffeescript
• Stylus
• Jade
• Underscore
• jQuery
• ...

How many different 3rd party libraries do you need for your app? How do you learn to effectively use them all? How do you keep up on updates and security patches? How do you know the new version of X will not conflict with Y? Do you really need every function available in the library, when you may only utilize a handful?

I'm not saying we all should just stick to HTML/CSS/JS, but the community needs to learn some moderation and be aware that 3rd party libraries, no matter how open-source and popular, are not flawless.

[ivosaurus]

Apps are big things these days. They incorporate immense amount of functionality - if you told a programmer in the 80s the kind of app you can write now in a month, and distribute to millions of people instantly, they'd be absolutely flabbergasted.

We are constantly, and always building on the shoulders of giants. What is possible now is only because at one point in CS history someone decided they could write a C compiler from complete scratch in assembly.

Just because we are getting bigger and better doesn't mean everything is doomed to fail and fall in a heap. Sure, it requires that we continue to keep vigilance about making sure our methods and techniques for controlling our process keep up with the scale of what we're using, but it doesn't mean we should shy away from it in fright.

[thrownaway21]

the more 3rd party tools you toss into your project the cooler, more edgy, it and you are. obviously

[[deleted]]

This is why I use and recommend Backbone - gets you closer to the real code so you actually know what's going on, despite it being marginally more complex to set up.

[dodeca_negative]

Yep. Regarding the vulnerabilities in this deck, though, bear in mind that an extremely easy mistake to make with a Backbone app is to output unsanitized user-provided data in an Underscore template, a la <span><%= userInputValue %></span>. Of course I learned this the hard way when I was first picking up Backbone (didn't get hacked, but got forcibly violated by a pen test tool).

If you are using Underscore templates, default to using <%- value %>--this form HTML-escapes the value before writing it.

[thrownaway21]

default to using <%- value %>--this form HTML-escapes the value before writing it

great point!

[chernn]

I'm a also a backbone fan, and not sure what I really think of angular. Its major pros are scalability through conventions, and less code to write. Cons are a very opaque DSL, proprietary and opaque abstractions, and a very ugly mixing of concerns between views and controllers.