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

Mike Goodwin mike.goodwin at owasp.org
Tue Jun 30 12:41:37 UTC 2015


"with DOM hacks kept under control"

I always though their motivation was file size (jqlite = 2Kb, jQuery =
30Kb) but I guess the size of the file and the opportunity it presents to
hack the DOM are probably correlated, especially if jqlite does not support
a load of uncontrolled jQuery plugins ;o)


On 30 June 2015 at 11:10, johanna curiel curiel <johanna.curiel at owasp.org>
wrote:

> 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/cddadb5f/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/cddadb5f/attachment-0001.gif>


More information about the OWASP-Leaders mailing list