4 ms·

Most Dangerous Software Weaknesses

wiz21c 5y ago
I bet it'll be the same in 2030 :-)
- getaclue 5y ago
  Shh too busy coding to read pitfalls XD
- marcosdumay 5y ago
  I hope by 2030 the C-only ones are lower than the top of the list, and trending down instead of up.
  - wongarsu 5y ago
    I don't know. Microsoft has been pushing for safer languages (most famously C#) as well as static verification where that's not viable (kernel drivers) for well over a decade, along with the prevalence of Java in Enterprise Software, and we still have out-of-bounds read/write and use after free in the top 10. If you write new software these C-isms seem easy to avoid, especially with Rust as another compelling option. But I doubt that makes a big dent on the statistics in the next decade.
- TroisM 5y ago
  They must be thinking in terms of job security...
wongarsu 5y ago
It's interesting how top-heavy the distribution is. The top 5 make up half the total score of the top 25. The top 2 make one third of the total score of the top 25. I wonder if this shows we can get outsized impact by focusing on just a couple of types of issues, or if it is an artifact of how the data is collected (e.g. out-of-bounds write is easy to find by fuzzing but severe enough to always warrant a CVE)
alanfranz 5y ago
One fundamental thing, in my opinion, revolves around the concept of "validation". Sometimes I see vulnerability assessment reports that claim some vulnerability was introduced by "insufficient validation" or "improper validation" or something like that. Most of the times (let's exclude embedded/iot which can be different, I'm talking about "classical" web applications or API backends) you don't need to validate arbitrary data. You need to use the proper API to handle such data. If an input string contains '); DROP TABLE Students; -- you don't need to "sanitize" the string. You just need to use the proper function (usually provided by your db driver), and it will quote it for you. There's no input that can create a SQL injection. Similarly, when you output something for the web, always use a context-aware templating engine (e.g. Thymeleaf) so that the appropriate escaping function is used when rendering an HTML element, javascript, an attribute, whatever. XSS is impossible, unless "unsafe" functions (those that dump the raw string into the text) are used. For sure, if any "active" content (not just an opaque string that needs to be rendered back somehow) is passed to the application (e.g. a direct reference to an object which may require an ACL to be visualized), then you need to "validate" the input. But it is very important to understand the difference between "validate something which is strictly related to your application logic" and "use the appropriate data manipulation functions for arbitrary data".
- wongarsu 5y ago
  However sometimes there are no good, safe APIs commonly available. Number 5 "OS Command Injection" and Number 8 "Path Traversal" fall in that category. Both are exercises in proper quoting (and in the case of Path Traversal also catching ways to leave the intended base directory). If sane OS APIs for these cases exist at all they are platform-specific, so most languages go with the unsecure platform-agnostic way and provide only rudimentary wrappers that don't solve these problems either.
  - alanfranz 5y ago
    You're right that some APIs just suck. But it's important to recognize that the problem exists. If you notice that you can't perform an action safely, and there's an injection risk, you can usually try and find a safe way that doesn't involve an error-prone approach. Example for the path traversal: generate a filename within the app, and save the original name somewhere. For command injection, it is more variegated. But resorting to launching an external command (rather than an API in the language you're using) should be a niche requirement, not the standard way to go.
cxcorp 5y ago
I find it interesting that XSS has been in the top 5 since the first Top 25 to include a table with ranks in 2010 (archive: https://cwe.mitre.org/top25/archive/ https://cwe.mitre.org/top25/archive/). I know Content Security Policy can help mitigate XSS, but I wonder if there are any existing tools to help you discover what kind of rules your website would need currently to even function as intended?

I bet it'll be the same in 2030 :-)

getaclue 5y ago
Shh too busy coding to read pitfalls XD
marcosdumay 5y ago
I hope by 2030 the C-only ones are lower than the top of the list, and trending down instead of up.
- wongarsu 5y ago
  I don't know. Microsoft has been pushing for safer languages (most famously C#) as well as static verification where that's not viable (kernel drivers) for well over a decade, along with the prevalence of Java in Enterprise Software, and we still have out-of-bounds read/write and use after free in the top 10. If you write new software these C-isms seem easy to avoid, especially with Rust as another compelling option. But I doubt that makes a big dent on the statistics in the next decade.
TroisM 5y ago
They must be thinking in terms of job security...

It's interesting how top-heavy the distribution is. The top 5 make up half the total score of the top 25. The top 2 make one third of the total score of the top 25. I wonder if this shows we can get outsized impact by focusing on just a couple of types of issues, or if it is an artifact of how the data is collected (e.g. out-of-bounds write is easy to find by fuzzing but severe enough to always warrant a CVE)

alanfranz 5y ago

One fundamental thing, in my opinion, revolves around the concept of "validation". Sometimes I see vulnerability assessment reports that claim some vulnerability was introduced by "insufficient validation" or "improper validation" or something like that. Most of the times (let's exclude embedded/iot which can be different, I'm talking about "classical" web applications or API backends) you don't need to validate arbitrary data. You need to use the proper API to handle such data. If an input string contains '); DROP TABLE Students; -- you don't need to "sanitize" the string. You just need to use the proper function (usually provided by your db driver), and it will quote it for you. There's no input that can create a SQL injection. Similarly, when you output something for the web, always use a context-aware templating engine (e.g. Thymeleaf) so that the appropriate escaping function is used when rendering an HTML element, javascript, an attribute, whatever. XSS is impossible, unless "unsafe" functions (those that dump the raw string into the text) are used. For sure, if any "active" content (not just an opaque string that needs to be rendered back somehow) is passed to the application (e.g. a direct reference to an object which may require an ACL to be visualized), then you need to "validate" the input. But it is very important to understand the difference between "validate something which is strictly related to your application logic" and "use the appropriate data manipulation functions for arbitrary data".

wongarsu 5y ago
However sometimes there are no good, safe APIs commonly available. Number 5 "OS Command Injection" and Number 8 "Path Traversal" fall in that category. Both are exercises in proper quoting (and in the case of Path Traversal also catching ways to leave the intended base directory). If sane OS APIs for these cases exist at all they are platform-specific, so most languages go with the unsecure platform-agnostic way and provide only rudimentary wrappers that don't solve these problems either.
- alanfranz 5y ago
  You're right that some APIs just suck. But it's important to recognize that the problem exists. If you notice that you can't perform an action safely, and there's an injection risk, you can usually try and find a safe way that doesn't involve an error-prone approach. Example for the path traversal: generate a filename within the app, and save the original name somewhere. For command injection, it is more variegated. But resorting to launching an external command (rather than an API in the language you're using) should be a niche requirement, not the standard way to go.

cxcorp 5y ago

I find it interesting that XSS has been in the top 5 since the first Top 25 to include a table with ranks in 2010 (archive: https://cwe.mitre.org/top25/archive/ https://cwe.mitre.org/top25/archive/). I know Content Security Policy can help mitigate XSS, but I wonder if there are any existing tools to help you discover what kind of rules your website would need currently to even function as intended?