Hey Matt, Really appreciate the quick feedback and will definitely update to the latest rule pack!
Thanks! On Friday, June 5, 2015 at 5:32:28 PM UTC-4, Matt Steele wrote: > > After working with HP we believe some of this was caused by an improper > parsing algorithm inside Fortify. > > If you have the opportunity to update to the latest rule pack, it appears > to have resolved all our issues and does not report any violations we're > concerned with. You might want to open a support ticket with Fortify for > more details. > > On Fri, Jun 5, 2015 at 12:33 PM, Patrick Woo <[email protected] > <javascript:>> wrote: > >> Hey Matt, >> >> I'm actually facing the same issue as well with Fortify scans, has there >> been a resolution on this or is this a concern? >> >> >> On Tuesday, April 7, 2015 at 12:19:39 AM UTC-4, Sander Elias wrote: >>> >>> Hi Matt, >>> >>> Let try to answer your concerns. >>> >>> 1. No, I have not. >>> 2. Only if you don't trust AngularJS. >>> 3. Yes, While I do not thing this is a security issue, it might be >>> an issue that is simple to fix, and don't throw up tools like fortify >>> any >>> more is a plus. >>> >>> Let me expand a bit on #2. The tool like you are using is normally use >>> to (dynamically) check scripts you have to include for 3rth party stuff >>> (ads/social stuff mostly). You don't want any of those scripts to >>> manipulate things like the history. However, in the way Angular gets used >>> mostly, history manipulation might just be what you need. You even want >>> redirect your app to some other location, this is actually quite common. >>> On the security site of things. Basically, if you insert a single 3rth >>> party script, you are screwed. If there is an browser-plugin, you are >>> screwed. If you have users, (you know the one, with the username/password >>> on a sticky, in view!) you are ... >>> There is no such thing as a secure client-side app. That is including >>> wep-app's who might be even a tad more insecure. But it is also including >>> ALL kind of other apps. Some suggest that native apps are more secure, but >>> thats not true.. If you expose a data-channel from your server to the >>> outer-world, you better secure that rigorously. And that's about what you >>> can do. >>> All the above does not mean you can throw your hands in the air, and >>> neglect all the security stuff above, you need all of that, otherwise you >>> are putting out really low hanging fruits. >>> >>> Regards >>> Sander >>> >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "AngularJS" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/angular/dK-S20SXQRg/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
