T05 · Unauthorized Access and Privilege Escalation
- Location
scripts/smyx_pet_climbing_frame_heatmap_analysis.py:45- Finding
Caller-Controlled Identity Can Enable Cloud Account Impersonation
- Content
View full analysis
Vulnerability Details
File Location:
scripts/smyx_pet_climbing_frame_heatmap_analysis.py:45,55;skills/smyx_common/scripts/util.py:548-562,580-599,610-623
Vulnerability Type: Improper authentication and trust of a caller-supplied identity
Risk Level: HighRelevant Code
The command-line entry point accepts a hidden but directly callable identity parameter and uses it to initialize the current identity without authenticating ownership:
python parser.add_argument("--open-id", required=False, help=argparse.SUPPRESS)python # Initialize the internal user identity. OpenIdUtil.resolve_current_open_id(args.open_id, use_current=bool(args.open_id))The resolved identity is subsequently used as both the
openIdandmobilevalue in a silent login or registration request:python def _get_or_create_user(username): _url = ApiEnum.BASE_URL_HEALTH + "/sys/phoneLogin" open_id = username _data = { "silent": 1, "register": 1, "openId": open_id, "mobile": username, "source": ConstantEnum.DEFAULT__SKILL_HUB_NAME } try: _response = requests.post(_url, json=_data) if _response.status_code == 200: _response_json = _response.json() if _response_json and _response_json.get("success"): return _response_json and _response_json.get("result") except Exception as _e: CommonUtil.trace_exception_stack(_e) return {}Tokens returned for that asserted identity are stored and attached to subsequent API calls:
python if not ApiEnum.TOKEN or not ApiEnum.OPEN_TOKEN: new_current_user = _get_or_create_user(current__user_name) if new_current_user: ApiEnum.TOKEN = new_current_user.get("token") ApiEnum.OPEN_TOKEN = new_current_user.get("openToken") current_user_info = new_current_user.get("userInfo") ...[truncated 3715 chars]- Remediation
View remediation
Remediation Suggestions
- Remove
--open-idfrom the public command-line entry point. Hiding an argument from help output does not prevent unauthorized use. - Accept identity only from a trusted integration channel, not from ordinary CLI arguments, files, or other caller-controlled values.
- Require a signed identity assertion containing an issuer, audience, subject, expiration time, and nonce. Validate all fields before initializing the current identity.
- Change the server authentication flow so that knowledge of an
openIdor mobile identifier is never sufficient to obtain tokens. Require proof of account ownership or a pre-authenticated upstream session. - Separate registration from login and prohibit silent registration or login for arbitrary caller-selected identifiers.
- Bind cached tokens to the authenticated principal and trusted issuer. Do not reuse a token merely because a local username matches an asserted identifier.
- Reject identity changes after a process has established its authenticated principal.
- Add authorization tests proving that one caller cannot retrieve another user’s reports by supplying that user’s identifier.
- Invalidate any tokens previously issued through an identity-only silent-login flow and review stored account mappings for unauthorized associations.
- Remove
