21–30 of 131 posts
Earlier quoted context omitted.
Our industry is ageist and anti-intellectual. These are the symptoms of those.
Maybe not ageist, but I do think it's easier to get younger people to work slavishly and pay them relatively less (on average, not everywhere pays like Bay area).
Here are Language-Specific ones: 1. CWE-787 Out-of-bounds Write: C, C++, Assembly 4. CWE-416 Use After Free: C, C++ 7. CWE-125 Out-of-bounds Read: C, C++ 10. CWE-434 Unrestricted Upload of File with Dangerous Type: ASP.NET, PHP, Class: Not Language-Specific 12. CWE-476 NULL Pointer Dereference: C, C++, Java, C#, Go 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript 17. CWE-119 Improper…
Escaping by default has become a standard practice with HTML templating languages, see the Go html template standard library for a very detailed breakdown of what is escaped where.
More modern PHP frameworks like Laravel provide their own templating solution in part because of this. But the vast majority of websites run on default PHP templates, so it's not surprising that these kinds of vulnerabilities are so high up in the list.
Earlier quoted context omitted.
"But modern c++ is safe, preventing all those errors is as easy as not making them!..."
Is there some authoritative source for what is considered modern C++ and what is old? Most projects I've seen use a wide mix of C++ features of varying age. If you use some C++23 futures it would not make it modern if you still use C++98 features you not supposed to use.
It's somewhat similar to the C/C++ split. When it is convenient it's "C/C++" because "you can easily migrate your old C codebase to C++". But in other situations it's "C++", because C is old and more error prone and "we no longer manipulate raw pointers".
Thank god Spring dropped this interface in the Framework 6.x / Boot 3.x release, and the end for non-commercial support is this year for the old stuff.
https://github.com/spring-projects/spring-framework/issues/2... https://github.com/advisories/GHSA-4wrc-f8pq-fpqp
It's somewhat disheartening as a software developer focused on security that the top four elements are still: * Out-of-bounds Write * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') * Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') * Use After Free
The gap from knowing what a CWE is and actually knowing, on code level, how it manifests and how you avoid these things is very large. Given how much the software industry has grown in the past 10 years it's not particularly surprising.
Actually the SQL one is arguably in that category too, to a lesser extent. Libraries could, and should, make it obvious how to do parametrized SQL queries in your language. I would guess that for every extra minute of their day a programmer in your language must spend to get the parametrized version to work over just lazy string mangling, you're significantly adding to the resulting vulnerability count because some of them won't bother.
Bonus points if your example code, which people will copy-paste, just uses a fixed query string because it was only an example and surely they'll change that.
Earlier quoted context omitted.
How many of these rust can solve? (Not in use rust for everything bandwagon, genuinely curious)
2 of the 4 listed.
It's somewhat disheartening as a software developer focused on security that the top four elements are still: * Out-of-bounds Write * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') * Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') * Use After Free
Our industry is ageist and anti-intellectual. These are the symptoms of those.
Here are Language-Specific ones: 1. CWE-787 Out-of-bounds Write: C, C++, Assembly 4. CWE-416 Use After Free: C, C++ 7. CWE-125 Out-of-bounds Read: C, C++ 10. CWE-434 Unrestricted Upload of File with Dangerous Type: ASP.NET, PHP, Class: Not Language-Specific 12. CWE-476 NULL Pointer Dereference: C, C++, Java, C#, Go 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript 17. CWE-119 Improper…
PHP is uniquely vulnerable to things like XSS and others on that list, because it does escape strings that are used in templating. Escaping by default has become a standard practice with HTML templating languages, see the Go html template standard library for a very detailed breakdown of what is escaped where. More modern PHP frameworks like Laravel provide their own templating solution in part because of this. But t…
The whole problem is that you mix code and data, and that third party resource loading is 'on' by default in browsers, especially for scripts and things that can embed scripts. This is not something you can fix once and for all at the library level.
Here are Language-Specific ones: 1. CWE-787 Out-of-bounds Write: C, C++, Assembly 4. CWE-416 Use After Free: C, C++ 7. CWE-125 Out-of-bounds Read: C, C++ 10. CWE-434 Unrestricted Upload of File with Dangerous Type: ASP.NET, PHP, Class: Not Language-Specific 12. CWE-476 NULL Pointer Dereference: C, C++, Java, C#, Go 15. CWE-502 Deserialization of Untrusted Data: Java, Ruby, PHP, Python, JavaScript 17. CWE-119 Improper…
In java you'll get an exception, while in C you might dissapear your cat. Those 2 are quite incomparable when talking about "dangerous-ness" of a mistake
It's somewhat disheartening as a software developer focused on security that the top four elements are still: * Out-of-bounds Write * Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') * Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') * Use After Free