Answer yes if your organisation ensures that all of its applications have data validation implemented on their data inputs and outputs.
What is it?
There are several varieties of attacks that depend on applications not always adequately validating data inputs from input fields. Sometimes an application will accept input that is too long for the receiving buffer it is using to store that input, potentially allowing someone to have malicious code or commands “overflow” into application or system memory where it can be pushed to the system and executed.
Other attacks, such as SQL injection, rely on the fact that input can be interpreted in unexpected ways. This can happen when an application doesn’t filter and accidentally interprets what are known as escape characters. In such cases, what should be handled as a static string is actually interpreted as a command and executed, allowing attackers to trick applications into outputting information they should not, or even to trick them into modify data on the system.
Why should I have it?
Since the buffer overflow and injection conditions as described above can potentially allow any attacker to read from and write to the system with the same elevated permissions as the application itself, it’s essential to prevent them from being introduced in your applications. The primary way of doing this is by validating input.
Naturally, any vulnerabilities in software apply to the individuals/clients running copies of the software within their organisation or using the software as a hosted service (like any web-hosted application) and can place their data and security at risk.
Having input (and output) validation be a prominent part of your secure SDLC strategy not only helps reduce vulnerabilities and risk, but also answers a significant security concern your clients may have.
As with all elements of secure software development, input and output validation should be part of your developer training, code review, and automated code testing.
Being such a critical part of software security, all inputs and outputs (which often act as inputs later on) should be specifically mapped out and assessed to ensure nothing can be injected, modified, or extracted from the application’s intended data flow as part of your software architecture/design.
There are numerous consultancies or individual consultants that will be able to assist in crafting a policy and implementing an SDLC that includes security best practice in a way that meets your business and technical requirements. Please message us if you would like a recommendation.
If you would like to contribute to this article or provide feedback, please email firstname.lastname@example.org. Contributors will be recognised on our contributors page.
Please do not submit your answer on the knowledge base.