What are the most common programming language errors that compromise software design security and privacy?

En este punto es importante mencionar la prevención de ejecución de datos (DEP) que viene integrada ya en la mayoría de sistemas operativos y no es más que una técnica para controlar que un programa no se ejecute desde un espacio de memoria en el que no está destinado a hacerlo. Con esto se evita el desbordamiento de búfer causado por alguna aplicación maliciosa.

1) Misapplying patterns from other languages. 2) Performing superficially trivial changes to complex code leveraging less common features of the language. 3) Insufficient unit testing and code coverage. 4) Misunderstanding of the application's implementation scope and lacking defensive programming techniques "The code is not designed to do that!! Why would anyone..." are famous last words 5) improper string and array processing in C/C++ 6) improper bounds checking in C/C++ 7) Misunderstanding or improperly applying concurrency principles or missing potential race conditions. 8) Poor Error handling

the prevent tips, described in this article, are ok, mainly I suggest if your initiating in the software development, try to use Java, Python or C# .net, these programming language have good built-in bounds checkings (avoiding much debugging time). Have good programming!!!

I do a lot of low level work at the embedded level i.e. limited OS if any. While knowing the length of the storage is useful, knowing how the memory map is laid out is also useful. For instance you could be writing within the bounds of the array however if the memory address rolls over, you still might cause issues. If your array is at the end of memory, it may just wrap around to the beginning of memory where your interrupt vectors are located, causing an interrupt to jump to unexpected code.

When I first started my career as an ethical hacker, I discovered a website with a SQL injection vulnerability. I injected a malicious query and obtained sensitive customer information. I reported my findings and provided recommendations for fixing the vulnerability. This experience taught me the importance of ethical hacking and the potential consequences of not properly securing a website. It also motivated me to continue honing my skills to keep companies and their customers safe from cyber attacks.

SQL injection is one of the oldest and most critical security risks for web applications, especially for legacy ones. Some typical remediation techniques for SQL injection include parameterized queries, input validation in both frontend and backend side, writing SQL queries in an object oriented way (e.g., using the Criteria API from Hibernate), etc. Always be mindful about SQL injection and write your code appropriately.

With the rise of development frameworks this risk has been mitigated mostly unless someone purposely adds vulnerability in the code.

Not only will an attacker compromise data, steal data, cause data integrity through sql injection. The server resources on which the data is stored can also be compromise resulting to denial of service. Poor database configuration by administrative accounts to execute SQL services can lead to exposure of critical server administrative accounts. An attacker can decript such credentials and be able to access the server resources i.e, storage. Apply separation of concerns, server administrative accounts must be for accessing the server resources and configurations not sql server resources. Sql server accounts should not have same permissions as server administrative accounts and should be restricted to access server environment

A inje??o de SQL é uma das vulnerabilidades mais comuns em aplica??es web e ocorre quando dados n?o confiáveis s?o inseridos em consultas SQL sem a devida sanitiza??o ou valida??o. Isso permite que um invasor injete código SQL malicioso, manipulando consultas para realizar a??es n?o autorizadas no banco de dados.

XSS is a type of web vulnerability that can allow attackers to inject malicious code into a website. It is a common security issue that can lead to serious consequences for both the website and its users. Programmers can avoid XSS attacks by properly validating and sanitizing all user input, including input from forms, URLs, and cookies. They should also use security-focused coding practices, such as escaping special characters and using secure session management. Regular security testing and vulnerability scanning can also help identify and mitigate XSS vulnerabilities. As a programmer, it is important to take these steps to prevent XSS attacks and protect websites and users from harm.

To stop characters like <, >, and "from being read as HTML or JavaScript code, encrypt them. Have a content security policy in place to manage the resources that can be loaded and used on a webpage. Carry out routine security assessments to detect and address possible cross-site scripting issues.

Um "Script entre Sites" (também conhecido como "Cross-Site Scripting" ou XSS) é uma vulnerabilidade de seguran?a comum em aplica??es web. Nesse tipo de ataque, um invasor insere código malicioso (geralmente JavaScript) em uma página da web que é ent?o executado no navegador de outro usuário. Isso pode permitir que o invasor execute a??es maliciosas em nome do usuário legítimo, como roubo de cookies de autentica??o, redirecionamento para páginas falsas de phishing, roubo de informa??es confidenciais ou até mesmo execu??o de a??es em aplicativos da web com sess?es ativas.

Le XSS, cette menace sournoise qui peut transformer un simple commentaire en porteur de chaos sur le web! ???♂? En adoptant des pratiques de programmation sécurisées, comme l'utilisation de fonctions d'encodage ou de filtrage de sortie, nous renfor?ons nos défenses contre les attaques XSS. Ensemble, protégeons nos applications web et offrons une expérience en ligne s?re pour tous! ??

