Secure Code Warrior C# Basic OWASP Web Top 10 2017 8: Insecure deserialization, 9: Using Components with Known Vulnerabilities, 10: Insufficient Logging and Monitoring

Last but not least. These set challenges consist of 8: Insecure deserialization, 9: Using Components with Known Vulnerabilities, 10: Insufficient Logging and Monitoring

8: Insecure deserialization,

Injection Flaws - Deserialization of Untrusted Data

  using (var stream = File.OpenRead(

                fileName ?? throw new InvalidOperationException()))

            {

                articles = SerializerServices

                    .DeserializeObject<List<Article>>(

                        stream, settings);

            }

The application deserializes input XML files to parse Articles information. However, a malicious user can tamper with such files to inject malicious content or cause an application crash.

The application uses encryption/decryption techniques to avoid malicious actors from tampering with such files. When the application deserializes an XML input file, it first decrypts it using the same key that was used for encryption. Additionally, using XmlSerializer(typeof (T)) will prevent (de-)serialization of objects of anything but the desired type.

 var articles =

                SerializerServices.DecryptAndDeserialize<List<Article>>(

                    fileName,

                    Environment.GetEnvironmentVariable("CRYPTO_KEY"),

                    settings);

Injection Flaws - Deserialization of Untrusted Data

The application deserializes input XML files to parse Mobile information. However, a malicious user can tamper with such files to inject malicious content or cause an application crash.

The application uses encryption/decryption techniques to avoid malicious actors from tampering with such files. When the application deserializes an XML input file, it first decrypts it using the same key that was used for encryption. Additionally, using XmlSerializer(typeof (T)) will prevent (de-)serialization of objects of anything but the desired type.

这里的第2小题和第1小题，完全一样的类型和内容

Injection Flaws - Deserialization of Untrusted Data

 public static T DecryptAndDeserialize<T>(

            string filename,

            string password,

            XmlReaderSettings settings = null)

        {

            using (var filestream = File.Open(filename, FileMode.Open))

            {

                return DeserializeObject<T>(filestream, settings);

            }

        }

There is no encryption during serialization, nor decryption during deserialization. The data is vulnerable to an adversary who could manipulate it, or insert incorrect or dangerous data.

All data during (de-)serialization are decrypted/encrypted using the Triple DES. Triple DES is considered unsafe when dealing with a large amount of data. Anyhow, it is not recommended because performance-wise it is considered really slow.

All data during (de-)serialization are decrypted/encrypted using the DES. The Data Encryption Standard (DES) was created in the seventies. Nowadays it is considered deprecated. Its key size is too short and it can be broken by a brute force attack. In addition, DES uses 64-bit blocks, which causes some potential problems when encrypting several gigabytes of data with the same key.

All data during (de-)serialization are decrypted/encrypted using the AES 128 bits algorithm with the 256-bit key, where the key is generated according to the PBKDF2 standard with a sufficient number of iterations, one million in this case. Using XmlSerializer(typeof (T)) will prevent (de-)serialization of objects of anything but the desired type.

       private static Rijndael CreateRijndael(

            string password)

        {

            var rijndael = Rijndael.Create();

            var pdb = new Rfc2898DeriveBytes(password, Pepper, 1000000);

            rijndael.Key = pdb.GetBytes(32);

            rijndael.IV = pdb.GetBytes(16);

            return rijndael;

        }

 

9: Using Components with Known Vulnerabilities,

Vulnerable Components - Using Known Vulnerable Components

The jQuery 1.5.2 library is vulnerable to a large number of implementations of Cross-Site Scripting (XSS). This version of the jQuery library is deprecated and needs to be updated.

The application now uses jQuery 3.5.0 library. This version fixes vulnerabilities that allowed for XSS and DoS attacks. XSS attacks allow an attacker to add various javascript or HTML content to a user. DoS attacks cause the application to crash and change its behavior.

Vulnerable Components - Using Known Vulnerable Components

错误

 <PackageReference Include="System.Net.Security" Version="4.0.0" />

Using an outdated security library that contains an "Improper Certificate Validation" vulnerability may allow an adversary to bypass security controls when an invalid certificate is presented.

It is recommended to use up-to-date libraries and regularly check for known vulnerabilities. The NuGet package System.Net.Security has been updated to version 4.3.2, eliminating several vulnerabilities, including "Invalid certificate validation". An adversary will not be able to bypass security controls when an invalid SSL certificate is presented.

Vulnerable Components - Using Components From Untrusted Source

错误

using PasswordHasher = MorrisNextGen.Security.Hashing.YAPH;

using Encryption = MorrisNextGen.Security.Encrypting.YAEA;

Using encryption and hashing utilities from untrusted sources may introduce unexpected vulnerabilities into the application. An adversary could take advantage of it to introduce malicious code into the downloaded components.

正确，自己用aes实现了工具类

It is recommended to avoid using components from untrusted sources. The application is using built-in utilities for encryption and hashing instead of relying on external components. In this way, it will not be vulnerable to unexpected errors or bugs with malicious purposes.

 

10: Insufficient Logging and Monitoring

Insufficient Logging and Monitoring - Insufficient Logging and Monitoring

错误

 Console.WriteLine(e.Message);

There is no entry in the Windows Event Log when an exception occurs that is associated with an incorrect login or password. Only an error message is displayed in the console, which will not be saved anywhere.

应该记录日志

Using Logger.LogError(e.Message) will display an error message in the console and will save it in the Windows Event Log. This feature will allow analyzing program errors in the future.

Insufficient Logging and Monitoring - Insufficient Logging and Monitoring

错误

  AppDomain.CurrentDomain.UnhandledException += null;

No records are kept about exceptions that occurred in the application. Attackers take advantage of this to go about undetected.

Interception of unhandled exceptions is enabled in the Main() method. If an exception occurs in the static fields before this method, the exception will not be caught. Also, the user will be displayed all the information about the error, including the stack trace. This gives a potential attacker too much information about the application's inner workings.

    private static ILogger GetLogger()

        {

            var logger = ApplicationLogging.LoggerFactory

                .AddConsole(LogLevel.Information).AddEventLog(LogLevel.Debug)

                .CreateLogger<Program>();

            AppDomain.CurrentDomain.UnhandledException += (sender, e) =>

                {

                    var innerException =

                        ((Exception)e.ExceptionObject).InnerException;

                    logger.LogCritical(innerException?.Message);

                };

            return logger;

        }

意思是unhandle exception不能在main函数里面处理

Insufficient Logging and Monitoring - Insufficient Logging and Monitoring

    var logger = ApplicationLogging.LoggerFactory

                .AddConsole(LogLevel.Information).AddEventLog(LogLevel.Debug)

                .CreateLogger<Program>();

日志初始化之后，都用日志处理，不要再用Console了

When an exception occurs during the unsuccessful deletion of a user, there is no persistent record of the event, as the error message is only written to the console. This approach results in inadequate logging and monitoring, as the error information is not stored in a centralized logging system like the Windows Event Log or a dedicated log file. Consequently, this limited visibility hampers the ability to detect, investigate, and respond to potential security incidents or application issues in a timely manner.

By utilizing Logger.LogError(...), the error message is not only displayed in the console but also saved in a persistent logging system such as the Windows Event Log or a dedicated log file. This approach enhances the application's logging and monitoring capabilities, enabling future analysis of program errors. Depending on your business rules, logs could include additional information like stack traces (be aware that it might contain sensitive information), inner exceptions, etc.