Experimenting with the SOAP API's CreateLogin method, I noticed something peculiar. It seems that you can enter any customer ID, in which case it will create a new login for that customer (regardless of who is currently logged in), and it changes the current session to be authenticated for that other customer. So in a roundabout way, I can log in as any customer. All I need is their customer ID, a login type for which they have no login, and my own preexisting login.
I'm trying to see how you would use this method in a way that would allow a customer currently logged into specify another customer_no to create a login. What would be the use case where you would expose that parameter to the public? There are many API methods where a web developer has to consider the security implications when using.
Thanks.
Indeed, developers must be cautious about exposing certain SOAP API calls. Similarly to PHP, it invites less-aware coders to expose vulnerabilities. I can imagine scenarios where this "gotcha" with CreateLogin could be abused. For example, some people might be caching the current customer_no value in a cookie. Or their site could be a SPA which calls into a proxy API, where the call could be intercepted and changed. It's a small risk, but it strikes me as something worth being aware of.
Perhaps I'm mistaken, but the design of CreateLogin suggests that this is not an intended use. The session must be authenticated, and yet the method can affect any constituent. To compound this potential problem, the documentation is inaccurate for the method.