Add AvoidUsingBrokenHashAlgorithms

[MJVL]

PR Summary

This adds a new rule: AvoidUsingBrokenHashAlgorithms.

This rule searches for use of SHA-1 or MD5 within -Algorithm parameters. This mainly serves to flag use with Get-FileHash, but also works for other cmdlets which may use the same parameter scheme. Should other algorithms in the future be deemed insecure, it would be trivial to add them.

At this point both of these algorithms are broken (Microsoft SDL has labeled them as such since 2009), so I think it would be worthwhile to flag these, such that new code doesn't use these algorithms except when needed for backwards compatability.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

[ghost]

All CLA requirements met.

[bergmeister]

Thanks for the contribution and very good idea. I'll be giving it a test run but from a high level looks good otherwise. I might suggest something minor around the parameter parsin

[MJVL]

Thanks for the contribution and very good idea. I'll be giving it a test run but from a high level looks good otherwise. I might suggest something minor around the parameter parsin

Cool, thanks! I'll fix anything as needed when you get a chance to review.

[bergmeister]

An optional improvement would be to make it also work when no named parameters are used: Invoke-ScriptAnalyzer -ScriptDefinition 'Get-FileHash foo SHA1'

[MJVL]

Good idea. Can you see of any cases where this might false flag? Ie, someone opening a file that's named the same as a flagged hashing algorithm?

[bergmeister]

No, because what you would do is check whether the first and second item in the array are not named parameters, i.e. do not start with dash and therefore you know for sure that the first one has to be the file name and the second one the algorithm

[bergmeister]

Looks good, I would just change severity from Warning. An optional suggestion on improving parsing but this could also just be a follow up PR as I'd rather want to wrap this up and ship it quickly in the next version of PSSA.
Docs question to @sdwheeler What do we do with the docs/Rules folder in this repo now? Do we have to replicate the same change here: https://github.com/MicrosoftDocs/PowerShell-Docs-Modules/tree/main/reference/docs-conceptual/PSScriptAnalyzer/Rules

[MJVL]

Looks good, I would just change severity from Warning. An optional suggestion on improving parsing but this could also just be a follow up PR as I'd rather want to wrap this up and ship it quickly in the next version of PSSA. Docs question to @sdwheeler What do we do with the docs/Rules folder in this repo now? Do we have to replicate the same change here: https://github.com/MicrosoftDocs/PowerShell-Docs-Modules/tree/main/reference/docs-conceptual/PSScriptAnalyzer/Rules

Thanks for the input! Fixed severities and unit tests based on your review comments.

I lack the bandwidth at the moment to improve the parsing, but it's something I could look into in the future. I think we should leave that as a follow-up PR like you said to get this to ship faster.

[sdwheeler]

Docs question to @sdwheeler What do we do with the docs/Rules folder in this repo now? Do we have to replicate the same change here: https://github.com/MicrosoftDocs/PowerShell-Docs-Modules/tree/main/reference/docs-conceptual/PSScriptAnalyzer/Rules

Yes. I just need to know when you are going to release and then I will copy the updated docs from the source repository to the docs repository. Eventually we want a CI job to do that automatically at release time. But for now, I can do it manually.