Można było podglądać cudze recepty z Medicover – na szczęście bez danych pacjentów

Nowy rok zaczynamy błędem znanym od lat, który najwyraźniej nigdzie się nie wybiera. Tym razem modyfikacja parametru zapytania do serwisu WWW powodowała ujawnienie danych medycznych. Na całe szczęście nie było w nich danych pacjentów.

Otrzymaliśmy dzisiaj informację od czytelnika o błędzie w aplikacji Medicover Online. Medicover to jeden z największych w Polsce podmiotów świadczących usługi prywatnej opieki medycznej, a z jego portalu obsługi korzystają codziennie tysiące klientów. Problem wyglądał zatem poważnie.

A co jeśli zmienimy cyferki na końcu adresu?

To klasyczne pytanie zadaje sobie codziennie wiele osób, używających różnych systemów. Tym razem trafiło na Kamila, który sprawdził, co się stanie, jeśli zmieni parametr w zapytaniu wyświetlającym mu szczegóły e-recepty wystawionej przez lekarza Medicoveru. Zapytanie wyglądało tak:

https://mol.medicover.pl/api/EPrescription/Drugs/GetDrugDetails?id=5989xxxx

Jak się możecie domyślać, artykuł czytacie, ponieważ po zmianie ostatniej cyfry na inną w przeglądarce pojawiły się dane innej, cudzej recepty (błąd występował tylko dla zalogowanej sesji, ale wyświetlić można było dane dla cudzych recept). Co zatem można było zobaczyć? Odpowiedź serwera wyglądała tak (po sformatowaniu dla czytelności i lekkiej anonimizacji):

{
„success”: true,
”element”: {
„drugTradeName”: ”Saccharomycesboulardii”,
”endOfDrugTreatment”: ”2020-12-28T12: 21: 29Z”,
”recommandation”: null,
”isDoctorDrug”: false,
”prescribingDoctors”: [
{
„locations”: [
{
„clinicId”: 27274,
”clinicName”: ”Bielsko-BiałaCMKarpacka”,
”clinicPharmaName”: ”BielskoBiałaCMKarpacka”,
”scheduleDate”: ”2021-01-04T00: 00: 00Z”
}
],
”doctorId”: 149684,
”doctorName”: ”XxxxJustyna”
},
”eaN13Code”: 5909990887491,
”appointmentId”: 28287xxxx,
”unavailableReason”: null,
”isAvailable”: true,
”dosage”: ”2x1”,
”packName”: ”20szt.”,
”drugDose”: ”250mg”,
”drugName”: ”Enterol”,
”drugId”: 1107209,
”doctorName”: ”XxxxxJustyna”,
”doctorId”: 149684,
”prescriptionDate”: ”2020-12-21T12: 21: 29.863Z”,
”prescribedDrugId”: 5989xxxx,
”drugFormName”: ”kaps.”,
”ePrescriptionDocumentIds”: [
60642589
],
”ePrescriptionPackageId”: 0
},
”message”: null
}

Tu przykład takiego komunikatu w przeglądarce:

Mogliśmy zatem poznać imię i nazwisko lekarza, który przepisał dany lek, nazwę leku i informacje o dawkowaniu.

Czy to poważny błąd?

Na pewno dużą ulgą dla pacjentów jest informacja, że w odpowiedzi serwera nie było danych osoby, która receptę otrzymała – wtedy waga incydentu byłaby o rząd lub dwa rzędy wielkości większa. Same informacje o przepisywanych lekach mają większe znaczenie z punktu widzenia samego Medicoveru – zebranie statystyk, jakie leki który lekarz przepisuje, mogło być ciekawym badaniem i mieć znaczenie dla osób pracujących w branży.

Warto jednak zauważyć, że powyższe zapytanie do API umożliwiało pobranie danych nieprzypisanych do naszego konta – można się więc zastanowić, jakie jeszcze zapytania nie były weryfikowane po stronie serwera. Ciekawą wskazówką od Kamila jest informacja, że błąd dotyczył nowej, niedawno wprowadzonej funkcji. Demonstruje to wagę, jaką należy w takich przypadkach przykładać do audytu aplikacji i jej kodu źródłowego, szczególnie w tak wrażliwych środowiskach jak medyczne.

Reakcja Medicoveru

Tu musimy pochwalić firmę, ponieważ czas usunięcia problemu lokuje ją w top3 w historii naszych zgłoszeń podobnych błędów. Informację od czytelnika otrzymaliśmy o 13:20. O 15:30 skontaktowaliśmy się z odpowiednią osobą po stronie Medicoveru (osobiste relacje się przydają) i 10 minut później przekazaliśmy opis błędu. O 17:10 usługa była już wyłączona. Wzorowy czas reakcji.

Powyższy incydent dołącza do długiej listy wpadek w branży medycznej w Polsce – by przypomnieć tylko możliwość czytania czatów z lekarzami Luxmedu czy szpital w Kole, który udostępniał całemu światu wszystkie dane pacjentów. Niestety wraz z postępującą cyfryzacją służby zdrowia możemy się spodziewać kolejnych podobnych incydentów.