fix(query): fixed false negative for "App Service Authentication Disabled" query missing resources

[cx-ricardo-jesus]

Closes #

Reason for Proposed Changes

• The query App Service Authentication Disabled was not taking into consideration the resources azurerm_linux_web_app and azurerm_windows_web_app not verifying if the authentication settings for these two resources are enabled.

Proposed Changes

• After analyzing the documentation regarding the "azurerm_app_service", "azurerm_linux_web_app" and "azurerm_windows_web_app" resources, I maintained the same verifications for the resource that was already being analyzed and extended the query in order to verify the authentication field on the two other resources.
• Comparing the resources azurerm_linux_web_app and azurerm_windows_web_app with the resource azurerm_app_service I realized that there is another authentication field called auth_settings_v2 that was not present on the last one.
• So, taking what I said in the last point into account, I kept the policies that tackles the vulnerabilities on the resource azurerm_app_service, and added an extra one that uses a helper function called prepare_issues, which verifies not only the auth_settings field but also the auth_settings_v2 field and handles all the cases regarding the new resources that are going to be analyzed in this query for these two fields.
• For the new resources, I kept the same reasoning used on the resource that was already on the query for the auth_settings field because, according to the information present on the documentation, this field has equal settings and fields within for all the resources.
• For the field auth_settings_v2, there is small things that changes in comparison to the field auth_settings, more precisely, the field auth_settings_v2 not being required and set to false by default, which should return a positive result, made me deal with it in a slightly different way, returning a positive result on the query when this field is not defined.
• On top of that, I added eight new samples that should return a positive result and four more Terraform samples that should return a negative result. All of these new test sample are provided in order to cover all the possibilities regarding positive and negative results.
• NOTE: When both fields auth_settings and auth_settings_v2 are not defined, I only inserted the auth_settings block on the remediation field and not the auth_settings_v2 but this positive case can be solved defining the field auth_settings_v2 instead of the auth_settings field.
  I submit this contribution under the Apache-2.0 license.

[cx-artur-ribeiro]

LGTM, nice work on all the test cases included.
Just left a change on your comment but nothing too important.

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
4266022	Triggered	Generic Password	1602b39	assets/queries/cloudFormation/aws/amplify_branch_basic_auth_config_password_exposed/test/negative7.yaml	View secret
9419039	Triggered	Username Password	1602b39	assets/queries/cloudFormation/aws/amplify_branch_basic_auth_config_password_exposed/test/positive5.yaml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[cx-artur-ribeiro]

LGTM