On Wed, Oct 17, 2018, at 11:09 PM, Hagen Bauer wrote:

Has anybody tried to hide the direct api access behind a nginx reverse proxy url?

That would still need authentication right? Even behind nginx proxy.

Where do you plan to keep that secret when using a static website?

On 10/18/18 1:19 AM, Abhilash Raj wrote:

...

On Wed, Oct 17, 2018, at 10:39 AM, Hagen Bauer wrote:

...

Hi,

I am running a static website with jekyll and I want to integrate a form that executes a subription rest api call to mailman.

From my first investigation this seems to be a bad idea from a security perspective (rest api needs managaer access).

I agree, you should never be exposing your Mailman Core's API to Internet, because it is an administrative API.

To be able to do that entirely in front-end, you may even have to expose the password in front, which is definitely not a good idea.

...

Is there a secure way to do this? Any other ideas?

One thing you could do is have mailto:listname-join@domain.com URL in your site, that your subscribers can use to send an email to subscribe.

You might be able to embed our web frontend in an Iframe or something, I don't have any experience doing that or am not even sure if that'll work.

---

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/

-- thanks, Abhilash Raj (maxking)

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.com

And within the nginx proxy configuration on the server this would translate to

 localhost:80xx/"mailman-restapi-with-credentials"user@mail.com

First 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.com

Probably 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.

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.com

And within the nginx proxy configuration on the server this would translate to

 localhost:80xx/"mailman-restapi-with-credentials"user@mail.com

First 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.com

Probably 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/