4 ms·

Unauthenticated installers have been a dumb idea from day 1. This finally looks like the right opportunity to get rid of them. I'm sure that having an addition

by ge0rg 9y ago

Unauthenticated installers have been a dumb idea from day 1. This finally looks like the right opportunity to get rid of them. I'm sure that having an additional step to verify your read/write access to the installation directory (eg. by means of a token file) isn't too big a hurdle for users, and it will properly close off this attack surface.

tyingq 9y ago
Many of them could remain mostly as-is in the case where the database is local, as they already ask for the database name and password, and don't move forward until it's right. So just adding the extra step when a remote database is specified might suffice, and preserve the easy install for most users.
- nsgi 9y ago
  As discussed in the article, this is still potentially insecure when using shared hosting.
- TazeTSchnitzel 9y ago
  That won't help you if your username is "root", your password is "", your hostname is "localhost" and your database is "database".
- hannob 9y ago
  That was my initial idea I proposed as a fix. However I am not really comfortable with it and came to the conclusion I don't think it's a good fix. Ultimately that makes a pretty bold assumption: That if you have database credentials on a host this allows you to control other people's webapps in some situations. That's not reasonable. I could just be another customer at a webhoster and I don't think it's reasonable to assume that customers are allowed to hack each other. I think a real additional authentication step for all installations is the right solution.
  - tyingq 9y ago
    Sure. Shared hosting usually uses remote databases, though I suppose you could install a DB locally and fire it up. That assumes you land on the same physical host as your victim, which isn't likely at all but the smallest hosts. And, shared hosting is pretty risky anyway :). But I do get your reasoning.
lsaferite 9y ago
It seems like the MediaWiki process is decent. For non-technical people, an installer that generates a config file you then upload seems like a reasonable alternative. It ensures you know the correct DB details and such as you generate the config file and that you have write permissions to the server when uploading. As a bonus, the web app doesn't need write access to make this system work. That is a huge security whole itself.

by ge0rg 9y ago

tyingq 9y ago

Many of them could remain mostly as-is in the case where the database is local, as they already ask for the database name and password, and don't move forward until it's right. So just adding the extra step when a remote database is specified might suffice, and preserve the easy install for most users.

nsgi 9y ago
As discussed in the article, this is still potentially insecure when using shared hosting.
TazeTSchnitzel 9y ago
That won't help you if your username is "root", your password is "", your hostname is "localhost" and your database is "database".
hannob 9y ago
That was my initial idea I proposed as a fix. However I am not really comfortable with it and came to the conclusion I don't think it's a good fix. Ultimately that makes a pretty bold assumption: That if you have database credentials on a host this allows you to control other people's webapps in some situations. That's not reasonable. I could just be another customer at a webhoster and I don't think it's reasonable to assume that customers are allowed to hack each other. I think a real additional authentication step for all installations is the right solution.
- tyingq 9y ago
  Sure. Shared hosting usually uses remote databases, though I suppose you could install a DB locally and fire it up. That assumes you land on the same physical host as your victim, which isn't likely at all but the smallest hosts. And, shared hosting is pretty risky anyway :). But I do get your reasoning.

lsaferite 9y ago

It seems like the MediaWiki process is decent. For non-technical people, an installer that generates a config file you then upload seems like a reasonable alternative. It ensures you know the correct DB details and such as you generate the config file and that you have write permissions to the server when uploading. As a bonus, the web app doesn't need write access to make this system work. That is a huge security whole itself.