Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update: Mobile Application Security Cheat Sheet #1524

Open
richeeta opened this issue Oct 30, 2024 · 1 comment · May be fixed by #1531
Open

Update: Mobile Application Security Cheat Sheet #1524

richeeta opened this issue Oct 30, 2024 · 1 comment · May be fixed by #1531
Labels
ACK_OBTAINED Issue acknowledged from core team so work can be done to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet.

Comments

@richeeta
Copy link

What is missing or needs to be updated?

The current Mobile Application Security Cheat Sheet lacks specific guidance on securing app functionality that could be accessed when an iOS/iPadOS device is locked. I believe this cheat sheet could be enhanced by adding specific guidance for iOS/iPadOS for Shortcuts, Siri, deep links, and WidgetKit data.

How should this be resolved?

To address these gaps, I would respectfully suggest that the following sections be added:

  1. Shortcuts Permissions
    iOS Shortcuts allow for automation of app functions, which may enable sensitive actions even when the device is locked. Sensitive app functionalities triggered via Shortcuts should always require device unlock before execution.
    Solution: Store secure tokens in Keychain that the app validates before executing sensitive shortcuts. Implement checks with UIApplication.shared.isProtectedDataAvailable to restrict execution of sensitive actions when the device is locked.
  1. Siri Permissions
    Siri can access app functionalities through voice commands, which may be accessible even when the device is locked, potentially enabling unauthorized actions.
    Solution: Configure requiresUserAuthentication to true on intents that expose sensitive information or functionality. Additionally, set INIntent.userConfirmationRequired = true for operations requiring explicit user confirmation. These settings ensure proper authentication (e.g., Face ID or PIN) and explicit approval before Siri can execute sensitive commands.
  1. Deep Link Security
    Deep links offer direct access to specific app screens, which could potentially bypass authentication if not secured, allowing unauthorized users access to secure sections of the app.
    Solution: Implement authentication checks on any view controllers or endpoints accessed via deep links. Configure and validate Universal Links using apple-app-site-association files for secure deep linking. Sanitize and validate all parameters received through deep links to prevent injection attacks. Ensure unauthorized users are redirected to the login screen, preventing direct access to sensitive parts of the app without proper authentication.
  1. WidgetKit Security
    Widgets on the lock screen may display sensitive data, potentially exposing it without the device being unlocked.
    Solution: For iOS 17+, use WidgetInfo.isLocked to detect lock screen state. For earlier iOS versions, implement custom logic based on available widget states since widgetFamily alone doesn't directly provide lock screen information. Apply conditional logic to mask or restrict sensitive widget content when appropriate security conditions aren't met.

Additional Security Considerations:

  1. Configure appropriate background refresh policies to prevent sensitive data updates while device is locked
  2. Implement proper privacy-related configurations in Info.plist for features requiring user permissions
  3. Use App Groups with appropriate security configurations when sharing data between app and widgets

Thank you!

@richeeta richeeta added ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet. labels Oct 30, 2024
@szh
Copy link
Collaborator

szh commented Oct 30, 2024

I think this is a great idea. Want to submit a PR?

@szh szh added ACK_OBTAINED Issue acknowledged from core team so work can be done to fix it. and removed ACK_WAITING Issue waiting acknowledgement from core team before to start the work to fix it. labels Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACK_OBTAINED Issue acknowledged from core team so work can be done to fix it. HELP_WANTED Issue for which help is wanted to do the job. UPDATE_CS Issue about the update/refactoring of a existing cheat sheet.
Projects
None yet
2 participants