[Owasp-leaders] From a security point of view: Angular or React?

johanna curiel curiel johanna.curiel at owasp.org
Tue Jun 30 10:10:13 UTC 2015


I love this discussion and also the fact that it makes me aware of the gap
between devs vs security peeps

While we discuss what is more save to use, reallity is that if I have built
a site with Jquery and  need to 'switch' from the security pov to Angular
or react, I have to refactor
Thats a lot off work. Security folks are always ready to tell 'devs 'change
this change that' this is not secure etc..., but the amount of work involve
in this makes it difficult for devs to just go a fix things (especially
with the workload ). This is just a case, but this is a main issue for any
developer in the need to fix or change code because is not secure.

How do we approach this issue? Owasp wants to help devs by making them
aware, but I'm not sure we realize the work involve of devs and how to make
it easier implement security in their projects or worse, when a library or
dependency has suddenly become vulnerable.

regards

Johanna

On Tue, Jun 30, 2015 at 5:48 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:

> Correct, and the idea is that jqlite should be enough for any DOM
> manipulations (with DOM hacks kept under control :) )
>
> This means that there shouldn't be any need to have the jQuery api added
> to the application
>
> Dinis
> On 29 Jun 2015 11:16, "Mike Goodwin" <mike.goodwin at owasp.org> wrote:
>
>> "jquery is a banned API"
>>
>> That is an interesting statement. Angular comes with a built-in, home
>> grown implementation of jQuery called jqlite, which automatically falls
>> back on full jQuery if it is present. From their docs
>> <https://docs.angularjs.org/api/ng/function/angular.element>:
>>
>> *"all element references in Angular are always wrapped with jQuery or
>> jqLite; they are never raw DOM references"*
>>
>> The Angular way is to encapsulate all your DOM manipulation using
>> jQuery/jqlite inside directives. When you are writing a custom directive,
>> the target DOM element is passed in as a jQuery/jqlite element, so you
>> can't really avoid it.
>>
>> Mike
>>
>>
>> On 29 June 2015 at 08:22, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>>
>>> Thanks all for the great feedback, which matches the research I had done
>>> on it (see
>>> http://blog.diniscruz.com/2015/06/why-we-are-going-to-use-angularjs-13-on.html
>>> for the list of reasons we are going to go with Angular).
>>>
>>> Joanna, regarding jQuery, my experience (in both developing and
>>> reviewing jQuery apps) is that it tends to promote an 'lets just hack it to
>>> make it work' kind of development workflow. In jQuert code, there are
>>> always tons of DOM manipulations, which will always include (browser
>>> specific and other) hacks, and create code with quite a lot of dependencies
>>> and lack-of-isolation between components. Basically you shown me an large
>>> jQuery app (like the one we developed) and It most likely be an app hard to
>>> refactor, hard to maintain and hard to understand what really is going on
>>> (ironically the power of jQuery tends to create this stuff, since it is
>>> always possible to 'fix something' by adding a bit of jQuery somewhere).
>>>
>>> And of course jQuery is also a nightmare from a security point of view,
>>> since as mentioned on this thread there are quite a lot of sinks that will
>>> transform strings into code.
>>>
>>> In order to make our app secure and easy to code we are using the
>>> following stack/technologies:
>>>
>>> - no jQuery (as far as I am concert it is a banned API :)  )
>>> - Jade for creating html (i.e. no raw html and encoding by default on
>>> all variables)
>>> - 95%+ Unit Test coverage
>>> - NodeJs on the server (with one a version of the website created with
>>> NO Javascript)
>>> - AngularJS on the client, with full use of Angular components to keep
>>> code clean, easy to test and isolated (Controllers, Directives, Services,
>>> etc...)
>>> - CoffeeScript on both server and client (to promote good Javascript
>>> practices, keep code clean and easy to test)
>>> - Git Flow, with git submodules used to separate the code into different
>>> areas of responsibility
>>> - Docker for deployment and testing (with ability to start new instances
>>> of the site in seconds (on any branch))
>>> - Slack for team collaboration
>>> - GitHub for Issues (and of course code hosting :)  )
>>>
>>> I also have to say that I like the maturity and amount of thinking that
>>> has gone into AngularJS security. Yes there is a level of moving parts, but
>>> they push the development teams to have a really good architecture (which
>>> is key to enable all team members to write secure code).
>>>
>>> In fact, what I really like about our current development
>>> environment/workflow (the one based on Node, CoffeeScript and Jade) is that
>>> there are large parts of the code base that at the moment it is REALLY hard
>>> to create a security vulnerability. For example, since we use Jade for the
>>> views, I don't have to 'security review' design and UI changes since they
>>> are secure by default (and I have a test to check for the on case where
>>> un-escape content can be enabled). Compare this to the normal JSP or jQuery
>>> world where any code change is one small mistake away from creating a
>>> security issue. Basically the best way to prevent HTML injections (aka XSS)
>>> is to not have any HTML coding at all :)
>>>
>>> Dinis
>>>
>>> On 29 June 2015 at 00:21, Kim Carter <kim.carter at owasp.org> wrote:
>>>
>>>>  With Angular: Generally a lot of work for a large non-trivial
>>>> application. Angular is pretty much an all or nothing framework.
>>>>
>>>> With React and Flux: As much or as little work as you want it to be.
>>>> Many teams use React to replace small pieces at a time. The last client I
>>>> used React with I used it to replace the backbone views. Why only the
>>>> views? Because there was nothing wrong with the router or models and the
>>>> problem with the existing code base was the manual DOM manipulation and
>>>> events being in unknown states due to having many teams work on the code
>>>> base and all of which did things a different way. By using React to replace
>>>> a Backbone view at a time, the work load was very manageable. I attacked
>>>> the worst views first, unravelled them and replaced them with React
>>>> components. React is essentially a view engine, but can be used for
>>>> everything. With React, you can use as little or as much as you like.
>>>>
>>>>
>>>>  Kim Carter
>>>>
>>>> OWASP New Zealand Chapter Leader (Christchurch)
>>>>
>>>> c: +64 274 622 607
>>>>
>>>>
>>>>   On 29/06/15 08:35, Jim Manico wrote:
>>>>
>>>> JQuery was originally built to help with cross-browser quirks which is
>>>> becoming less of an issue. I see plenty of folks migrating away from it to
>>>> Angular and similar. There are a variety of migration resources on the net
>>>> and it's doable - but migration can be time consuming work.
>>>>
>>>> --
>>>> Jim Manico
>>>>   Global Board Member
>>>> OWASP Foundation
>>>> https://www.owasp.org
>>>>  Join me at AppSecUSA <http://appsecusa.org/> 2015!
>>>>
>>>> On Jun 28, 2015, at 10:22 AM, johanna curiel curiel <
>>>> johanna.curiel at owasp.org> wrote:
>>>>
>>>>   From a developer point of view, if I had to replace Jquery with
>>>> Angular or React how much work is that?
>>>>
>>>>  Imagine my entire front is completely dependent on Jquery...any
>>>> instructions or ideas how to achieve this without an excruciating QA?
>>>>
>>>> On Sun, Jun 28, 2015 at 4:09 PM, Jim Manico <jim.manico at owasp.org>
>>>> wrote:
>>>>
>>>>>  Angular is much better for XSS defense today, but React was built
>>>>> with a much more sound core and is likely to have a better future.
>>>>>
>>>>>  #nuance
>>>>>
>>>>> --
>>>>> Jim Manico
>>>>>   Global Board Member
>>>>> OWASP Foundation
>>>>> https://www.owasp.org
>>>>>  Join me at AppSecUSA <http://appsecusa.org/> 2015!
>>>>>
>>>>> On Jun 28, 2015, at 4:21 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>>>>>
>>>>>   Which one makes it easier to write secure code, has more features
>>>>> to help security and has better support for Security-focused tests?
>>>>>
>>>>> What do you see on the ground?
>>>>>
>>>>> Which one tends to create apps with more vulnerabilities?
>>>>>
>>>>>   _______________________________________________
>>>>> OWASP-Leaders mailing list
>>>>> OWASP-Leaders at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OWASP-Leaders mailing list
>>>>> OWASP-Leaders at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OWASP-Leaders mailing listOWASP-Leaders at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>>
>>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20150630/262bffa7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: owasp_member_EmailSignature.gif
Type: image/gif
Size: 3735 bytes
Desc: not available
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20150630/262bffa7/attachment-0001.gif>


More information about the OWASP-Leaders mailing list