add CSRF protection capabilities

[bernhardreiter]

Similar to certtools/intelmq-manager#111
the SPA should offer the possibility to log into the backend and use secure cookies
or request headers to protect against CSRF.

Right now the example configuration for apache only has Basic-Auth. So the current operational recommendation is to only use a browser for IntelMQ Fody and Manager that cannot access other sides. Or organise a better authentification protecting against this using the web server or proxies.

Implementation considerations

If certtools/intelmq-manager#111 is done, the experiences can be used to implement this for fody as well.

[bernhardreiter]

Implementation planning

We need

• An adaptation of the backend session store from sqlite to postgresql, as intelmq-cb-mailgen already uses postgresql and it does not make sense to use a second database.
• Adapt the javascript code from the manager to use from Vuejs
• find a fast way how the backend can be started, but the database connections stay open, needs testing

Idea:

• (optional) Check if the IntelMQ Manager can also use the postgresql backend, so there are two different types of accounts

[ghost]

Could a central IntelMQ component (such as the API) act as a authentication provider/proxy?
Or can we harmonize the authentication implementations in all IntelMQ Webinterfaces?

[bernhardreiter]

We probably should harmonise them if we can. (There was an issue once where I asked to give recommendations about how to build IntelMQ webinterfaces.)

Could a central IntelMQ component become an authentication provider/proxy? Yes, probably could.
But I am undecided if it should. The drawback would be some sort of complexity and a needed development leap,
which is always a general risk.

[ghost]

Hi,

I don't think we gain a lot when having a central IntelMQ authentication provider, but it would add a lot of complexity. Also, that component would be a single point of failure- given that, IIUC, fody does not access IntelMQ directly but only the (static) data written to a database, I think it would be better if fody is not locked down if an IntelMQ authentication provider/proxy is not accessible.

[bernhardreiter]

@schacht-certat yes, this is the drawback I was thinking of. However if fody and Intelmq manager are both used by a number of users, it does not make sense to have two completely different user account databases.

[ghost]

@schacht-certat yes, this is the drawback I was thinking of. However if fody and Intelmq manager are both used by a number of users, it does not make sense to have two completely different user account databases.

Yes, I think it would be cool if both could access the same userdb!

But I think implementing an authentication proxy/provider in IntelMQ would be overkill. The authentication portion of the session handling is basically only one method, that checks username/password and can easily be extended to pass those on to some external authentication provider (LDAP, some SSO... - a Postgres DB would already allow that).
The session handling on the other hand would in any case have to be part of the specific backend (intelmq-api, fody-backend) and (ideally) needs some kind of DB.

I'm just not sure how to best harmonize the DB backends in intelmq-api and fody-backend.

[bernhardreiter]

When trying to serve many requests quickly, each request has to be checked for authorisation. So there needs to be a backchannel for all serving workers to know which client is currently authorized. But this does not need to be a database, it could be a signed token like JSON Web Token (JWT). In the new IntelMQ Manager we tried to use a shared database, but found out that this is difficult to do fast with Apache's mod_wsgi and the two sqlite Python adapters we've tried. From this I think that using a JWT approach would be slightly better as it avoids this problem and I'd try it first. This would mean: no database necessary for the session information, just a shared secret (or a public key) for all workers.

[bernhardreiter]

The quickest path to a working solution is to lift as many code as possible from https://github.com/certtools/intelmq-api for fody-backend. And easiest would be to just require intelmq-api as module and then import session or so.

Later intelmq-api could be extended to provide postgresl support for the session database as a variant, for the installations that use the postgresql output bot anyway.