[BULK] [Bundle-Security] - Scheduled execution to fix known issues#1128
Conversation
|
#docutune-review |
| ## See Also | ||
|
|
||
| [FTP Managed-Code Extensibility API Reference](https://msdn.microsoft.com/library/e7b57c2a-e14c-4f14-9707-df95ab8b3660) | ||
| [FTP Managed-Code Extensibility API Reference](https://msdn.microsoft.com/library/aaaabbbb-0000-cccc-1111-dddd2222eeee) |
There was a problem hiding this comment.
These are actual page identifiers. They are links to specific content using the id of page. This is a false positive and breaks the link to the topic if this ttype of change is merged.
wadepickett
left a comment
wadepickett
left a comment
There was a problem hiding this comment.
Links to articles using page identifiers are being broken and replaced by generic identifiers. Is that the intent?
|
The entirety of this PR may need to be reverted. Although I am still checking on one COM interface UUID for IAppHostPathMapper2 that was flagged. False postives that need to be reverted and now have been reported to be added to the "allow list".
There is one exception I am still looking into: | Details:The GUIDs flagged by the DocuTune security scan are not sensitive data—they are MSDN article identifiers used in documentation links (e.g., https://msdn.microsoft.com/library/e7b57c2a-e14c-4f14-9707-df95ab8b3660). Replacing these with placeholder GUIDs (aaaabbbb-0000-cccc-1111-dddd2222eeee) would break all 11 affected links across 9 files, resulting in 404 errors for readers trying to access referenced API documentation. Additionally, one change incorrectly modifies a COM interface UUID (0f80e901-8f4c-449a-bf90-13d5d082f187) that developers need for implementation. These are public identifiers, not secrets or security risks. Recommend updating the DocuTune scanning rules to exclude MSDN library URL GUIDs and COM interface UUIDs from remediation. PR #1128 - Broken GUID Links SummaryThe foolowing are all GUID's used for article links as they should be except perhpas the COM interface UUID which I am looking into: Files with MSDN Article Links Being Replaced
|
|
For this item: | iis/web-development-reference/native-code-api-reference/iapphostpathmapper2-mappath-method.md | 42 | 0f80e901-8f4c-449a-bf90-13d5d082f187 | COM interface UUID for IAppHostPathMapper2 | I don't think we want to replace this with a generic fake ID. It is not fixing a security risk as far as I can tell: Why a COM Interface UUID might be a false positive as a security risk A COM IID Is a Public Identifier, Not a Secret
Knowing an IID is equivalent to knowing:
All of these are intentionally public. The IID Is Already Widely Published
If an attacker can:
…the IID is trivially discoverable. There is no confidentiality boundary around it. COM Security Does Not Rely on Obscurity
It is not enforced by hiding or obfuscating interface IIDs. |
There was a problem hiding this comment.
Conclusion:
Every one of these GUID replacements are for false positive security issues. The entire PR needs to be closed and not merged.
I will report the GUID's first to get them on an allow list first, and then close this issue.
All but one of the changes introduced in this PR are for article link GUID's which are valide to use.
Then there is an attempt to replace a COM interface UUID with a generic fake GUID. This is also a false postive.
|
Who is the contact for these? It would be helpful if it was dropped in the description or something when PR's are created. |
|
Closing. No valid GUID's were replaced here. Reporting them all for the allow list so this does not happen again. |
2 participants
Remediating articles to align with content SFI guidance related to sensitive terms with GUIDs, thumbprints, and secrets.
DocuTune v1.0.0.0
CorrelationId: 701ed572-bf09-49e7-a007-1117353ced87
#docutune