- Checking for overflow of integer addition needs to be done with - care, because automatic type promotion can prevent the check - from working correctly. -
-- Use an explicit cast to make sure that the result of the addition is - not implicitly converted to a larger type. -
-- On a typical architecture where short is 16 bits - and int is 32 bits, the operands of the addition are - automatically promoted to int, so it cannot overflow - and the result of the comparison is always false. -
-- The code below implements the check correctly, by using an - explicit cast to make sure that the result of the addition - is unsigned short. -
-
+Checking for overflow of integer addition needs to be done with
+care, because automatic type promotion can prevent the check
+from working as intended, with the same value (true
+or false) always being returned.
+
+Use an explicit cast to make sure that the result of the addition is +not implicitly converted to a larger type. +
+
+On a typical architecture where short is 16 bits
+and int is 32 bits, the operands of the addition are
+automatically promoted to int, so it cannot overflow
+and the result of the comparison is always false.
+
+The code below implements the check correctly, by using an
+explicit cast to make sure that the result of the addition
+is unsigned short (which may overflow, in which case
+the comparison would evaluate to true).
+
+Data received over a network connection may be received in a different byte order than
+the byte order used by the local host, making the data difficult to process. To address this,
+data received over the wire is usually converted to host byte order by a call to a network-to-host
+byte order function, such as ntohl.
+
+The use of a network-to-host byte order function is therefore a good indicator that the returned +value is unvalidated data retrieved from the network, and should not be used without further +validation. In particular, the returned value should not be used as an array index or array length +value without validation, as this could result in a buffer overflow vulnerability. +
++Validate data returned by network-to-host byte order functions before use and especially before +using the value as an array index or bound. +
+In the example below, network data is retrieved and passed to ntohl to convert
+it to host byte order. The data is then used as an index in an array access expression. However,
+there is no validation that the data returned by ntohl is within the bounds of the array,
+which could lead to reading outside the bounds of the buffer.
+
In the corrected example, the returned data is validated against the known size of the buffer, +before being used as an array index.
+A common pattern is to initialize a local variable by calling another function (an +"initialization" function) with the address of the local variable as a pointer argument. That +function is then responsible for writing to the memory location referenced by the pointer.
+ +In some cases, the called function may not always write to the memory pointed to by the +pointer argument. In such cases, the function will typically return a "status" code, informing the +caller as to whether the initialization succeeded or not. If the caller does not check the status +code before reading the local variable, it may read unitialized memory, which can result in +unexpected behavior.
+ +When using a initialization function that does not guarantee to initialize the memory pointed to +by the passed pointer, and returns a status code to indicate whether such initialization occurred, +the status code should be checked before reading from the local variable.
+ +In this hypothetical example we have code for managing a series of devices. The code
+includes a DeviceConfig struct that can represent properties about each device.
+The initDeviceConfig function can be called to initialize one of these structures, by
+providing a "device number", which can be used to look up the appropriate properties in some data
+store. If an invalid device number is provided, the function returns a status code of
+-1, and does not initialize the provided pointer.
In the first code sample below, the notify function calls the
+initDeviceConfig function with a pointer to the local variable config,
+which is then subsequently accessed to fetch properties of the device. However, the code does not
+check the return value from the function call to initDeviceConfig. If the
+device number passed to the notify function was invalid, the
+initDeviceConfig function will leave the config variable uninitialized,
+which will result in the notify function accessing uninitialized memory.
To fix this, the code needs to check that the return value of the call to
+initDeviceConfig is zero. If that is true, then the calling code can safely assume
+that the local variable has been initialized.
odasa --index, unless indexing has been disabled, in which case
+ /// + A write that looks like it may be bypassing runtime checks. +
+ ++The APIs provided by the .NET libraries for XML manipulation allow the insertion of "raw" text at +a specified point in an XML document. If user input is passed to this API, it could allow a +malicious user to add extra content that could corrupt or supersede existing content, or enable +unintended additional functionality. +
+
+Avoid using the WriteRaw method on System.Xml.XmlWriter with user input.
+If possible, use the high-level APIs to write new XML elements to a document, as these automatically
+escape user content. If that is not possible, then user input should be escaped before being
+included in a string that will be used with the WriteRaw API.
+
In this example, user input is provided describing the name of an employee to add to an XML
+document representing a set of names. The WriteRaw API is used to write the new
+employee record to the XML file.
However, if a malicious user were to provide the content
+ Bobby Pages</name></employee><employee><name>Hacker1, they
+would be able to add an extra entry into the XML file.
+
The corrected version demonstrates two ways to avoid this issue. The first is to escape user
+input before passing it to the WriteRaw API, which prevents a malicious user from
+closing or opening XML tags. The second approach uses the high level XML API to add XML elements,
+which ensures the content is appropriately escaped.
+C# supports runtime loading of assemblies by path through the use of the
+System.Reflection.Assembly API. If an external user can influence the path used to
+load an assembly, then the application can potentially be tricked into loading an assembly which
+was not intended to be loaded, and executing arbitrary code.
+
+Avoid loading assemblies based on user provided input. If this is not possible, ensure that the path
+is validated before being used with Assembly. For example, compare the provided input
+against a whitelist of known safe assemblies, or confirm that the path is restricted to a single
+directory which only contains safe assemblies.
+
In this example, user input is provided describing the path to an assembly, which is loaded +without validation. This is problematic because it allows the user to load any assembly installed +on the system, and is particularly problematic if an attacker can upload a custom DLL elsewhere on +the system.
+In the corrected version, user input is validated against one of two options, and the assembly +is only loaded if the user input matches one of those options.
++ SQL Server connections where the client is not enforcing the encryption in transit are susceptible to multiple attacks, including a man-in-the-middle, that would potentially compromise the user credentials and/or the TDS session. +
+ +Ensure that the client code enforces the Encrypt option by setting it to true in the connection string.
The following example shows a SQL connection string that is not explicitly enabling the Encrypt setting to force encryption.
+ The following example shows a SQL connection string that is explicitly enabling the Encrypt setting to force encryption in transit.
+
Deserializing a delegate object may result in remote code execution, when an +attacker can control the serialized data.
+ +Avoid deserializing delegate objects, if possible, or make sure that the serialized +data cannot be controlled by an attacker.
+ +In this example, a file stream is deserialized to a Func<int>
+object, using a BinaryFormatter. The file stream is a parameter of a public
+method, so depending on the calls to InvokeSerialized, this may or may not
+pose a security problem.
Deserializing an object from untrusted input may result in security problems, such +as denial-of-service or remote code execution.
+ +Avoid using an unsafe deserialization framework.
+ +In this example, a string is deserialized using a
+JavaScriptSerializer with a simple type resolver. Using a type resolver
+means that arbitrary code may be executed.
To fix this specific vulnerability, we avoid using a type resolver. In other cases, +it may be necessary to use a different deserialization framework.
+ +Deserializing an object from untrusted input may result in security problems, such +as denial-of-service or remote code execution.
+ +Avoid deserializing objects from an untrusted source, and if not possible, make sure +to use a safe deserialization framework.
+ +In this example, text from an HTML text box is deserialized using a
+JavaScriptSerializer with a simple type resolver. Using a type resolver
+means that arbitrary code may be executed.
To fix this specific vulnerability, we avoid using a type resolver. In other cases, +it may be necessary to use a different deserialization framework.
+ +