Could you please indicate whether patches (or security upgrades) are planned for this purpose or whether they will be implemented in the near future. What are your recommandations in terms of security?
in a few words to introduce myself :
I work for a publisher in the telecom sector.
We are located in france, vietnam, slovakia and slovakia.
We use the ODK solution to track information.
web application firm suggesting ODK collect for visit report collection to one of our clients
In terms of your bullet points:
weak hashing algorithms (MD5) : "it can be vulnerable to collisions and other security weaknesses, and should not be used", feedback from our client security team
for tapjacking : client feedback is "When user touches the screen, application may pass the touch event to another application below its user interface layer that the user does not see, serving like a proxy to pass unintended touch activities. This attack is quite similar to clickjacking but for mobile devices." and they advise us to use android:filterTouchesWhenObscured="true"
they also alert us on temporary file creation and want to make sure it is deleted when they are no more required.
and last one is linked to raw SQL queries, "Inclusion of input into raw SQL queries can potentially lead to a local SQL injection vulnerability in the mobile application"
it is very precise feedback and we would likely get your expertise on these topics.
What particular us of MD5 is the team concerned about?
Seems like a valid concern. Would need some research but I could see this being added as long is it doesn't effect any existing features in the app.
Not quite clear on what this refers to. Would be great to have examples.
Makes sense as general advisory. Did the security team find any ways to inject SQL and cause problems?
I think as a general point here if you're having teams do security analysis on ODK tools it would be really helpful to share their reports and even better have them involved in discussion on this forum. That way there can be an understanding of what attacks the team is concerned about and there can be a community discussion around if that's something the app might be able to mitigate. I'd argue it's pretty much impossible for any team to guaruntee their codebase is immune to particular classes of attack but it's very possible for them to work with security teams to get to a place where everyone is confident that enough is in place that the app is "good enough" for a use case.
Bear in mind that Collect is a free, open source and available as-is/without warranty. As far as I've seen there isn't any form of ongoing security analysis or pen testing on the code base so could always use contributions from security people
The concern is about using MD5 for cryptography purposes. Our team is currently checking some places in Collect app where MD5 is used, and assess that it is not used for cryptography.
In RFC 6151, the IETF suggestion is :
Where the MD5 checksum is used inline with the protocol
solely to protect against errors, an MD5 checksum is still an
acceptable use. Applications and protocols need to clearly state in
their security considerations what security services, if any, are
expected from the MD5 checksum. In fact, any application and
protocol that employs MD5 for any purpose needs to clearly state the
expected security services from their use of MD5.
We've also found an article that explores security and privacy attitudes, practices, and needs within organizations that use Open Data Kit (ODK) :
Cobb, Camille et al. 2016. “Computer Security for Data Collection Technologies.” In Proceedings of the Eighth International Conference on Information and Communication Technologies and Development - ICTD ’16, Ann Arbor, MI, USA: ACM Press, 1–11. http://dl.acm.org/citation.cfm?doid=2909609.2909660 (April 9, 2020).
Need more support?ODK Cloud, the official hosting service from the creators of ODK, comes with priority support. Get started today.