Port MASTG-TEST-0055 (by @guardsquare) #3054
Conversation
|
We still need to find an appropriate MASWE for this test |
Co-authored-by: Jeroen Beckers <[email protected]>
| - [`UITextAutocorrectionTypeNo`](https://developer.apple.com/documentation/uikit/uitextautocorrectiontype/uitextautocorrectiontypeno) | ||
| - [`secureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/1624427-securetextentry) | ||
|
|
||
| If the app uses Storyboards or XIB files, check whether the UI elements such as `UITextFields`, `UITextViews`, and `UISearchBars` use the `UITextAutocorrectionTypeNo` attribute. |
There was a problem hiding this comment.
can this really be tested by just having the IPA?
There was a problem hiding this comment.
There is no easy way to get it from a built IPA file. I am afraid we can only review the source code, or use dynamic analysis to hook an init function of TextField? Do you want me to create a dynamic test for it?
| The following attributes, if present, will prevent the caching mechanism for text inputs: | ||
|
|
||
| - [`UITextAutocorrectionTypeNo`](https://developer.apple.com/documentation/uikit/uitextautocorrectiontype/uitextautocorrectiontypeno) | ||
| - [`secureTextEntry`](https://developer.apple.com/documentation/uikit/uitextinputtraits/1624427-securetextentry) |
There was a problem hiding this comment.
should we require both? We need to explain this better, either here or in the evaluation using some examples maybe.
There was a problem hiding this comment.
I clarified it in the last commit, please have a look
|
|
||
| 1. Reset your iOS device keyboard cache by navigating to `Settings > General > Reset > Reset Keyboard Dictionary`. | ||
| 2. Exercise the application and identify the functionalities that allow users to enter sensitive data. | ||
| 3. Use @MASTG-TECH-0052 to retrieve the keyboard cache file with the extension `.dat` at `/private/var/mobile/Library/Keyboard/` and its subdirectories. |
There was a problem hiding this comment.
was this working? which iOS version was it?
There was a problem hiding this comment.
Yes, it worked on iOS 15.4.1 iPhone XS. The file is /private/var/mobile/Library/Keyboard/en-dynamic.lm.
It's not very consistent though. I can't find there all suggestions that my keyboard cached(yes I restarted my device).
|
|
||
| This test checks whether the keyboard cache contains sensitive data from the target app. | ||
|
|
||
| ## Steps |
There was a problem hiding this comment.
is this test really useful/meaningful/valuable?
There was a problem hiding this comment.
After thinking it over again, I am not sure about value of these tests:
- Inspecting
/private/var/mobile/Library/Keyboard/en-dynamic.lmisn't consistent. Typing a password with autocorrection doesn't consistently put it to the database. Therefore, it's even difficult to get a True Positive. - Static search for
UITextAutocorrectionTypeNoandsecureTextEntryis also difficult if an app uses Storyboard. It'd be easier in SwiftUI but this is not a big percentage of apps yet. Even if it was possible for all apps, I am not sure if testing of usage of these APIs would be practical and sufficient.
In general, it's difficult to test for this weakness statically because we don't know what data is sensitive and where it's typed. Therefore, I suggest we:
- Remove the test for testing
/private/var/mobile/Library/Keyboard - Remove the static search for
UITextAutocorrectionTypeNoandsecureTextEntry - Create a dynamic test with Frida that intercepts text from all inputs that don't have
UITextAutocorrectionTypeNoorsecureTextEntry, and let the user review this list afterwards.
This PR closes #2934