The WebClient class provides a variety of methods for data transmission and -communication with a particular URI. Despite of the class' naming convention, -the URI scheme can also identify local resources, not only remote ones. Tainted -by user-supplied input, the URI can be leveraged to access resources available -on the local file system, therefore leading to the disclosure of sensitive -information. This can be trivially achieved by supplying path traversal -sequences (../) followed by an existing directory or file path.
- -Sanitization of user-supplied URI values using the
-StartsWith("https://") method is deemed insufficient in preventing
-arbitrary file reads. This is due to the fact that .NET ignores the protocol
-handler (https in this case) in URIs like the following:
-"https://../../../../etc/passwd".
Validate user input before using it to ensure that is a URI of an external -resource and not a local one. -Potential solutions:
- -System.Uri.IsWellFormedUriString.In the first example, a domain name is read from a HttpRequest
-and then this domain is requested using the method DownloadString.
-However, a malicious user could enter a local path - for example,
-"../../../etc/passwd" instead of a domain.
-In the second example, it appears that the user is restricted to the HTTPS
-protocol handler. However, a malicious user could still enter a local path,
-since as explained above the protocol handler will be ignored by .net. For
-example, the string "https://../../../etc/passwd" will result in the code
-reading the file located at "/etc/passwd", which is the system's password file.
-This file would then be sent back to the user, giving them access to all the
-system's passwords.
Directly incorporating user input into a HTTP request without validating the input -can facilitate Server Side Request Forgery (SSRF) attacks. In these attacks, the server -may be tricked into making a request and interacting with an attacker-controlled server. -
- -To guard against SSRF attacks, it is advisable to avoid putting user input -directly into the request URL. Instead, maintain a list of authorized -URLs on the server; then choose from that list based on the user input provided.
- -The following example shows an HTTP request parameter being used directly in a forming a -new request without validating the input, which facilitates SSRF attacks. -It also shows how to remedy the problem by validating the user input against a known fixed string. -
- -
-Cookies without HttpOnly flag are accessible to JavaScript running in the same origin. In case of
-Cross-Site Scripting (XSS) vulnerability the cookie can be stolen by malicious script.
-
-Protect sensitive cookies, such as related to authentication, by setting HttpOnly to true to make
-them not accessible to JavaScript. In ASP.NET case it is also possible to set the attribute via <httpCookies> element
-of web.config with the attribute httpOnlyCookies="true".
-
-In the example below Microsoft.AspNetCore.Http.CookieOptions.HttpOnly is set to true.
-
-In the following example CookiePolicyOptions are set programmatically to configure defaults.
-
-In the example below System.Web.HttpCookie.HttpOnly is set to true.
-
Azure Storage .NET, Java, and Python SDKs support encryption on the client with a customer-managed key that is maintained in Azure Key Vault or another key store.
-Current release versions of the Azure Storage SDKs use cipher block chaining (CBC mode) for client-side encryption (referred to as v1).
Consider switching to v2 client-side encryption.
-Sensitive data that is transmitted using HTTP is vulnerable to being read by a third party. By default, -cookies are sent via HTTP, not HTTPS. -
-
-In ASP.NET case when using cookies ensure that HTTPS is used by setting the property Microsoft.AspNetCore.Http.CookieOptions.Secure to true.
-
-In ASP.NET Core case when using cookies, ensure that HTTPS is used, either via the <forms> attribute above, or
-the <httpCookies> element, with the attribute requireSSL="true". It is also possible to require cookies
-to use HTTPS programmatically, by setting the property System.Web.HttpCookie.Secure to true.
-
-In the example below Microsoft.AspNetCore.Http.CookieOptions.Secure is set to true programmatically.
-
-In the following example CookiePolicyOptions are set programmatically to configure defaults.
-
-In the example below System.Web.HttpCookie.Secure is set to true programmatically.
-
In cryptography, a salt is some random data used as an additional input to a one-way function that hashes a password or pass-phrase. It makes dictionary attacks more difficult.
- -Without a salt, it is much easier for attackers to pre-compute the hash value using dictionary attack techniques such as rainbow tables to crack passwords.
-Use a long random salt of at least 32 bytes then use the combination of password and salt to hash a password or password phrase.
-The following example shows two ways of hashing. In the 'BAD' cases, no salt is provided. In the 'GOOD' cases, a salt is provided.
-By setting critical TokenValidationParameter validation delegates to always return true, important authentication safeguards are disabled. Disabling safeguards can lead to incorrect validation of tokens from any issuer or expired tokens.
Improve the logic of the delegate so not all code paths return true, which effectively disables that type of validation; or throw SecurityTokenInvalidAudienceException or SecurityTokenInvalidLifetimeException in failure cases when you want to fail validation and have other cases pass by returning true.
-
This example delegates AudienceValidator to a callable that always returns true.
To fix it, use a callable that performs a validation, and fails when appropriate.
-Token validation checks ensure that while validating tokens, all aspects are analyzed and verified. Turning off validation can lead to security holes by allowing untrusted tokens to make it through validation.
- -Set Microsoft.IdentityModel.Tokens.TokenValidationParameters properties RequireExpirationTime, ValidateAudience, ValidateIssuer, or ValidateLifetime to true. Or, remove the assignment to false because the default value is true.
This example disabled the validation.
-To fix it, do not disable the validations or use the default value.
-The DataSet and DataTable types are legacy .NET components that you can use to represent data sets as managed objects.
While DataSet and DataTable do impose default limitations on the types that are allowed to be present while deserializing XML payloads, DataSet and DataTable are in general not safe when populated with untrusted input.
Please visit DataSet and DataTable security guidance for more details.
- -Please review the DataSet and DataTable security guidance before making use of these types for serialization.
- -This query finds native calls to external functions that are often used in creating backdoors or are generally attributed to unsafe code practices. This is an example of a query that may be useful for detecting potential backdoors. Solorigate is one example that uses this mechanism.
-Any findings from this rule are only intended to indicate suspicious code that shares similarities with known portions of code used for the Solorigate attack. There is no certainty that the code is related or that the code is part of any attack.
-For more information about Solorigate, please visit https://aka.ms/solorigate.
-This query detects situations in which an offset to a last file modification time is used to conditionally execute a particular block of code. This is a common pattern in backdoors, where the file's modification timestamp is the time at which the backdoor was planted, and the time offset is used as a time bomb before a particular code block is executed.
-Any findings from this rule are only intended to indicate suspicious code that shares similarities with known portions of code used for the Solorigate attack. There is no certainty that the code is related or that the code is part of any attack.
-For more information about Solorigate, please visit https://aka.ms/solorigate.
-This query detects code flow from ProcessName property on the Process class into a hash function.
-Such flow is often used in code backdoors to detect running processes and compare them to an obfuscated list of antivirus processes to avoid detection. Solorigate is one example that uses this mechanism.
-Any findings from this rule are only intended to indicate suspicious code that shares similarities with known portions of code used for the Solorigate attack. There is no certainty that the code is related or that the code is part of any attack.
-For more information about Solorigate, please visit https://aka.ms/solorigate.
-