To further enhance security, the app should not be able to modify the web interface at runtime.
This implies that the web interface is built upfront and served from a directory where the OTS service user does not have write permission.
Since it is already recommended to add HTTPS with a reverse proxy, that proxy can handle the files.
I propose implementing a new sub-command, 'build-web', into OTS that compiles and emits the static HTML into a directory.
This way, the operator can either call this manually when the static files need updating or automate it using systemd via a privileged execPreStart.
To reduce the frequency of updating static files, I would replace the call to /isWritable with a call to /config, which could emit the relevant dynamic data for the web interface to consume.
I would include at least the list of available expiry options from the configuration, and possibly a version so the frontend could know whether it is out of date.
From Luzifer in #177:
OTS contains compiled-in assets. They cannot change during runtime. There is barely a difference between statically compiling the frontend and baking it into the binary and statically compiling the frontend and hosting it using the nginx. The second variant can be changed easier.
Aside if you really want to go that way: make generate, edit the index.html in the frontend directory, let nginx serve it at ots.yourdomain.com and pass through the /api to the Go application: You're done. I don't see the benefit as you will loose the customization feature but you can do that.
This is mainly defense in depth, if an attacker can gain arbitrary code execution inside the go binary. I have not seen this in practice yet, but this is the attack vector I am trying to protect against. Since the API only ever sees ciphertext, the client is the weak point.
make generate is sufficient for our usecase, still a function that includes the customization would be cool.
Moved from #177:
To further enhance security, the app should not be able to modify the web interface at runtime. This implies that the web interface is built upfront and served from a directory where the OTS service user does not have write permission. Since it is already recommended to add HTTPS with a reverse proxy, that proxy can handle the files. I propose implementing a new sub-command, 'build-web', into OTS that compiles and emits the static HTML into a directory. This way, the operator can either call this manually when the static files need updating or automate it using systemd via a privileged execPreStart. To reduce the frequency of updating static files, I would replace the call to /isWritable with a call to /config, which could emit the relevant dynamic data for the web interface to consume. I would include at least the list of available expiry options from the configuration, and possibly a version so the frontend could know whether it is out of date.
From Luzifer in #177:
This is mainly defense in depth, if an attacker can gain arbitrary code execution inside the go binary. I have not seen this in practice yet, but this is the attack vector I am trying to protect against. Since the API only ever sees ciphertext, the client is the weak point.
make generateis sufficient for our usecase, still a function that includes the customization would be cool.