Java: Add query for Sensitive Keyboard Cache

[joefarebrother]

Query that detects instances of sensitive information that could be saved into the keyboard cache.

Considers cases in which an input field declared is declared via XML with a name that indicates it may contain sensitive information, but its input type, as declared either in XML or in code, indicates that it is saved to the keyboard cache.

[github-actions]

QHelp previews:

java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp

errors/warnings:

./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:1:1: Content is not allowed in prolog.
A fatal error occurred: 1 qhelp files could not be processed.

[github-actions]

QHelp previews:

java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp

errors/warnings:

./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:32:127: element "code" not allowed here; expected the element end-tag or text
./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:33:5: element "li" not allowed here; expected the element end-tag, text or element "a", "b", "blockquote", "code", "em", "i", "img", "ol", "p", "pre", "sample", "strong", "sub", "sup", "table", "tt", "ul" or "warning"
./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:35:3: The element type "li" must be terminated by the matching end-tag "</li>".
A fatal error occurred: 1 qhelp files could not be processed.

[github-actions]

QHelp previews:

java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp

errors/warnings:

./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:32:127: element "code" not allowed here; expected the element end-tag or text
./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:33:5: element "li" not allowed here; expected the element end-tag, text or element "a", "b", "blockquote", "code", "em", "i", "img", "ol", "p", "pre", "sample", "strong", "sub", "sup", "table", "tt", "ul" or "warning"
./java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp:35:3: The element type "li" must be terminated by the matching end-tag "</li>".
A fatal error occurred: 1 qhelp files could not be processed.

[github-actions]

QHelp previews:

java/ql/src/Security/CWE/CWE-524/SensitiveKeyboardCache.qhelp

Android sensitive keyboard cache

When a user enters information in a text input field on an Android application, their input is saved to a keyboard cache which provides autocomplete suggestions and predictions. There is a risk that sensitive user data, such as passwords or banking information, may be leaked to other applications via the keyboard cache.

Recommendation

For input fields expected to accept sensitive information, use input types such as "textNoSuggestions" (or "textPassword" for a password) to ensure the input does not get stored in the keyboard cache.

Optionally, instead of declaring an input type through XML, you can set the input type in your code using TextView.setInputType().

Example

In the following example, the field labeled BAD allows the password to be saved to the keyboard cache, whereas the field labeled GOOD uses the "textPassword" input type to ensure the password is not cached.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <!-- BAD: This password field uses the `text` input type, which allows the input to be saved to the keyboard cache. -->
    <EditText
        android:id="@+id/password_bad"
        android:inputType="text"/> 

    <!-- GOOD: This password field uses the `textPassword` input type, which ensures that the input is not saved to the keyboard cache. -->
    <EditText
        android:id="@+id/password_good"
        android:inputType="textPassword"/>  
</LinearLayout>

References

• OWASP Mobile Application Security Testing Guide: Determining Whether the Keyboard Cache Is Disabled for Text Input Fields.
• Android Developers: android:inputType attribute documentation.
• Common Weakness Enumeration: CWE-524.

[atorralba]

This mostly looks good, I added some minor comments.

Other than that, have you considered that the input type could be added programmatically via setInputType? I'm curious about how many alerts raised by this query could be discarded because of this. If there are enough, it could might sense to handle it as well.

WDYT?

[atorralba]

Hey @joefarebrother thanks for working on this, I think it'll be a valuable addition. I added some more minor comments and a conceptual question, but otherwise this LGTM. If DCA and MRVA look good, we should ask for a docs review.

[sabrowning1]

👋🏼 @joefarebrother, thanks for your work on this! I've suggested a few small changes to the .qhelp file to align with our style guide. Let me know if you have any questions!

[sabrowning1]

Looks good for Docs, thanks @joefarebrother! 👍🏼

[atorralba]

🎉