T09 · Insecure Skill Coding Practices
- Location
scripts/search-doctors.js:105- Finding
Unauthenticated OceanBus Responses Permit Forged Medical Search Results
- Content
View full analysis
{ if (resolved) return; try { const result = JSON.parse(msg.content); // Response can arrive from a different OpenID than what YP returned if (result.results !== undefined || result.error) { resolved = true; formatOutput(result, opts); await ob.destroy(); return; } ``` A structurally similar issue exists in the list operation at `scripts/search-doctors.js:157-165`, where messages are accepted based only on the presence of a `depts` or `cities` property. ### Technical Analysis The listener accepts the first incoming JSON message containing `results` or `error`. It does not: - Verify that the message sender is the selected DoctorDataSvc. - Verify a cryptographic signature associated with an approved service identity. - Include or validate a random request identifier. - Associate the response with the specific request that was sent. The source comment explicitly permits responses from an OpenID different from the discovered service. Consequently, JSON shape is treated as sufficient proof that a message is an authentic medical-data response. An attacker capable of sending a message to the generated OceanBus identity can race the legitimate service and supply a forged response such as: ```json { "total": 1, "results": [ { "name": "Attacker-Controlled Entry", "title": "Director", "dept": "Cardiology", "hospital": "Attacker-Controlled Clinic", "skill_short": "Attacker-controlled medical claim", "fee_low": 5000, "fee_high": 5000 } ] } ``` Because the Skill instructions require the Agent to reproduce script results without changing the doctor, hospital, or fee data, forged data may be presented directly ...[truncated 1396 chars]- Remediation
View remediation
