Since I am running mailman in a docker container I thought it may be an approach to put https://github.com/dthree/mailit along.
This seems to be used by a good amount of people and would allow me to have a rest api just for sending the mails to mailman.
I am not a javascript specialist but currently I do not see any security risks.
Do I miss something?
Regards Hagen
On 10/19/18 8:05 PM, Stephen J. Turnbull wrote:
Hagen Bauer writes:
Has anybody tried to hide the direct api access behind a nginx reverse proxy url?
Sounds straightforward.
I doubt anybody's done it, though, because you still face the problem that anybody with that access is a site manager, with unclear limits on their power outside of Mailman. (Shouldn't be much they can do outside of Mailman, but I wouldn't bet my host on it.) In many cases, the real site manager is also the host admin, so they have sufficient access to a shell account. There's no need for her to have a proxy; why make it available to people who are supposed to have less power?
Note I'm *not* saying this *never* makes sense. I'm just saying that in a lot of cases it won't buy you very much because Mailman isn't set up to provide granular authorization of REST endpoints.
on the Webseite I would have a url like this
mailmanserver.tld/subcsribe/user@mail.comAnd within the nginx proxy configuration on the server this would translate to
localhost:80xx/"mailman-restapi-with-credentials"user@mail.comFirst of all, the address to subscribe is a variable, so at a bare minimum your nice static site has to provide a form, which isn't very static. I guess you could put the URL to the nginx proxy as the action URL in the form, but then the proxy needs to deal with a form-encoded query string to translate to the appropriate REST endpoint.
I suppose you could also have the user type the URL including the email address into the browser address bar, but Abhilash's idea of providing a mailto:subscribe@mailmanserver.tld URL seems more convenient. The mailto URL also solves the problem of confirming ownership of the mailbox, since that logic is built in to the subscribe-by-mail code.
Second, if your proxy is configured very carefully, you might be able to restrict this to only the exact operations you want to expose, here subscription. However, although the email interface implements verification by providing a one-time token that must be read from the mailbox of the address (and so proves ownership of the mailbox), I don't think the REST API implements operations like that. IIRC that is implemented in Postorius. (Abhilash?) If my memory is correct, you would also need to implement that, and that's definitely not static.
So the public does not see the credentials. And if my nginx host config is hacked I have a problem anyway.
I can't speak for Abhilash, but what would worry me is not that nginx is already hacked, but rather that if not properly configured, it might be possible for someone to access REST endpoints you don't want exposed through this interface, and maybe even to other parts of the webserver. To give a simple example, consider a variant on the ancient Apache traversal bug:
mailmanserver.tld/subscribe/../unsubscribe/user@mail.comProbably nginx and/or Mailman and/or your proposed proxy config are already capable of stopping this particular well-known attack, but undoubtedly there are more sophisticated attacks that I don't know about.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/