Why this week’s release came out a day early

SimpleScrumTools releases on Fridays. Changes collect on our development copy during the week, and on Friday they go to production together. This week’s release went out on Thursday, October 8, one day early, because it carried four security fixes. We do not hold a security fix for a calendar.

The review

Before each release we pair a function test with a security review of everything not yet in production. This week the review covered the whole product, not only the new work. It found nine issues worth fixing. We ranked them by what each one could do to a team that uses SimpleScrumTools, and fixed the four at the top first.

A gap in last week’s fix

Last week we wrote about a pre-account takeover. We fixed it in the step that links a Google or GitHub sign-in to an existing account. This week’s review found a second route to the same class of defect, through the link that confirms an email address.

That is the lesson we took from it. Last week’s fix closed the route we found, and we described it as fixing the defect. A fix closes one route. The class stays open until someone has checked every route into it. This time we checked the other places the same class could reach, and changed two of them. A confirmation link now works only for the person signed in to the account it was sent to. A password reset now disconnects Google and GitHub sign-in. The release notes below say what that means for you.

A file that could stop the server

The second fix is in CSV import. The importer read a file and built a table from it before it checked the file’s size against its limits. A file of a particular shape could use up the server’s memory while that table was built. That is a denial of service: it takes the product away from everyone, not only the person who sends the file.

The importer now applies its limits while it reads. It stops at 1,000 columns on a line, and it keeps only the rows it will import. On our hosted test copy, files of that shape are now refused in under half a second, and the server keeps working.

Two more

The third fix is for cross-site request forgery at sign-in. A page on another website could sign your browser in to an account that was not yours, and anything you then typed would go into that account. Sign-in, and every other request that changes data, now refuses a request that a page on another site can send.

The fourth fix is in project overrides. An override can hide a project from one person. It stopped them reading the project, but it did not stop them changing it. Hiding a project now removes every permission that person has on it.

Check a fix by trying to break it

For each fix we wrote tests, then broke the fix on purpose and confirmed a test failed. When this release went out, the suite held 3,457 tests, and all of them passed. Tests run code in isolation, so we also ran each fix in the real app. For the sign-in fix, we built a page on a second site that tries the forgery in a real browser. We ran it with the fix switched off, and the browser ended up signed in to the wrong account. With the fix on, nothing happened. A test can only show that a fix works if the same test fails without the fix.

Midweek, the 310-check function test ran against the hosted development copy, using throwaway accounts and the real HTTP routes. Ten checks failed. Each one was behaviour we designed or a check that had gone out of date, and none was a defect.

The review’s other findings are lower severity. They are queued for the coming releases.

SimpleScrumTools is free for teams of up to 5 members, with no card required. Create a free account.