starred/itsyhome-macos

Fork 0

mirror of https://github.com/nickustinov/itsyhome-macos.git synced 2026-04-26 04:15:56 +03:00

[GH-ISSUE #65] Security issues #66

New issue

Closed

opened 2026-03-03 16:43:18 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 16:43:18 +03:00

Owner

Originally created by @alaschgari on GitHub (Feb 21, 2026).
Original GitHub issue: https://github.com/nickustinov/itsyhome-macos/issues/65

First and foremost: thank you for creating this.
I ran an Opus 4.6 security check and it found these issues. You might want to fix them for the upcoming versions:

Security Risk Analysis — itsyhome-macos

Summary

The codebase is generally well-structured from a security standpoint — no hardcoded secrets, proper Keychain usage, app sandboxing enabled, and zero third-party dependencies. However, there are several notable risk areas, primarily around the webhook server and network configuration.

🔴 High Severity

1. Webhook Server Has No Authentication

File: WebhookServer.swift

The built-in HTTP server accepts any incoming connection on the configured port without requiring authentication. Anyone on the same network can:

Control devices — toggle lights, unlock doors, open garage doors
Query device state — list all rooms, devices, and their status
Stream events — subscribe to real-time device state changes via SSE

# Anyone on the network can unlock your door:
curl http://<your-ip>:8423/unlock/Front%20Door

Caution

This is the most significant risk. An attacker on the same Wi-Fi network could control smart home devices, including locks and garage doors, without any credentials.

2. Wildcard CORS Header (`Access-Control-Allow-Origin: *`)

File: WebhookServer.swift#L261

The webhook server sends Access-Control-Allow-Origin: * on every response. This means any website the user visits could make cross-origin requests to the local webhook server to control devices.

Access-Control-Allow-Origin: *

Warning

A malicious webpage could silently send requests to http://localhost:8423/unlock/Front%20Door from the user's browser if the webhook server is running.

🟡 Medium Severity

3. App Transport Security Disabled (`NSAllowsArbitraryLoads`)

File: Info.plist#L73-L77

ATS is completely disabled, allowing all plaintext HTTP connections.

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

Mitigating factor: This is likely intentional — Home Assistant instances on local networks commonly run over http://. The HAURLValidator.swift auto-selects http:// for local addresses and https:// for remote ones. However, a narrower exception (e.g., NSAllowsLocalNetworking) would be safer.

4. URL Scheme Can Be Triggered By Any Local App

File: URLSchemeHandler.swift

Any application on the Mac can open itsyhome:// URLs to control devices:

open "itsyhome://unlock/Front%20Door"

Mitigating factor: This is a documented feature (deeplinks). However, there's no confirmation dialog or origin check — a malicious app or script running on the Mac could silently control devices.

5. Logging Exposes Device Names & Server URLs

Multiple files log device names, server URLs, and entity IDs with privacy: .public:

File	What's Logged
HAAuthManager.swift#L74	Server hostname
HomeAssistantClient.swift#L134	Full server URL
HomeKitManager+DataFetching.swift#L42	Home name
HomeKitManager+Doorbell.swift#L59	Accessory names

These are visible in Console.app and log stream to any user on the Mac.

🟢 Low Severity / Positive Findings

6. ✅ Credentials Stored in Keychain (Properly)

File: HAAuthManager.swift

The Home Assistant access token is stored in the macOS Keychain with kSecAttrAccessibleAfterFirstUnlock. The server URL is stored in UserDefaults (acceptable — it's not a secret).

7. ✅ No Hardcoded Secrets or API Keys

Scanned the entire codebase — no hardcoded tokens, passwords, API keys, or secrets were found.

8. ✅ App Sandbox Enabled

File: Itsyhome.entitlements

The app runs in a sandbox with only the entitlements it needs:

com.apple.developer.homekit
com.apple.security.network.client + network.server
com.apple.developer.ubiquity-kvstore-identifier (iCloud KV store)

9. ✅ Zero Third-Party Dependencies

No SPM packages, CocoaPods, or Carthage dependencies. The entire app is built with Apple frameworks only, eliminating supply chain risk.

10. ✅ URL Scheme Validation Is Properly Whitelisted

The URL validator only accepts http, https, ws, and wss schemes, and the URL scheme handler only accepts a fixed set of actions (toggle, on, off, lock, unlock, etc.).

11. ✅ Process() Usage Is Safe

Process() is only used to call /usr/bin/open with the app's own bundle path for restart — no user-controlled input reaches this call.

Risk Matrix

#	Finding	Severity	Exploitable?
1	No auth on webhook server	🔴 High	Yes — same network
2	Wildcard CORS	🔴 High	Yes — any webpage
3	ATS disabled globally	🟡 Medium	MITM on local traffic
4	URL scheme no confirmation	🟡 Medium	Any local app
5	Public logging of device data	🟡 Medium	Local user access

Originally created by @alaschgari on GitHub (Feb 21, 2026). Original GitHub issue: https://github.com/nickustinov/itsyhome-macos/issues/65 **First and foremost: thank you for creating this. I ran an Opus 4.6 security check and it found these issues. You might want to fix them for the upcoming versions:** # Security Risk Analysis — itsyhome-macos ## Summary The codebase is **generally well-structured** from a security standpoint — no hardcoded secrets, proper Keychain usage, app sandboxing enabled, and zero third-party dependencies. However, there are several **notable risk areas**, primarily around the webhook server and network configuration. --- ## 🔴 High Severity ### 1. Webhook Server Has No Authentication **File:** [WebhookServer.swift](file:///Users/alaschgari/test/itsyhome-macos/macOSBridge/Webhook/WebhookServer.swift) The built-in HTTP server accepts **any incoming connection** on the configured port without requiring authentication. Anyone on the same network can: - **Control devices** — toggle lights, unlock doors, open garage doors - **Query device state** — list all rooms, devices, and their status - **Stream events** — subscribe to real-time device state changes via SSE ```bash # Anyone on the network can unlock your door: curl http://<your-ip>:8423/unlock/Front%20Door ``` > [!CAUTION] > This is the most significant risk. An attacker on the same Wi-Fi network could control smart home devices, including **locks and garage doors**, without any credentials. ### 2. Wildcard CORS Header (`Access-Control-Allow-Origin: *`) **File:** [WebhookServer.swift#L261](file:///Users/alaschgari/test/itsyhome-macos/macOSBridge/Webhook/WebhookServer.swift#L261) The webhook server sends `Access-Control-Allow-Origin: *` on every response. This means any website the user visits could make cross-origin requests to the local webhook server to control devices. ``` Access-Control-Allow-Origin: * ``` > [!WARNING] > A malicious webpage could silently send requests to `http://localhost:8423/unlock/Front%20Door` from the user's browser if the webhook server is running. --- ## 🟡 Medium Severity ### 3. App Transport Security Disabled (`NSAllowsArbitraryLoads`) **File:** [Info.plist#L73-L77](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/Info.plist#L73-L77) ATS is completely disabled, allowing all plaintext HTTP connections. ```xml <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict> ``` **Mitigating factor:** This is likely intentional — Home Assistant instances on local networks commonly run over `http://`. The [HAURLValidator.swift](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/HomeAssistant/HAURLValidator.swift) auto-selects `http://` for local addresses and `https://` for remote ones. However, a narrower exception (e.g., `NSAllowsLocalNetworking`) would be safer. ### 4. URL Scheme Can Be Triggered By Any Local App **File:** [URLSchemeHandler.swift](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/Shared/URLSchemeHandler.swift) Any application on the Mac can open `itsyhome://` URLs to control devices: ```bash open "itsyhome://unlock/Front%20Door" ``` **Mitigating factor:** This is a documented feature (deeplinks). However, there's no confirmation dialog or origin check — a malicious app or script running on the Mac could silently control devices. ### 5. Logging Exposes Device Names & Server URLs Multiple files log device names, server URLs, and entity IDs with `privacy: .public`: | File | What's Logged | |------|---------------| | [HAAuthManager.swift#L74](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/HomeAssistant/HAAuthManager.swift#L74) | Server hostname | | [HomeAssistantClient.swift#L134](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/HomeAssistant/HomeAssistantClient.swift#L134) | Full server URL | | [HomeKitManager+DataFetching.swift#L42](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/iOS/HomeKitManager+DataFetching.swift#L42) | Home name | | [HomeKitManager+Doorbell.swift#L59](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/iOS/HomeKitManager+Doorbell.swift#L59) | Accessory names | These are visible in Console.app and `log stream` to any user on the Mac. --- ## 🟢 Low Severity / Positive Findings ### 6. ✅ Credentials Stored in Keychain (Properly) **File:** [HAAuthManager.swift](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/HomeAssistant/HAAuthManager.swift) The Home Assistant access token is stored in the macOS Keychain with `kSecAttrAccessibleAfterFirstUnlock`. The server URL is stored in `UserDefaults` (acceptable — it's not a secret). ### 7. ✅ No Hardcoded Secrets or API Keys Scanned the entire codebase — no hardcoded tokens, passwords, API keys, or secrets were found. ### 8. ✅ App Sandbox Enabled **File:** [Itsyhome.entitlements](file:///Users/alaschgari/test/itsyhome-macos/Itsyhome/Itsyhome.entitlements) The app runs in a sandbox with only the entitlements it needs: - `com.apple.developer.homekit` - `com.apple.security.network.client` + `network.server` - `com.apple.developer.ubiquity-kvstore-identifier` (iCloud KV store) ### 9. ✅ Zero Third-Party Dependencies No SPM packages, CocoaPods, or Carthage dependencies. The entire app is built with Apple frameworks only, eliminating supply chain risk. ### 10. ✅ URL Scheme Validation Is Properly Whitelisted The URL validator only accepts `http`, `https`, `ws`, and `wss` schemes, and the URL scheme handler only accepts a fixed set of actions (`toggle`, `on`, `off`, `lock`, `unlock`, etc.). ### 11. ✅ Process() Usage Is Safe `Process()` is only used to call `/usr/bin/open` with the app's own bundle path for restart — no user-controlled input reaches this call. --- ## Risk Matrix | # | Finding | Severity | Exploitable? | |---|---------|----------|-------------| | 1 | No auth on webhook server | 🔴 High | Yes — same network | | 2 | Wildcard CORS | 🔴 High | Yes — any webpage | | 3 | ATS disabled globally | 🟡 Medium | MITM on local traffic | | 4 | URL scheme no confirmation | 🟡 Medium | Any local app | | 5 | Public logging of device data | 🟡 Medium | Local user access |

kerem closed this issue

2026-03-03 16:43:19 +03:00

kerem commented

2026-03-03 16:43:19 +03:00

Author

Owner

@nickustinov commented on GitHub (Feb 21, 2026):

Hey! Web server is disabled by default, and unless you are sure what you are doing and know whats happening in your network I would recommend keeping it disabled.

@nickustinov commented on GitHub (Feb 21, 2026): Hey! Web server is disabled by default, and unless you are sure what you are doing and know whats happening in your network I would recommend keeping it disabled.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/itsyhome-macos#66

No description provided.

Rows
Columns