Could a stranger read a rescue request? Ten high-severity findings in an SOS app, retested
For product owners and CTOs releasing safety-critical mobile apps.
A crisis-response mobile app, with Android and iOS clients and a Bluetooth and Wi-Fi mesh layer, came back for retest after ten high-severity findings in its first beta.
- Public safety
- SOS mobile app on Android and iOS
- Compliance
- Reputation
- Clients
- Money
What was at risk
A stranger could receive location and a medical record
A person near a phone that had triggered an SOS could receive the owner's GPS position and medical record. Context: medical data is special-category data under GDPR.
An anonymous session treated as a rescuer
An anonymous session was given a key, and the app then treated that session as a rescuer: a stranger with the access of someone who is there to help.
Fixes that quietly break availability
Two of the four new issues the fixes introduced were medium and about availability. In an SOS app, availability is the function, so a fix that costs it is a new defect.
A retest summed up as ten fixed when two were not
One finding was only partly fixed, and one was fixed on the client with the server side unverified from code. A reader needs those two named, not folded into ten.
Standards and rules in play
- Evidence labels on every statementVerified means traced end to end. Inferred means one step is reasoned. The reader can see which statements rest on which.
- Fail closed, no way backA beta-2 client without the new key, lease, binding or cohort refuses the traffic and does not drop back to beta-1 behaviour. We hunted for legacy fallbacks and for flags that default a fix off.
Context: apps that hold health and location data are expected to meet GDPR security duties.
How we tested it
- Test level
- Static review of the second beta's source code, finding by finding.
- Test types
- Security testing, white-box, and confirmation testing of ten earlier findings.
- Test basis
- The ten high findings of the first beta, all confirmed real, each re-traced as an attack.
- How we workedCode reviewWhere it showed upFor each finding we re-traced the original attack through the beta-2 code, and looked for legacy fallbacks.
- How we workedGrading each findingWhere it showed upEach finding graded fixed, partly fixed or cannot verify: 8 fixed, 1 partly fixed, and 1 fixed on the client where the matching server behaviour cannot be verified from code.
Terms as in the ISTQB CTFL 4.0.1 syllabus and glossary.
What we found, and what it costs
- FindingHighA person near an SOS phone could receive the owner's GPS position and medical recordWhat it costs youThe location and health data of someone in an emergency, readable by a stranger.
- FindingHighAn anonymous session was given a key and then treated as a rescuerWhat it costs youA stranger in the rescuer role, with the access that goes with it.
- FindingOpenOne finding partly fixed, and one fixed on the client with server behaviour that cannot be verified from codeWhat it costs youThese have to be carried as open, not as closed.
- FindingNewFour new issues from the fixes: two medium (availability), one low, one informationalWhat it costs youA fix that adds an outage is still a cost. They are in the report beside the originals.
Eight of the ten were fixed, two of them with a low residual risk. None of our original findings turned out to be wrong.
What changed
Retest results graded finding by finding, with new issues and limits stated. A client without the new key fails closed, and every statement carries a verified or inferred label.
Releasing something people depend on in an emergency?
We retest each finding as an attack and label what we verified. The first month is a trial.
