Closed sushi2k closed 7 years ago
I think your comments referring to the Android version of this test case:
I agree that the recommendations need to be improved.
AFAIK, it is possible to use byte arrays, the content of which can be referenced directly. However, I'm not sure if this is consistently safe for all Android runtimes.
The points about mutable objects & speeding up garbage collection should be added as well.
There should also be a recommendation to implement critical operations natively if it can't be done safely in Java.
@pmilosev can you help to improve this chapter?
@b-mueller Yes, I referred to Android. You can assign the ticket to me.
Please feel free to correct me on anything you see as potentially unsafe or something.
@pmilsoev As this is the iOS ticket, I just assigned you this ticket: https://github.com/OWASP/owasp-mstg/issues/478
This one is linked to memory testing of Android. Please create a PR with your changes. Thanks for your help.
Sure, just note that it will take me few weeks before I implement this. As commented already on another ticket, I'll be going trough the existing content by end of next week, before start adding any new content. I already have a ticket for proof reading one chapter - this will be done in the next several days.
What needs to be done regarding this issue ? I can already see a section named "Testing for Sensitive Data in Memory" under "Testing Data Storage".
However I don't completely agree with the Remediation statement. While immutable objects can not be overwritten consistently, one can use mutable objects to overwrite their content when no longer needed. For user input (e.g. password fields) one can implement a custom keyboard that never exposes the entered value in plain text in memory (assuming the API to which the field should be passed doesn't require the field to be plain text). Therefore I would change the statement to also mention the possibility of using mutable objects and / or custom components.
p.s. Some testing from couple of years ago showed that asking the system to do garbage collection with
System.gc()
significantly reduced the time data was in memory after being dereferenced. (e.g. from 10min to 2min or so).