Describe the bug
Any user can create a subdomain for any domain on the server and create content using that domain. The Add Web Domain button does not validate whether or not the domain created is a subdomain for a domain already on the server. If user1 owns domain1.com and uses the nameservers for the HestiaCP server, user2 on the same server can create any subdomain for domain1.com and upload any content they want and act like they own the domain. As long as both users are on the same server and the domain is being managed by the same DNS server. This can be a problem for shared hosting environments. Additionally users can send e-mail from this subdomain which would appear legitimate for most e-mail clients since the SPF and DKIM records would be valid.
To Reproduce
What steps did you take when the issue occured?
Point domain to the HestiaCP server using the nameservers.
Add the TLD to one user using the Add Web Domain.
Add a subdomain of the TLD to another user using the Add Web Domain and check "Create DNS Zone".
View both domains in a browser.
Expected behavior
Throw an error if the user tries to add a subdomain using the Add Web Domain form if the TLD exists for another user (alternatively make a checkbox to enforce this or not).
NOTE: Please do not enforce this for command line and API calls since some shared hosts give out free subdomains. Enforcing this at a user level (i.e. the PHP form) would be a better option.
Operating system:
Ubuntu 20.04 LTS
Hestia Control Panel version:
v1.3.2
Additional context
DirectAdmin has added a checkbox to their settings for this, might be a better solution:
(Link to DA feature request for further info: https://www.directadmin.com/features.php?id=925)
Validated all of the above with KuJoe. We have quite a few more concerns specific to Hestia, can someone at HestiaCP reach out privately? https://twitter.com/sickcodes
The suggested solve in your PHP script did't work as it allowed adding subdomains under different users via api.
2nd option used an outdated list and wasn't perfect.
We will update it every Hestia update to the last version. To change v-add-web-domain-allow-users / v-delete-web-domain-allow-users will to allow / disable the security check. For that domain only. To be used for developers / Or any other reason you might...
We will ship the fix together with 1.4.0 after beta testing.
Good idea implanting the fix as optional feature as obviously not all end users need the security enhancements, mainly only those involved with sub-hosting or sub-usership.
I'll do some testing shortly myself and we'll publish the findings :) great work team!
Describe the bug
Any user can create a subdomain for any domain on the server and create content using that domain. The Add Web Domain button does not validate whether or not the domain created is a subdomain for a domain already on the server. If user1 owns domain1.com and uses the nameservers for the HestiaCP server, user2 on the same server can create any subdomain for domain1.com and upload any content they want and act like they own the domain. As long as both users are on the same server and the domain is being managed by the same DNS server. This can be a problem for shared hosting environments. Additionally users can send e-mail from this subdomain which would appear legitimate for most e-mail clients since the SPF and DKIM records would be valid.
To Reproduce
What steps did you take when the issue occured?
Expected behavior
Throw an error if the user tries to add a subdomain using the Add Web Domain form if the TLD exists for another user (alternatively make a checkbox to enforce this or not).
NOTE: Please do not enforce this for command line and API calls since some shared hosts give out free subdomains. Enforcing this at a user level (i.e. the PHP form) would be a better option.
Operating system:
Ubuntu 20.04 LTS
Hestia Control Panel version:
v1.3.2
Additional context

DirectAdmin has added a checkbox to their settings for this, might be a better solution:
(Link to DA feature request for further info: https://www.directadmin.com/features.php?id=925)
For additional reference, here's an old thread from VestaCP with 2 possible solutions (mine being the worst of the 2):
https://forum.vestacp.com/viewtopic.php?f=13&t=9175
The text was updated successfully, but these errors were encountered: