Add API endpoint for community templates and update CLI to use it

[prjseal]

• Create CommunityTemplatesApiController in PSW web app with endpoints:
  • GET /api/communitytemplates/index (returns index.json)
  • GET /api/communitytemplates/template/{fileName} (returns template YAML)
  • GET /api/communitytemplates/clearcache (clears template cache)
• Copy community-templates folder to src/PSW for API serving
• Update PSW.csproj to include community-templates in build output
• Update CommunityTemplateService in CLI to call PSW API instead of GitHub
• Add CommunityTemplatesApiUrl configuration to PSWConfig and appsettings.json
• Update service registration to inject API URL from configuration

This change allows the CLI to fetch templates from the PSW website API instead of directly from GitHub, while still allowing pull requests to GitHub for template updates.

To fix this kind of issue, user-controlled values should be sanitized before being written to logs. For log files that are stored or viewed as plain text, this typically means removing or normalizing newline and other control characters so that a malicious user cannot inject extra log lines or otherwise break the log structure. The functional behavior of the application should remain unchanged; only what is written to the logs is adjusted.

In this specific controller, the only problematic sink is _logger.LogWarning("Invalid filename attempted: {FileName}", fileName); in GetTemplate. The best minimal fix is to create a sanitized version of fileName that strips newline characters (and, optionally, carriage returns) before passing it to the logger. We should keep this change local to the GetTemplate method and avoid altering how fileName is used elsewhere (e.g., in responses or when constructing paths) so existing functionality is preserved.

Concretely, in src/PSW/Controllers/CommunityTemplatesApiController.cs, within the if (fileName.Contains("..") || fileName.Contains("/") || fileName.Contains("\\") ) block, introduce a new variable sanitizedFileName that uses Replace to remove Environment.NewLine and \n/\r characters from fileName, and then log sanitizedFileName instead of fileName. No new methods or imports are required; string.Replace and Environment.NewLine are already available from System, which is typically imported at the project level (and we do not need to modify imports in the snippet).

In general, to fix log-forging issues you should sanitize or encode any user-controlled data before logging. For plain-text logs, the key is to remove or neutralize newline and other control characters so a user cannot visually create fake subsequent log entries. This is typically done with Replace calls or a small helper that strips dangerous characters before logging.

For this specific case, the problematic value is templatePath (derived from user-provided fileName) being logged at line 127. We should ensure that any control characters in fileName do not reach the log. The least intrusive and most localized fix is to sanitize fileName to remove newline characters (and optionally other control characters) right before we use it in that log statement, without changing how the actual file path is built. To keep behavior identical for file access but safer for logs, we can create a sanitized version used only for logging, e.g. var safeTemplatePath = templatePath.Replace("\r", "").Replace("\n", ""); and log that instead. This does not affect file reading and only adjusts what gets written to logs.

Concretely, in src/PSW/Controllers/CommunityTemplatesApiController.cs, within the lambda passed to _memoryCache.GetOrCreateAsync, we will:

• Introduce a local variable safeTemplatePath immediately before logging when the file is not found, removing \r and \n characters from templatePath.
• Update the LogWarning call to log safeTemplatePath instead of templatePath.

No new methods or imports are required; we can rely on string.Replace, which is already available.

In general, to fix log forging issues you should sanitize or encode any user-controlled data before writing it to logs. For plain-text logs, this usually means stripping or replacing newline characters and, optionally, other control characters that may affect log structure. For logs intended for HTML display, HTML-encode user input before logging.

For this specific code, the main sensitive log entry is at line 131, logging templatePath derived from the user-controlled fileName. The most robust and minimal-change fix is to introduce a small private helper method in CommunityTemplatesApiController that takes a string and returns a version safe for logging (e.g., replaces \r and \n with spaces and optionally removes other control characters). Then, call this helper when logging any value that derives from user input: in practice, this affects the templatePath logged at line 131 and possibly the invalid filename logged at line 105 (and the error log at line 144 which includes fileName). This preserves all functionality while ensuring that even if a user submits a filename containing line breaks or control characters, the logs cannot be forged or visually confused.

Concretely:

• Add a private static string SanitizeForLogging(string value) method near the top or bottom of the controller class. This method should:
  • Return the input if it is null.
  • Replace \r and \n with spaces (or remove them).
  • Optionally strip other non-printable control characters (ASCII < 32, except perhaps tab).
• Update the relevant log statements to pass sanitized values instead of the raw fileName / templatePath:
  • Line 105: log SanitizeForLogging(fileName).
  • Line 127: log SanitizeForLogging(templatePath).
  • Line 131: log SanitizeForLogging(templatePath).
  • Line 144: log SanitizeForLogging(fileName).

No new external dependencies are required; the sanitization can be implemented with standard System string operations.

In general, to fix log forging stemming from user input, you should sanitize or normalize any user-controlled values before sending them to the logger. Common mitigations include stripping newline and carriage return characters (and optionally other control characters) so that a single logged value cannot visually break log structure or masquerade as multiple entries. For structured logs, this is often as simple as passing a cleaned version of the string to the logger.

For this specific code, the primary problematic usage is at line 144 where fileName is logged in an error message. We can mitigate the issue by creating a sanitized version of fileName that removes line breaks and then using that sanitized value in the log call. To avoid changing existing behavior beyond sanitization, we should only modify the arguments passed to the logger, not the control flow or response body. A reasonable, lightweight approach within the shown snippet is to create a local variable (e.g., safeFileName) in the catch block that calls .Replace("\r", "").Replace("\n", "") on fileName, and then pass safeFileName to _logger.LogError. This approach keeps changes minimal and does not require altering method signatures or external dependencies.

Concretely, in src/PSW/Controllers/CommunityTemplatesApiController.cs, within the catch (Exception ex) block of GetTemplate, insert a line creating safeFileName using simple string replacement and then use safeFileName instead of fileName in the _logger.LogError call. No new imports are needed; we rely only on string.Replace, which is already available.

---