Make sure to use new token for every request & server validates it before while using GET/PUT/POST as stale or reusing old token can be used by hackers to POST data which can mess integrity of data.

Most of the applications are tested with minimum data, so operations can be performed with the cpu power, but with huge data will be fail, so I recommend create test enviroment assuming that your applications is managing a huge data. Have a good programming!!!

One aspect of the integer overflow can also happen in loop statement resulting unconditional loop like behaviour. Ensure that the signed and size of loop variable is the same as the value which is checked in the loop condition. Effective unit testing and code quality tool can help avoid/resolve these situations

A program is not just the code, but it's also the environment it runs within and the architecture it runs on. Not all integer are the same across architectures, so code that works fine in one place, may break in another, and be wasteful somewhere else. Check your language's limits. Be aware that max unsigned integer is larger than the max signed integer. Wrapping over that value behaves differently for each. Be careful when comparing signed and unsigned types, you may need to promote them. Watch out when serializing and deserializing values. Overflows can happen with bit operations, too. Some languages use part of an integer representation value for flags, making their usable values smaller than the number of bits seem to allow.

O estouro de número inteiro é um erro comum em linguagens de programa??o que ocorre quando um valor inteiro excede o limite máximo ou mínimo que pode ser representado pelo tipo de dados em quest?o

Efectivamente esto es un error que tiene mucha importancia y que además se presenta comúnmente. Este desbordamiento incluso compromete el dise?o puesto que se ve afectada la visualización y en algunos casos deja expuesto parte del código, lo cual es una puerta abierta para los ataques. De allí la necesidad imperante de utilizar adecuadamente los tipos de datos en base a las proyecciones de uso del sistema y la implementación de mecanismos para controlar estas condiciones.

Using locks and semaphores, all over the place to prevent race conditions is often a sign of poorly designed code. Look at using a framework that forces you into a pattern that minimizes this. Also look to never share mutable state between threads. 99% of developers who think they know what they are doing when they do this really don't.

In Concurrent programming in Golang, I recall using locks to overcome race conditions. When a process accesses a resource, the program immediately locks the resource so another process cannot access the same resource while read/write is occurring in the first process. For example, if one process is using a global array variable, the program locks access, then the second process must wait until the first process has unlocked the array.

Race conditions are the sneakiest of the errors that find their way in the code. Often, programs that start small are written with a linear flow of control in mind. When such programs evolve into big applications, shared data such as configs, status queues, etc run the risk of being modified by multiple threads simultaneously. It can inadvertently result in leakage/loss of sensitive data.

Of course, using locks and semaphores is crucial, but we also need to design systems to minimize wait times and dependencies. I've seen developers set up thousands of independent schedulers for specific tasks, leading to a huge increase in RAM and CPU usage, causing the entire service to halt. We implemented smart scheduling and bundled tasks to reduce dependencies, improving overall performance. By minimizing lock contention, optimizing resource usage, and efficiently managing tasks, we can prevent race conditions without overwhelming system resources. Proper system design is as important as synchronization mechanisms in achieving robust and efficient concurrency.

Concurrent and asynchronous programming are always referred as a good way to improve performance, but it leads to a change in the overall programming paradigm and system design, which increases the possibility of critical bugs and data loss/leakage among shared resources.

Hard coding secrets and tokens like passwords and api keys etc. Opens up the code being vulnerable to be exploited and attacked. Other typical exploitation is by using Eval function where the dynamic evaluation can be used by the actor to execute and control a part of the code. Example would be expecting input in dynamic eval in code and the actor is able to execute a custom url in place of a expected string in Eval(). Typically open up and used to happen in PHP dynamic eval.

An often overlooked source of potential security issues lies in logs, especially in dynamic languages like Python and JavaScript. You can inadvertently expose sensitive information without knowing. Always remember to log the minimum like just an object property vs a log with the full object.

Stop thinking, " It will never happen!" Better ask yourself, " What is the worst that could happen in my code? ". We code with the "good" path in mind, with some fail-safes here and there, but we never code with the mindset of preventing the worst from happening. Robotic industries, for example, don't wait for a value to be true. They wait for a sequence of values to be true. You only stop at a sensor's bool if you have seen the bools of the previous sensors. It's another way of programming. Ladder or contact language and Grafcet are different ways of programming. All your lines of code are executed in each frame. There is no stack. And it allows some form of safe multithreaded state machine.

Apart from Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), the most common issues are the failure to patch or update libraries, along with excessive focus on data logging and handling of sensitive data on log files.

Code repetition is a basic but still common seen error. Just by following some basic OOP guidelines and a few simple design patterns, one can have a modular software easier to debug, refactor, add features and guarantee a great uptime on production! In the other hand, always remember the KISS principle!