Add a security section to the front-end guide

[toolness]

As mentioned in #158, we should have section on front-end security!

Topics can include:

• Understand the same-origin policy

• XSS attacks and mitigation strategies

  • Avoid manually constructing HTML and passing it to .innerHTML/$.fn.html() if possible
  • Prefer templating systems that have a semantic understanding of HTML (e.g. JSX)

• Understand the threats posed by untrusted, user-provided data

  • This includes XSS but also goes beyond it--for instance, even if you're escaping the data properly, if you're presenting it in a way that looks "official", e.g. as the sole content of an <h1> at the top of a page, that could be used to mislead people.

• Understand what click-jacking is and why it should be prevented via e.g. the X-Frame-Options header, when possible.

Some forms of exploit mitigation are collaborations between front and back-end. For example:

• Content Security Policy is configured via a HTTP header sent along with a web page, but it usually requires front-end code to conform with it in a certain way (e.g. by not including inline scripts).

• Cross-site Request Forgery (CSRF) is an attack that needs to be prevented by a collaboration between front and back-end code (the back-end needs to reject requests that don't have a CSRF token, while the front-end needs to provide the token).

So I'm not sure whether these things should go in the front-end guide vs. some kind of back-end/security guide, or both.

[konklone]

I'd love to see something included about avoiding unnecessary use of third parties (e.g. self-hosting Google Fonts instead of linking to them by reference, not using code.jquery.com or ajax.googleapis.com, etc.).

[hbillings]

It sounds like this originally came up in relation to ATO pentesting. We're going to chat more about this in the rally on Friday. It would be helpful if we could chat with folks who have been through this process and see what kinds of issues have come up.

@toolness, I think what you've outlined here is valuable regardless of what else comes up in the rally, particularly things like CORS and sanitizing data. Explicit guidance would be better than implicit, to mangle a Zen of Python saying. :)

[toolness]

Cool! Part of what I wrote was also a reflection of issues that came up during CALC's ATO pentesting, if that helps, though @jseppi might have additional feedback.

[jseppi]

I think @toolness covered what came up in CALC's pentesting.

One of the findings was that direct user input was shown on the page in a way that could make the site look broken. It wasn't really a security problem, but a presentation/trust problem, especially given that the bad input was read from a URL query param.

The pentesters also found that some user input would cause the page (and perhaps even the browser) to crash. This was due to a code bug that resulted in an infinite loop. Again, not really a security problem, but something like that could have hurt the site's reputation or have been used to maliciously crash a link recipient's browser.

CALC did have an XSS bug, but we luckily caught it before the pentesters, fixed it in our legacy jquery code, and then totally mitigated similar problems by switching to React.

[msecret]

After discussion, we decided to keep the focus of the guide on the mitigation strategies rather the then threats. Mitigation will be how the guide is organized. Threats will be part of each mitigation strategy section. We also decided that finding existing documentation on the internet should be done first, and just link to it, rather then write more guidance. In accessing whether the existing documentation is good enough, we decided it has to be practical advice for teams to actually implement the mitigation strategies

Created the following issues to split up the work:

• https://github.com/18F/frontend/issues/174
• https://github.com/18F/frontend/issues/175
• https://github.com/18F/frontend/issues/176
• https://github.com/18F/frontend/issues/177

[msecret]

This could have some useful content: https://simplesecurity.sensedeep.com/web-developer-security-checklist-f2e4f43c9c56

[xtine]

We have a Security page in place. Closing this issue in favor of new issues to target addition or changes to existing sections under the Security page.