Summary
Two robustness gaps around the 0.62.1 ConvertFrom-Json swap in Get-TssSecretField.ps1. Both address error/edge-case behavior downstream of the decode, and belong in one PR.
1. ConvertFrom-Json result is not asserted to be a string
File: src/functions/secrets/Get-TssSecretField.ps1:165-167
if ($apiResponse.Content) {
$apiResponse.Content = $apiResponse.Content | ConvertFrom-Json
}
. $ProcessResponse $apiResponse
RestSharp.RestResponse.Content is a [string] property. If a future Secret Server version (or a MITM/misconfigured proxy) returns a JSON object or array on this endpoint, ConvertFrom-Json yields a PSCustomObject or array; assigning that to .Content implicitly stringifies (@{foo=bar} etc.) and the downstream ProcessResponse sees garbage. No exploitable path — the endpoint contract is scalar today — but the code silently corrupts output.
Proposed fix:
if ($apiResponse.Content) {
$decoded = $apiResponse.Content | ConvertFrom-Json
if ($decoded -isnot [string]) {
Write-Warning "Unexpected non-string field response for [$Slug] on secret [$secret]"
return
}
$apiResponse.Content = $decoded
}
2. ConvertFrom-Json shares the outer try/catch with HTTP failures; JSON null maps to \$null silently
File: src/functions/secrets/Get-TssSecretField.ps1:157-174
Two side-effects of the 0.62.1 decode swap:
- Decode-time exceptions (e.g. non-JSON response body) are caught by the outer try/catch and surface the same warning as HTTP failures:
Issue getting field [\$Slug] on secret [\$secret]. This loses the distinction between transport and parsing errors.
- If the API returns the JSON literal
null (2 bytes), ConvertFrom-Json produces PowerShell \$null. Assigned back to .Content, ProcessResponse emits \$null. In 0.62.0 the Substring(1, length-2) produced the string 'ul' (which was clearly wrong, but different).
Proposed fix:
- Wrap the
ConvertFrom-Json block in its own try/catch with a distinct warning (Unable to decode field response as JSON: {message}).
- Add a
.NOTES line documenting that a JSON-null response yields \$null (not the string 'null').
Discovery
Consolidated PR review of v0.62.0 → dev (0.62.1 candidate). Related to the #370/#336 fix (PR #470).
Summary
Two robustness gaps around the 0.62.1
ConvertFrom-Jsonswap inGet-TssSecretField.ps1. Both address error/edge-case behavior downstream of the decode, and belong in one PR.1.
ConvertFrom-Jsonresult is not asserted to be a stringFile:
src/functions/secrets/Get-TssSecretField.ps1:165-167RestSharp.RestResponse.Contentis a[string]property. If a future Secret Server version (or a MITM/misconfigured proxy) returns a JSON object or array on this endpoint,ConvertFrom-Jsonyields aPSCustomObjector array; assigning that to.Contentimplicitly stringifies (@{foo=bar}etc.) and the downstreamProcessResponsesees garbage. No exploitable path — the endpoint contract is scalar today — but the code silently corrupts output.Proposed fix:
2.
ConvertFrom-Jsonshares the outer try/catch with HTTP failures; JSONnullmaps to\$nullsilentlyFile:
src/functions/secrets/Get-TssSecretField.ps1:157-174Two side-effects of the 0.62.1 decode swap:
Issue getting field [\$Slug] on secret [\$secret]. This loses the distinction between transport and parsing errors.null(2 bytes),ConvertFrom-Jsonproduces PowerShell\$null. Assigned back to.Content,ProcessResponseemits\$null. In 0.62.0 theSubstring(1, length-2)produced the string'ul'(which was clearly wrong, but different).Proposed fix:
ConvertFrom-Jsonblock in its own try/catch with a distinct warning (Unable to decode field response as JSON: {message})..NOTESline documenting that a JSON-null response yields\$null(not the string'null').Discovery
Consolidated PR review of v0.62.0 → dev (0.62.1 candidate). Related to the #370/#336 fix (PR #470).