XSS, CSRF, mitigating common web vulnerabilities in Loopback + AngularJS

[Pandaiolo]

Hello,

I am using the Angular client, and while angular looks decently protected against XSS, if following good practice, I am not sure I will avoid 100% XSS in the future.

Loopback Services for angular stores the token in the javascript object, which would make it available to an attacker if an XSS flaw is successfully exploited, I guess ?

Is this a concern ? Is an attacker with a valid token able to impersonate the user and all its permissions, until token expires ? Or forge a CSRF ?

Should I implement an additional layer of security ? Would an SSL-only app would be more secure ?

Examples here :

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

What are the best security practice when using Loopback with Angular client ? The web is an hostile place and I do not want to underestimate the threat :-)

Thanks !

Aurelien

[Raymond Feng]

LoopBack supports Express compatibile middlewares to mitigate the potential attacks. For example, we can use:

https://github.com/krakenjs/lusca

Thanks,

---

Raymond Feng

Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

--
You received this message because you are subscribed to the Google Groups "LoopbackJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loopbackjs+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pandaiolo]

Thanks, that makes sense indeed !

I'll have a look on express middlewares that play nice with Angular

Thanks

Aurelien

[Miroslav Bajtoš]

On Monday, May 12, 2014 5:43:45 PM UTC+2, Pandaiolo wrote:

Loopback Services for angular stores the token in the javascript object, which would make it available to an attacker if an XSS flaw is successfully exploited, I guess ?

 

Is this a concern ? Is an attacker with a valid token able to impersonate the user and all its permissions, until token expires ? Or forge a CSRF ?

 

Yes, that's correct. However, if you have a XSS vulnerability, then the attacker can do pretty much anything, regardless of the authentication mechanism used. He can even call the same lb-services used by your own code.

Here is what OWASP says on this matter in the CSRF Prevention Cheat Sheet you mentioned:

It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented.

 

Should I implement an additional layer of security ? Would an SSL-only app would be more secure ?

SSL-only is a good idea, many big players (google, twitter, facebook, github) are already doing that.

The lusca module pointed out by Raymond is a good thing to consider too.

Miroslav