[security defect] Personal information disclosure due to no authentication and authorisation

Subject of the issue

Although disclosure of sensitive information has been highlighted in several PRs #835, #836, #837, and in https://github.com/IEEEKeralaSection/rescuekerala/issues/836#issuecomment-414864199 any registered requestor’s personal information is still available without any authentication and authorisation. Therefore, I am opening this PR to address this security defect for your immediate attention and urgent remediation.

The requestors (requestee) originally were flood victims themselves and their immediate family or friends or concerned asking to be rescued. Now the requestors include relief camp leads, local authorities, volunteers and displaced people. We need to protect any sensitive personal information that they would provide, this include telephone number, personal address, and medical information in some cases.

https://github.com/IEEEKeralaSection/rescuekerala/issues/836#issuecomment-414864199

Steps to reproduce defect

Goto “Registered Requests” page https://keralarescue.in/requests/?district= and you can view and retrieve personal information of requestors without any authentication (e.g. contact telephone number).

Expected behaviour

It is expected that personal information is adequately protected and is not made available without any adequate authentication and authorisation. A potential impact is unsolicited contact including calls to rescue and relief requestors including flood victims.

Remediation is to implement adequate authentication and authorisation to protect access to all rescue and relief records as soon as possible. You can start with redacting personal information in all those requests records that are displayed in the webpage. Majority of rescue calls has been actioned, and several of those calls has been closed as well.

It is understood that for many cases authorities and volunteers would need contact details of the requestor (rescue and relief calls).

Until adequate authentication and authorisation is in place for keralarescue.in portal, a stopgap solution is to add a contact/messaging functionality (e.g. “contact” or “call me” or “get phone number” button or link) instead of displaying requestor’s phone number. When an authority or volunteer wants to contact the requestor they click on contact or call me or get phone number button or link, and then their telephone number is to be collected. Following this an SMS should be send to the requestor with a callback message, or send an SMS to volunteer/authority with requestor’s phone number (when its a landline number). In the former case, requestor can contact volunteer/authority directly. In the latter volunteer/authority can contact requestor. The SMS should contain easy to follow instructions. Here some backend work on SMS integration is also needed, sms functionality is already in place `mainapp/sms_handler.py’

It is also recommended to get all necessary consent, and log all record access for any audit trails in the future.

[biswaz]

https://github.com/IEEEKeralaSection/rescuekerala/commit/26cd1804fc82e8d870367d35cdfbac4e0fdd072f

Removed /data. @camaheshv I agree with you Hides phone numbers for requests older than 2 days @securitydaemon

[camaheshv]

@naveenpf still data is available in bulk at https://keralarescue.in/data/ and also district wise data available in bulk. Now, is it not the time to restrict bulk data availability ?