🛠 DevSecOps practices for C

Salute,

Let's look at OOP today, from the perspective of non-standard recommendations for C. I think this is a useful start, especially when you are just looking towards development, and in this way you can understand for yourself where it is better to move on.

For pointers you need to consider:

- Pointer forgery, where they cannot be misused to access, duplicate or change object variables

- Address arithmetic, where memory is dynamically allocated to an array, which can lead to errors in reading adjacent memory areas

- Dangling pointers, where an object is deleted/released without changing the value of the associated pointer

- Wandering pointers, where it is prohibited to use a pointer without first initializing it for any state, since the behavior is similar to dangling pointers

Now look, there are non-standard things like recommendations:

- Using forced pointer initialization to remove wild pointers

- After deleting the pointer, you must set it to a null or invalid address

- Instead of iterating over an array using address arithmetic, you need to use a separate index variable and check that the index does not exceed the size of the array

- Use Garbage Collector to free memory used by objects that are no longer referenced by system.gc, delete

- Control the invocation of superclass operations to avoid type confusion due to lax type checking in the language

- The use of functions that do not perform bounds checking, such as strcpy(), strcat(), sprintf(), vsprintf() and gets(), should be eliminated and replaced with strncpy(), strncat(), snprintf() and fgets()

- When using scanf(), scanf(), fscanf(), sscanf(), vscanf(), vsscanf() and vfscanf() functions, the length must be controlled

- It is necessary to exclude the use of functions that allow you to implement buffer overflow capabilities: realpath(3), getopt(3), getpass(3), stradd(3), strecpy(3) and strtrns(3)

- Use calloc() instead of malloc() for dynamic memory allocation

- Implement integer range checking as part of input validation due to truncation

- Declare variable as volatile for deletion

- Use the mlock() system call for UNIX and VirtualLock() for Windows, which prevents locked memory from being paged out to disk

- Use IndexOutOfRangeException to track attempts to access an incorrect index

- Use an unsafe context with unsafe to work with pointers, which disables automatic safety checks provided they are cleared after and control bounds checking, correct memory management

- Access to unsafe is strictly regulated and used as an exception

- Eliminate the formation of SQL queries by string concatenation

- Focus on parameterized queries

- Use modern cryptographic algorithms BCrypt or Argon2 with salt and iterations to store password hashes

- Avoid directly outputting user input

- Try to use context-sensitive cleaning

- Use thread-safe collections (ConcurrentDictionary, ConcurrentQueue)

Now here are the differences for C#, what exactly should be ignored:

- Working with pointers: forgery, dangling and wandering pointers, forced initialization, reset after deletion

- Address arithmetic for arrays

- Using malloc(), calloc(), free(); manual memory management

- Using functions like strcpy(), sprintf(), gets(), scanf() and similar for I/O

- mlock() and VirtualLock() system calls (except for specific cases with secrets)

- Using volatile to control object deletion

- Checking for type confusion via superclass call (C# is strongly typed)

Overall: this concept reduces information security risks when working with OOP code, so by following them and having a basic understanding of the principles of their operation, you will be able to build a high-quality development process, and it will also help you to further look at such issues when interacting with the development team.

#appsec #devsecops #reco #specialty #pmcases