Missing CSRF protection

[ghost]

php/save.php and php/controller.php can be called without authentication cookie or CSRF token.

[bernhardreiter]

Looking at the issue to see if customers are interested.

Seems https://api.jquery.com/jQuery.getJSON/ calls are used in the php files,
we would need to modify them to add custom headers (which is one way for CSRF protection),
the other would be secure and samesite cookies.

So .getJSON to .ajax() and considering if using a different jquery or other library (as bundled jquery 1.11 is getting old).

[bernhardreiter]

Things which need to be done (aka rough plan):

• add javascript/html dialog to enter credentials and show successful or unsuccessful log-in
• add a backend endpoint to verify credentials (also way to save and manage credential infos on the backend)
• make security token be saved in the javascript part (e.g. in sessionStorage)
• evaluation if to use safe cookie or just a xhttp request header or both for enough protection
• change backend to accept security tokens
• replace .getJSON calls with .ajax() or different library to add a header (or cookie or both).
• (optional) check important js libraries for needed updated (e.g. jquery 1.11 -> jquery 1.12.4 or 3.x or a different library altogether)

[bernhardreiter]

Sunet contracted us (from Intevation) do resolve this issue, timeframe is within two month.

[bernhardreiter]

We need longer to fix this. (Corona has slowed us down, among other things.)
Our plan is to make progress this months, and get it done before the summer holidays at least. #142 maybe a blocker and not optional, as it does not make sense to add hacks to the old jquery version.

[bernhardreiter]

#142 seems to be under control, our new branch https://github.com/Intevation/intelmq-manager/tree/dev-python-backend-webpart has updated jquery and bootstrap libraries.

web client part

Now it would be useful to have a modal bootstrap3 login form from the webapp which works by using a POST endpoint and gets a token that will be used in subsequent requests to the server as part of the header. To have a backend to develop against, it would be cool to have a hug example, see hugapi/hug#863

We also have to make sure that the token is saved on the client, even if the page is switched, maybe the localsession storage can be used for this.

[bernhardreiter]

Some progress on our side in small steps:

• on client side, https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage works over our page switches in the Manager
• on server side we need a persistent storage of session data, which should work with several processes from python. We've started with sqlite (which is close to postgresql) in https://github.com/Intevation/intelmq-manager/tree/wip-csrf an alternative would be redis or a different message queue (abused) as db that IntelMQ uses anyway, however we should stay indepentend with the Manager for now.
• for fast token verification on the backend side there are two approaches
  a) always access the (shared) db
  b) use cryptography, e.g. https://pypi.org/project/jwt/
  As we need a user database anyway we'll first try to see if we can make sqlite access fast via each python thread having one connection

[bernhardreiter]

technical how to connect fast to a persistent session and user db

Idea: Using sqlite with a small db file should leave this file in the memory via the file system caches.

One problem: the sqlite3 module is not threadsafe and apache and other web server may use threads to requests fast.

Solution-idea: Trying a different python module apsw which is thread-safe (https://rogerbinns.github.io/apsw/pysqlite.html#pysqlitediffs)

Turns out apsw has problems with mod_wsgi (at least in our tests it did not work well, we expect the use of python subinterpreters and forking by mod_wsgi as possible root for conflicts between the two pieces of software.) So we went back to pysqlite.

[bernhardreiter]

#202 implements a working version of CSRF protection (with some rough edges, but it is a significant improvement over having no protection).

[ghost]

I think we can close here, as the authentication part is done. Thanks @Intevation for the implementation and @SUNET for the funding!