fix(web-api): percent-decode before path-splitting

[tsani]

This PR patches a path traversal vulnerability.

I would like to thank the IT department at McGill's School of Computer Science for noticing this bug, and Max Kopinsky for working on the patch with me.

• Kind: bugfix

I did not separately report the bug since the fix is quite simple.

Description

Without this patch, try visiting http://localhost:8080/css/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc/passwd assuming learn-ocaml is running on port 8080. Notice that this successfully downloads the file /etc/passwd. There is some code present in learn-ocaml that is supposed to prevent this, namely the function sanitise_path, but since the path-splitting operation is performed before the percent-decoding, it is possible to smuggle slashes deeper into the system by simply percent-encoding them as %2f.

Checklist

• Read the CONTRIBUTING.md guide and:
  • Use Atomic Commits so each commit gathers a single logical change
  • Use Conventional Commits regarding commit messages (needed by our release toolchain)

Note to maintainers

• Read this wiki page.
• Make sure the PR has a milestone.
• Assign yourself before merging.
• Either do a regular merge:
  • for PRs containing several commits following conventional-commits,
  • or for PRs containing 1 commit shared with a later PR (to preserve the SHA1)
• Or do a squash-merge:
  • for PRs containing only 1 commit (not shared with a later PR),
  • or for PRs containing several commits that need not be kept in the history;
  • → Update the commit message header with a conventional-commit type,
  • → Add a footer Close #… if a related issue exists.

[erikmd]

Ouch; many thanks @tsani & all the people involved, for this critical fix.

I'll merge the PR as soon as the CI is green, then publish a stable release.

[erikmd]

Cc @yurug @AltGr this makes me think we should probably setup a security policy (for vulnerability disclosures etc.) in the github repo (cf. https://github.com/ocaml-sf/learn-ocaml/community); let's discuss this point at our next maintainer telco!