Meteor code security review

[kmcculloch]

Need to work out a security review process in advance of releasing the code (or decide never to do it). I know nothing as yet about the meteor community so I don't know what resources there are for this.

[dcwalk]

@b5 did you ever connect with @zsck about this? Thoughts on how to proceed are welcome.

[arcrose]

I'm happy to help with this. My buddy Michael who was with me at last Tuesday's meeting is also interested in contributing to a security review.

Some things we can do to help:

1. Review the source code
2. Perform a vulnerability assessment on the (live? a local instance?) application.

Are the contents of this repository the only one we're looking to review right now? Are there any documents we should read before starting? Could somebody identify the parts of the application that deserve the highest priority in a review?

Answers to these questions will help to get the process started, along with any other advice we can get about using, setting up, and navigating the application.

[dcwalk]

I think this is our priority for security, so the Archivers App code base including deployment config/scripts. Maybe @kmcculloch and @b5 could coordinate with @zsck (and Michael), how to proceed?

Happy to help facilitate that, it seems like coming out of a review some other issues would be touched on/addressed: #52, #51, #10, #2, #1 and some decisions RE: documentation on deployment, etc... could occur?

At some point we have bigger security questions (see: https://github.com/edgi-govdata-archiving/overview/issues/50), but I think a run through of a scoped project would be a great first start.

[dcwalk]

Per our meeting on Thurs, Mar 9 we have a plan to open the code!

Roadmap to opening Archivers App, target date of Friday March 17:

1. code cleanup/linting complete
2. integration of security middleware into dev process per @zsck’s recommendation
3. Add middleware recommendations to org-wide project guidelines
4. identify areas of codebase that are of concern and open issues (e.g. memory usage, imports api)
5. address https redirect and ensure CORS handling okay
6. throw a license on the code

[titaniumbones]

Amazing! Great work!

On March 9, 2017 8:50:07 PM EST, dcwalk notifications@github.com wrote:

Per our meeting on Thurs, Mar 9 we have a plan to open the code!

Roadmap to opening Archivers App, target date of Friday March 17:

1. code cleanup/linting complete
2. integration of security middleware into dev process per @zsck’s recommendation
3. Add middleware recommendations to org-wide project guidelines
4. identify areas of codebase that are of concern and open issues (e.g. memory usage, imports api)
5. address https redirect and ensure CORS handling okay
6. throw a license on the code

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/edgi-govdata-archiving/archivers.space/issues/47#issuecomment-285549233

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[dcwalk]

@b5 and @zsck can we get an update on this? Anything I can help move forward? Are we still on track for a Friday launch?

[b5]

We're still on track to open it up this week. I'm in meetings for the rest of the day, but should be able to hit publish sometime this evening

[b5]

Ok update on this: @zsck suggested some fantastic resources for checking security:

• NSP
• Helmet
• eslint-plugin-security

We should definitely get the eslint-security plugin up & running, and save Helmet & NSP for an our new app that'll have an express server involved. As for this app, meteor publishes a solid security checklist. That Checklist for us:

• [x] Make sure your app doesn’t have the insecure or autopublish packages.
• [x] Validate all Method and publication arguments, and include the audit-argument-checks to check this automatically.
• [x] Deny writes to the profile field on user documents.
• [x] Use Methods instead of client-side insert/update/remove and allow/deny.
• [ ] Use specific selectors and filter fields in publications.
• [x] Don’t use raw HTML inclusion in Blaze unless you really know what you are doing.
• [x] Make sure secret API keys and passwords aren’t in your source code.
• [x] Secure the data, not the UI - redirecting away from a client-side route does nothing for security, it’s just a nice UX feature.
• [x] Don’t ever trust user IDs passed from the client. Use this.userId inside Methods and publications.
• [ ] Set up browser policy, but know that not all browsers support it so it just provides an extra layer of security to users with modern browsers.

I'll do what I can to work through this list ASAP, with a goal of being done this evening.

[titaniumbones]

@b5 that's really helpful thank you!

[b5]

Alright team, @kmcculloch & I have gone through the whole list, and I'm feeling confident that we've done our due-dilligence in securing the app. The only outstanding task is adding specific filters to selector fields, which I'm going to create a new issue for. So with that, I think it's finally time to Open this thing up. Thank you so much to everyone who worked hard to get this thing out in the open where it belongs. Y'all know who you are ;)