...
1) Sensitive information in requests should never be sent using query parameters. The URLs (including the query parameters with the sensitive values) are frequently saved in many places downstream (e.g., browser cache, proxy servers, etc.) Existing APIs such as addBaremetalDhcp, addBaremetalHost, addBaremetalPxeKickStartServer, addBaremetalPxePingServer, addCiscoVnmcResource, addCluster, addExternalFirewall, addExternalLoadBalancer, addF5LoadBalancer, addHost, addImageStore, addNetscalarLoadBalancer, addNiciraNvpDevice, addPaloAltoFirewall, addS3, addSRXFirewall, addStratosphereSsp, addUcsManager, addVmwareDc, addVpnUser, createAccount, createUser, createVolumeOnFiler, login, updateCloudToUseObjectStore, updateHostPassword, updateUser, uploadCustomCertificate, uploadSslCert and such should probably require that their request parameters be sent in a HTTP POST body.
2) Responses should contain only the information requested; sensitive parameters such as passwords or keys must only be returned if they are explicitly requested and even then only for parameters which CloudStack has created. CloudStack could return its users' secret keys, for example, but there is no reason that CloudStack should return Xen host passwords, S3 secret keys, etc. The 4.x design includes the complete state of an object instance in the response for every API which manipulates the object. Examples: The removeNicFromVirtualMachine API returns the VM password in the response and , the disableUser API returns the user's secret key in the response, the addS3 API returns the S3 secret key, and so on.
3) Guards need to be put into place to prevent XSS and other malicious payloads from making it into the database
the naming of API calls and - parameters are not consistent leading to them not being as intuitive as could be to the application programmers leveraging them. This is a place holder to list such occasions so we can address them on going into 5.0. Please add to this list.
...
Current implementation of the list APIs is tied tightly with the default roles (root admin,domainadmin, regular user), and we have hard-coded logic baked in to handle these three out-of-box roles differently.The List APIs do not interpret the listing parameters in a standard way across board. Depending on which role is invoking the call, the logic assumes some default behavior in the given context and provides results by ignoring the passed listing parameter. Most contradictory parameters are these four: listall, isrecursive, domainid, account. Here is a summary of current API behavior in handling these four APIs;
Category | listAll | isRecursive | Result |
Both domainId and account are provided | IGNORED | IGNORED | Only list resources owned by the given account, even though the specified account is a root admin or domain admin. Basically listAll and isRecursive flags are totally ignored. |
Neither domainId nor account is provided (caller = NORMAL USER) | IGNORED | IGNORED | Only list resources owned by the caller. Basically listAll and isRecursive flags are totally ignored. |
Neither domainId nor account is provided (caller = ROOT ADMIN) | TRUE | IGNORED | Always list all the authorized resources for the root admin, isRecursive flag is ignored. |
| FALSE | IGNORED | Only list resources owned by the root admin |
Neither domainid nor account is provided (caller = DOMAIN ADMIN) | TRUE | IGNORED | Always list all the authorized resource along the domain tree, ignore passed isRecursive flag and internally set it to always TRUE. |
| FALSE | IGNORED | Only list resources owned by the domain admin. isRecursive flag is not taking effect |
Only domainId is provided (caller = NORMAL USER) | IGNORED | IGNORED | Only list resources owned by the caller. |
Only domainId is provided (caller = ROOT/DOMAIN ADMIN) | IGNORED | TRUE | List the authorized resources along the domain tree. |
| IGNORED | FALSE | List the authorized resources only for the given domain. |
There are several issues with current behavior:
...