Are injection vulnerabilities mainly a design or an implementation problem? I'm using SQL injection as an example; I'm interested in other injection vulnerabilities as well.
I believe that it is the direct consequence of lazy programming, i.e.
Some people say it is mainly a design flaw but I cannot figure out why.
This can be both, but the main responsibility for such problems is design.
Independent on design, if developer is not forced to create a code that is vulnerable to SQL injection, but still creates it, it is an implementation problem. It means, developer either does not understand the problem, or understand but doesn't want to create a code that is resistant to it.
If there is a design decision to use native SQL or HQL or JPQL or similar instead of prepared statement (in Java), or some DSL or similar technique, such decision makes it easy to get SQL injection problems in the code. Resistance to SQL injection is not a primary goal of prepared statements, bu rather a positive side effect. Nevertheless, a design decision to allow native SQL means a design problem.
If there is no explicit design decision regarding native SQL, then developers have no explicit guideline regarding implementation of data access layer and, if they are not experienced enough, do easily such mistakes and create code vulnerable to SQL injection. Means, no decision about plain SQL is again bad design because it does not address such important aspect.
Injections like SQL injection, XSS, etc are possible due to the possible combination of code and data within the same string and because developers construct such strings using untrusted and insufficiently validated user input.
The possibility to mix code and data inside the same string is deep in the design of SQL, HTML+Javascript, ... This is similar to memory pages in the computer being readable, writable and executable at the same time - which was common for a long time but now one tries to clearly separate code (executable) and data (readable, writable) in memory. Thus one might call mixing code and data in a string already a design problem, especially since in many cases it would have been possible to create a design with a clear separation of code and data.
But one might also point out that in many cases methods exist to construct a safe code+data string using functions which have clearly separated code and data as input, for example parameter binding for SQL statements. Therefore one might argue that not using such functions is design problem in the application. Not offering such functions in some cases would be a design problem of the used framework instead.
Such design problems then lead to implementation problems. In theory it would be possible to construct a safe code+data string without the help of the safety functions like parameter bindings, since one would "only" need to do a proper escaping and quoting. Doing this improperly is thus an implementation error.
Given a competent software architect, I would say the biggest issue tends to be implementation, and more specifically individuals that lack knowledge and training about secure coding best practice.
To qualify this short answer, I will contrast with design and show that design covers a broad space, some design is prescribed and defined by others, the rest, you can define.
Here are all of the layers to consider, starting at the end with the coder:
Industry Expectations are the habits, truths, misconceptions, hype, and customer perceptions that influence both software developers and their customers. This is largely prescribed design.
Frameworks [4] are generally influenced by Industry expectations and Norms[5], but over time it feeds back the other way: new frameworks are built with new ideas (sometimes security-focused) to improve Industry Expectations and Norms [5]. One example of a new framework: Google Firebase FireStore lets a mobile app define a query directly on the client-side, then the framework takes care of serialization and remote execution on the database; security occurs with javascript security files on the server that are quite flexible, and a security analyst can review those and spot any problems quite rapidly. This is also prescribed design.
System Architecture [3] is often prepared with [4] and [5] in mind. The decision to build a RESTFul API service (framework) is based on a Software Architecture decision [3] and constrained to the way that the framework [4] is designed to work. A more secure system architecture choice might be GraphQL, because RESTFul API require more manual coding with the usual human-error issues.
System architecture [3] is also broader than just software architecture. It chooses the right frameworks [4] as well as the software stack and hosting systems to build a solution. Choosing a little-known framework with a small developer community means there is low scrutiny and no time-tested maturity. Choosing a small Virtual Machine hosting provider with no published security practices can be a big liability.
I treat design [2] as a distinct item to System Architecture [3], Frameworks [4], and Industry Expectations [5]. Design is less about the system, and more about the customer's requirements, usually in a data-centric way. I say data-centric, because security is ultimately implemented around authorization and access to particular data, so an authorization-conscious design of the data model can improve security outcomes. So while implementation might be critical, this level of design is something you can control and can fail.
Finally, implementation [1] is well represented in the answers here already. Software coders should know their craft, and take designs [2] and write code using secure patterns. If after all of the above, there is still a security failure, perhaps it's a knowledge and training issue, because software coders should be following the "plans" in a best practice manner, not freestyling.
