[CPANEL-26332] API Tokens and WHM Function list-zones
-
Hello @bellwood, listzones is controlled with the Manage DNS Records privilege. It's found under the "Initial Privileges" section in WHM >> Manage API Tokens. Thank you. 0 -
This is incomplete - I have to allow "Everything - All Features `all`" to get a list of every zone on the server. Seems horribly insecure to need a "god" token to simply get a list of zones. 0 -
This is incomplete - I have to allow "Everything - All Features `all`" to get a list of every domain on the server.
Hi @bellwood, I've reproduced this behavior and opened case CPANEL-26332 to report the issue. I'll monitor this case and update this thread with more information as it becomes available. Note that an additional case (CPANEL-24676) is open to correct this behavior for the listaccts WHM API 1 function. That case is planned for publication with cPanel & WHM version 80. Thank you. Post Edit History: 1. Corrected the first case ID to reflect CPANEL-26332.0 -
@cPanelMichael thanks for the stellar customer service. Will keep an eye out for this in v80. 0 -
@cPanelMichael I see CPANEL-24676 was remediated 03-21-2019 however as of v80.0.11 I'm still unable to see all zones on a server with just the list-zones token permission. Interesting as well, the resolution for the case mentions listaccts, not listzones: - Fixed case CPANEL-24676: API Tokens: Ensure that the listaccts API call respects the 'list-accts' priv.
0 -
Hello @bellwood, It looks like CPANEL-26332 was utilized in this thread's title, but incorrectly entered as "CPANEL-24676" in my previous response. Apologies for the confusion. I've edited my previous response to correct this. I'll continue to monitor CPANEL-26332 internally and report back here more information on it's status as it becomes available. In summary, there are two cases associated with this thread, CPANEL-24676 and CPANEL-26332. CPANEL-24676 is fixed in version 80: Fixed case CPANEL-24676: API Tokens: Ensure that the listaccts API call respects the 'list-accts' priv. CPANEL-26332 was opened on March 18th, 2019 to request that the listzones WHM API 1 call returns all DNS zones on the system instead of just the zones owned by the "root" user when the 'manage-dns-records' API token privilege is enabled. Thank you. 0 -
@cPanelMichael any progress on this one by chance? Thanks =) 0 -
Having just tried to switch from using the root credential to API keys (so that password changes don't clobber our script) I have discovered that this appears to still be broken in 11.84; if you authenticate using the root password, you get all zones. If on the other hand you use an API key issued by root with "Manage DNS Zones" privilege, you only get zones owned by root. Seems particularly odd that the behaviour differs between the two. 0 -
This appears to still be broken 5 years later. Has this (CPANEL-26332) really not been fixed, cPanelMichael?
0 -
I don't see that this case was ever resolved, unfortunately. Is this still causing an issue with the API system?
0 -
cPRex its a security issue, for sure.
Having to create a God token to query one API endpoint is less than ideal.
If even the developers gave the option for tokens to be read-only, that, coupled with IP restrictions, would be worlds better than global R/W.
0 -
Alright - I've confirmed the issue is still happening and I've created CPANEL-45971 as a modern case for this issue, with some additional notes.
I will say that this thread represents the entirety of reports about this issue (as in, no other tickets or social media action about the problem) which is likely why it was a lower priority back then, so it may be a bit before this gets assigned to a team to fix.
0 -
cPRex yeah I'll presume that whoever is using the API just ascribes things away to some extent (put token in WHMCS, accounts provision, yay) but as a security minded individual who uses the API for much more complex things, it's one of those areas that I'd love to see some improvement upon.
Not just specifically to this issue, but, even the documentation, none of the methods mention what API privilege are required:
https://api.docs.cpanel.net/openapi/whm/operation/listzones/
Pretty slick docs and interface, but, no mention of token privileges and it's just assumed everyone is comfortable putting their hostname and, gulp, root credentials, into an public form to test the API, eep.Back water things I suppose, thank you for creating a new case for it, appreciate the assistance as always =)
0 -
bellwood - that's an interesting perspective for sure, and not something I'd thought of. So you're saying in a world with ideal documentation, the API calls would all list what privileges they require? I do think that most people assume "root" when they use the whmapi1 call. We even have an article that boils down to "test it as you go until it works"
0 -
Well, more so, for the list-zones (or any), if I'm generating an API token, it was not known to me I needed to pick "All Features". I'd just assumed the DNS group would suffice (list-zones is not anywhere on the "Manage API Tokens" page)
Now for that one, I opened a ticket and busied someone up to find out it had to be a "God" token, but, if the docs listed that information, it would clearer for developers so they didn't have to "test it as you go until it works" (which is a great name, btw, but an awfully frustrating process for someone trying to integrate) and perhaps internally it might spark discussion about how many API endpoints require "God" tokens and whether it warrants any change - especially if people are just having to check "All" to "get it working" (and I bet many, many do)
Happy to discuss more offline if you'd like, you know where to find me =)
0 -
Nah, we shouldn't need to have an epic discussion to get the product improved - unless you want to :D
I've created case DOC-20762 with our documentation team to see if that is something they can look into. This would be a large project for that team most likely since, as you and I have found, there isn't much out there on this, but compiling a list would be a nice thing to have for sure. If I hear anything else about this, I'll be sure to post!
0
Please sign in to leave a comment.
Comments
16 comments