Once a user is logged in, is including their username or userID routine API responses considered bad practice? I don't see why it should be, if everything you can do with that username requires an active login token.
The fact that you could put in an email address in lieu of a username/userID seems irrelevant; lots of systems allow email addresses as a username. What stands out about this to me is:
We see in both requests the same `uxd_id` field. This looks to be a temporary login key or validation key generated by the server, that the client would probably use to validate further requests or validate a password change request from that username. It's different in the email than in the live server response so they are generated in different sessions. So...
1) The email reset has two calls. What does the author mean that the first call validates the user's auth? If this is a "forgot password" link for a user who's not logged in, there should be no existing auth (unless that old uxdID functions as a permanent password, but even then, it should be specific to the user). That link should go to a page that issues a new email with a temporary validation token that's tied to the specific user and then emailed back to that user's email address. Unless you could intercept the named user's email there should be no way to know the new token and reset the password.
2) If, on the other hand, it was a reset pass call with the user already logged in, why is the server not checking that uxd_id matches the active login session which also matches the user whose password is to be changed? What's the point of the uxd_id field in the PUT call if not to check that calling user == authorized user == user whose password should be changed? Who would write something like that? For that reason, this looks more like a backdoor for testing password resets that was unintentionally left open.
Am I misunderstanding something about the way this thing is taking tokens to change passwords...? Or is what's described really as simple as "system doesn't check if uxd_id matches user's email on an active session"?
Yes, it's as simple as the back end not validating that the user id and email address in the requests are tied to the active session. It's a very common mistake, often happens when devs try to roll their own session management/access control functionality
You can't trust the client. You need to validate everything on the server in the context of the authenticated session. At that point, it doesn't really make sense for the client to be submitting data that will have to be looked up and verifed anyway.
If the client has a session, the client is passing the session hash on each and every call. You have to accept it and check it. Whether it's in a session cookie or manually as a GET param. The server doesn't "know" what session it's receiving a call from; it uses the session cookie sent by the client to check it.
Meaning, those $_SESSION variables in PHP are stored on the server, but the server only knows which session to access based on a key passed with every call from the client. A hacker copying someone's php session id would "trick" PHP into using the target's server side variables.
If you're coming from a reset password email and the user has no active session, a token has to be sent via GET and checked, which means you have to look it up and verify it.
The fact that you could put in an email address in lieu of a username/userID seems irrelevant; lots of systems allow email addresses as a username. What stands out about this to me is: We see in both requests the same `uxd_id` field. This looks to be a temporary login key or validation key generated by the server, that the client would probably use to validate further requests or validate a password change request from that username. It's different in the email than in the live server response so they are generated in different sessions. So...
1) The email reset has two calls. What does the author mean that the first call validates the user's auth? If this is a "forgot password" link for a user who's not logged in, there should be no existing auth (unless that old uxdID functions as a permanent password, but even then, it should be specific to the user). That link should go to a page that issues a new email with a temporary validation token that's tied to the specific user and then emailed back to that user's email address. Unless you could intercept the named user's email there should be no way to know the new token and reset the password.
2) If, on the other hand, it was a reset pass call with the user already logged in, why is the server not checking that uxd_id matches the active login session which also matches the user whose password is to be changed? What's the point of the uxd_id field in the PUT call if not to check that calling user == authorized user == user whose password should be changed? Who would write something like that? For that reason, this looks more like a backdoor for testing password resets that was unintentionally left open.
Am I misunderstanding something about the way this thing is taking tokens to change passwords...? Or is what's described really as simple as "system doesn't check if uxd_id matches user's email on an active session"?