2021’s Most Dangerous Software Weaknesses скачать в хорошем качестве

2021’s Most Dangerous Software Weaknesses

2021’s Most Dangerous Software Weaknesses Mitre Corp. recently updated its list of the top 25 most dangerous software bugs, and it’s little surprise that a number of them have been on that list for years. The Common Weakness Enumeration (CWE) list represents vulnerabilities that have been widely known for years, yet are still being coded into software and being bypassed by testing. Both developers and testers presumably know better by now, but still keep making the same mistakes in building applications. We’ll review the vulnerabilities that seem to consistently make the top 25 list over the years. But first, how do these mistakes come about? There are a variety of reasons. In many cases, developers simply don’t have security at the tops of their minds as they are coding the application. Their primary goal is to get the business logic right. In cases where a particular algorithm doesn’t seem to be working right, developers have been known to turn off security restrictions until it behaved as expected. Developers lose face when their application has a logic bug, but not when there is a potential security vulnerability, because these are largely hidden until they are exploited. Testers have a more direct responsibility for ensuring applications are secure, but usually have limited tools and expertise for doing so. They are almost always testing code in isolation, often with no database, APIs or network. Without a way to look into memory, or create illegal commands, and interpret the results in terms of an attack, they are limited in their ability to identify security vulnerabilities. There is also still the overriding perception within technical groups that security is the responsibility of the IT production group, not necessarily of the developers. After all, IT has significant tooling to define and manage an application and network perimeter, such as firewalls and anti-malware, that is designed to protect the entire infrastructure. The focus on security in production often means that there is less of a focus in development and test. It’s all part of a culture where security vulnerabilities are largely hidden from view because they typically don’t affect the function of the application, until an attack succeeds and systems or data are lost. While it would be most effective to focus attention on security during the entire application lifecycle, it is still critical to be vigilant in production. Buffer/Memory Overruns Manipulating memory remains one of the most popular ways of attacking a system. If an attacker is in possession of a specific memory address within an executable application, he can use it to enter values or commands that exceed the size of that memory space. Once outside of the memory space, attackers can insert executable software, making it possible to take over a computer or raise permission levels. There are many ways of taking advantage of buffer and memory overruns for attacks. If developers haven’t limited variable lengths, an overrun can allow an attacker to write malicious code directly into application memory. At the very least, it’s possible to use this technique to interfere with application execution, causing it to crash or return incorrect results. SQL/Command Injection Many developers focus on making sure an application returns the desired result above all else. In some applications, one common way of doing this is to give all user queries administrative access to the database. While that often works, it has consequences. First, it opens up database administrative access to any application user. That means anyone who uses the application can use SQL commands to modify the database. Using SQL escape characters, attackers can enter SQL commands into the web interface and have them executed by the database. Second, it keeps the database connection open for all. It’s never logged out after each individual use. That means that you don’t have to be an authorized user to find an open database. That makes the integrity of your data questionable on an ongoing basis.