No protection for CSRF

[DinisCruz]

Description

The current forms have no CSRF protection

Risk Analysis

It is possible to trigger the following actions which have some impact to the (affected) user:

• logout out
• login user into specific account
• create accounts as the user
• use the user to brute force the upstream TM 3.5 server for:
  • accounts (username and password)
  • emails (once we provide feedback on bad users)
  • spam valid users with 'here is the link to reset your pwd'

See the test routes.test.coffee for the full mapping of all actions possible (i.e. the attack surface)

References

• Express Security tips: http://webapplog.com/express-js-security-tips

---

TM-4.0-Security

[DinisCruz]

@michaelhidalgo do you want to have a go at writing a test that confirms this?

Basically you want a test that:

1. opens one of the affected pages (i.e. a GET or POST that affects server/user state)
2. checks if there is a csrf token on it

[romichg]

@DinisCruz I don't see how bullet points 2, 3 and 4 are a CSRF issue. They are all valid issues, just not CSRF. I will take this and break this up into actionable issues and arrange them into sprints accordingly.

[DinisCruz]

Well they are possible because any of those forms are not protected for CSRF

A key problem is that we should have no actions (that change state) on our website that can be triggered by anybody apart from the user

[DinisCruz]

yes @michaelhidalgo, and interesting way to test this would be to do the actions using pure http requests where you would prove: a) there are no unique/secret values that are needed to be provided in order for the request to work (i.e. the CSRF token) b) you can replay the request

[romichg]

True, but there are certain actions that change state without our ability to know context of the user :). Like creating an account or sending a password reset request. These are not CSRF then, since at that point our site has no knowledge of who it is actually behind the keyboard on the other side (or a bot). The way to solve these is to introduce progressive timeouts and CAPTCHA,

@michaelhidalgo and @DinisCruz lets not re-invent the wheel with the CSFR test tools. There are plenty of good tools out there that do exactly that - like Appscan and WebInspect.

[DinisCruz]

except that we don't have Appscan and WebInspect working at the moment and it will not be an easy task to do it (achieve the type of testing that we will need)

not to say that we shouldn't use Appscan and WebInspect on TM 4.0 (the more tools to hit it the better) but so far, in any of the TM sites, we don't have any repeatable workflow using those tools (Appscan and WebInspect)

[romichg]

So going back to our discussion of how a good secure programing should occur - most mature appsec programs have a repeatable process where an application gets scanned with one of these tools periodically in the life cycle.In fact this is what our MAST offering provides exactly :). I will talk with @tlaloc75 to see if we can get TM as part of that service.