GitHub Manager And Security - Abdelrhman-AK/WinPaletter GitHub Wiki

🔐 GitHub Security Analysis – For Curious Users & Developers

[!WARNING] Do not use unofficial builds. Some "cracked" versions appear on GitHub. WinPaletter is completely free and does not require a paid license. With GitHub integration for uploading and managing themes directly in the app, always use the official build for your safety.

[!TIP] Documentation describing how GitHub authentication and repository modules are handled securely inside the application.

GitHub Credentials – Security Model

This section explains how the application stores and uses the GitHub OAuth token.

1. Token Storage

Where it is stored

  • Stored inside Windows Credential Manager
  • Accessed via advapi32.dll (CredWrite, CredRead, CredDelete)
  • Credential name: WinPaletter_GitHubToken
  • Stored as a user-scoped credential
  • Persistence mode: CRED_PERSIST_ENTERPRISE

Security Properties

  • Protected by Windows OS (DPAPI protection)
  • Not stored in:
    • Config files
    • Registry
    • Application data folders
  • Only the current Windows user can access it

2. In-Memory Handling

Token Saving

  • Token is trimmed and validated (length 20–256)
  • Stored temporarily only to execute CredWrite
  • Before freeing unmanaged memory:
    • Buffer cleared using RtlSecureZeroMemory
  • Managed copy cleared using Array.Clear

Invalid tokens (null, empty, whitespace, invalid length) are rejected.

Token Loading

  • Credential blob size is validated
  • Token extracted from secure buffer
  • Temporary byte buffer cleared after reading
  • Native memory freed via CredFree
  • Invalid or corrupted credentials are ignored

Runtime Behavior

  • Token is not passed through events
  • Token-loaded event is parameterless
  • UI never receives the token directly
  • Logging does not include token values

Limitations

  • The token exists temporarily as a string inside:
    • Octokit client
    • Local variables
  • .NET strings cannot be forcibly cleared from memory
  • This is a platform limitation, not a design flaw

3. Authentication Lifecycle

Silent Login

  • Token loaded from credential store
  • Assigned to GitHub API client
  • Validity checked via API request
  • If invalid:
    • Credentials cleared
    • Client resets to anonymous mode

Device Flow

  • User authorizes via GitHub
  • Token generated
  • Token stored securely
  • Used only for API requests

Sign-Out

  • Token deleted from Credential Manager
  • Client credentials cleared
  • User redirected to GitHub settings for manual token revocation

The app does not revoke tokens automatically via GitHub API.

4. Logging & Events Policy

The system avoids leaking sensitive data:

  • No token written to logs
  • No token included in events
  • No token sent to UI
  • Logs include only:
    • Exception messages
    • Repository info
    • Branch state
    • Operation status

Full exception objects may still be logged where implemented.

5. OAuth Client ID

  • Client ID is embedded in the application
  • This is public information
  • Exposed during device authorization flow
  • Not considered secret

GitHub Core – Security Review

Security audit of WinPaletter/GitHub/Core/ modules.

1. Cache Module

Security Status

  • Cache keys derived from normalized paths
  • SHA1 / MD5 computed from repository content
  • No user-controlled cryptographic inputs

Path Handling

Paths come from:

  • Repository metadata
  • API responses

No credential exposure detected.

2. Entry Module

  • Converts repository content into internal representation
  • No credential storage
  • No sensitive data leakage

Path values and metadata originate from API.

3. Events Module

  • Token not passed to subscribers
  • Auth failure events expose only error messages
  • User switch event logs login state and username
  • Exceptions logged normally (unchanged)

Security posture: safe regarding token exposure.

4. FileSystem Module

Major Concern – Path Traversal

Initial normalization only trimmed slashes and backslashes.

Potential issue:

  • Paths containing .. could traverse outside expected repository root.

Fix Implemented

Added IsPathSafeForRepository(path):

Rejects paths containing:

  • ..

Applied to:

  • ReadFileBytesAsync
  • WriteFileAsync
  • CreateDirectoryAsync
  • UploadFileAsync
  • GetDirectoryRecursiveAsync
  • GetInfoAsync

Additional Notes

Area Status
File name validation Safe
Commit message usage Low risk (display-level impact only)
Local file reading Safe if validated
API path construction Escaped properly

5. GitHubAuth Module

Security measures confirmed:

  • Credential stored securely
  • Buffer cleared after write
  • Token not included in events
  • Logging excludes token

6. Helpers Module

  • Authorization exceptions only pass error message
  • Rate limit handling returns safe fallback values
  • No credential leakage

7. Navigation Module

  • Logs current path and search keywords
  • Uses safe name validation for rename
  • Exceptions logged normally

No token exposure detected.

8. Repository Module

  • Owner derived from authenticated user
  • Repository names logged
  • Optional parameters may require validation if user-controlled

Security impact: Low.

9. Virtual Repository Explorer

Path Handling

  • Paths used in:
    • Tree fetching
    • Cache retrieval
    • Info queries

URL Generation

Uses:

Uri.EscapeDataString(path);

Correct escaping implemented.

Still requires:

  • Path validation against traversal (..)

Logging

Logs path + errors.

No credential leakage.

Final Security Summary

1. Credential Security

  • Stored securely in Windows Credential Manager
  • User-scoped
  • Proper memory cleanup implemented
  • Not exposed through events or logs

2. Path Security

  • Path traversal protection added
  • Rejected if .. detected
  • Applied to all GitHub Content API operations

3. Logging Policy

  • No secrets logged
  • Exceptions logged as-is
  • Operational metadata logged

4. Attack Surface

Main potential risks:

  • Improper branch name validation
  • Path validation bypass if new entry point added without safety check

Mitigation:

  • Centralize path validation
  • Enforce validation at API boundary

Document reflects current implementation state after security review and fixes by Cursor IDE.

See Also