IT teams need a complete view of risk and compliance to minimize risk exposure and satisfy their boards. IT Risk Management solutions automate IT compliance, assess cyber and IT risk posture, and inform business decision. Discover solution must-haves in the 2021 Gartner Magic Quadrant for IT Risk Management.
Download NowA plea for secure-by-default infrastructure software
By Richard Paul Hudson, CISSP
If a combination of road markings were consistently shown to confuse drivers, leading to avoidable accidents, the appropriate response would be to change them and repaint the road, rather than try to teach people to compensate for the poor markings. Yet in the world of application security, where the insecure default behavior of infrastructure software repeatedly causes developers to build vulnerabilities into their applications, the focus remains on education and increasing developer awareness rather than on fixing the road markings — in this case the broken tools.
Unlike drivers, junior programmers require no formal training before they start work. And while driving and programming both get easier with experience, the learning curve is far steeper when writing software. It is often so difficult to get early coding efforts to work at all that the novice developer has little regard for secondary requirements like security.
Looking back to early 1999, I was overjoyed to have finally got my first-ever application up and running; but it must have been riddled with SQL injection vulnerabilities of which I was blissfully unaware. Having tested my SQL statements in an interactive console, the most intuitive way for me to incorporate them into a program was to build up the query strings and execute them dynamically, mixing code and data.
In my defense (and that of my former employer), this was only a few weeks after SQL injection had first been described by Jeff Forristal, signing as rain.forest.puppy, in the Dec. 25, 1998, edition of Phrack Magazine. But more than two decades later, large numbers of unwitting developers still stumble down the same ill-fated cognitive path: SQL injection remains the most exploited web application vulnerability, accounting for 68% of attacks (https://www.akamai.com/de/de/multimedia/documents/state-of-the-internet/soti-security-phishing-for-finance-report-2021.pdf).
The crucial question, however, is not whether application developers should be better educated. Rather, it is why infrastructure software (programming languages, libraries, etc.) is still designed and documented in a way that leads new application developers to combine code and data within the same query string variable, especially when there is virtually never a good reason to do so.
A solution for SQL injection vulnerabilities
When writing a program (rather than working on an interactive console), it is preferable to use one variable for the SQL code with bindings to a second variable or variables for the parameter data. This is true even in the relatively rare cases where the code of the SQL query is itself built up dynamically by the program. The only conceivable situation in which a programmer would need to submit code and data within a single string would be where the program is itself realizing an interactive SQL console, which is an unusual requirement.
All relevant programming languages and frameworks allow SQL code and parameters to be kept separate, usually by using prepared statements. However, although embedding SQL into a program as a raw query should raise a sea of red flags, it is often both the default option and the option set out in examples for beginners. If only the Java method for running a raw query were called executeUnnecessarilyDangerousQuery rather than simply executeQuery and its official documentation (https://docs.oracle.com/en/java/javase/16/docs/api/java.sql/java/sql/Statement.html#executeQuery(java.lang.String)) contained some sort of warning. Then, the proportion of budding Java developers falling into the SQL injection trap would shrink dramatically.
Similar measures could be applied to any injection-based vulnerability class. Indeed, some front-end JavaScript frameworks like React stand out as already using alarming method names like dangerouslySetInnerHTML (https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml) to flag functionality at risk from cross-site scripting. And, going through the OWASP Top 10 (https://owasp.org/www-project-top-ten/), equally simple potential improvements come to mind for some other issue types. For example, insecure deserialization would occur much less frequently if deserialization methods required programmers to specify by default the data type or types they were expecting to receive over the wire.
A plan of action
Such basic steps are seldom taken because the developers of infrastructure software have a fundamentally different agenda from a security manager. They typically aim for elegance, versatility and usability. It is easy to see how these goals lead to infrastructure software exposing overly general methods that place an unnecessary security burden on the developer.
As the best infrastructure software is open source and freely available, no law could directly force it to become more secure. However, anyone developing any kind of publicly available software is ultimately motivated by its adoption and use. The most important users of infrastructure software include commercial enterprises, and if commercial enterprises were legally required to use only infrastructure software that is secure by default, its authors would soon start paying attention. Most software is published and used globally, but legislation in any major jurisdiction — perhaps the U.S., China or the EU — would probably be sufficient to improve things everywhere.
Such legislation could reference a certification that programming languages and infrastructure frameworks would need to obtain before companies were permitted to use them. To keep down costs and, hence, industry resistance, it’s imperative to set a strikingly low bar for any such certification. It would expressly not be appropriate for it to involve penetration testing, or in-depth source code analysis, or any sort of guarantee that software is secure. It would merely need to ensure that dangerous methods were named accordingly; that documented examples reflected good security practice; and that other low-hanging fruit received minimum attention. Over time, such measures, as simple as repainting road markings, would save organizations billions of dollars annually and make the online world a much safer place.
Richard Paul Hudson, CISSP, is located in Munich, Germany, where he works at the intersection of security, architecture and artificial intelligence, most recently for msg systems. He has written a book to introduce laypersons to the world of information security (http://mybook.to/cybertwists).