Developers work towards solving specific issues and since programming is a skill used in many industries, this means there are a lot of developers who are designing and creating solutions/applications.
A challenge faced by developers when writing secure software is the vast amount of tutorials available on the internet. These tutorials successfully demonstrate how to perform a specific activity, for example, retrieving data from a database, but do not implement any type of security when doing so. The issue here is a lack of skills – since these tutorials do not show how to successfully implement security measures, developers tend to learn bad practices when it comes to designing and creating software solutions.
Another challenge developers may face is a lack of time. Developers tend to design and program according to different models of software development life cycles (SDLC) and these models emphasise design, implementation and testing. Security is often added on as an afterthought or when these applications are hacked – this can be easily solved by emphasising the importance of security at every stage of the process.
I have therefore created the following 5 recommendations I believe developers should keep in mind when creating software solutions.
Avoid User Input
This is the best advice for a software developer, however, nearly all applications will require user input at some point. This means we must implement strict input validation rules to ensure the user input is in the format we expect. The main risks of not implementing input validation
from a technical point of view are being susceptible to cross-site scripting (XSS) attacks and SQL injection attacks. This is also something software developers need to be aware of due to the use of variables and the way user input is used within an application. Developers may only be thinking about how the application should function however attackers are thinking about how to crash programs, execute arbitrary code or obtain sensitive information. For example, when asking the user for the amount of money they would like to transfer, it is important this input is validated as a number and not a string since we cannot perform math operations on text and this is likely to break our system.
Avoid Access Control
My second recommendation would be to avoid implementing access control if possible. Developers implementing their own access control have many different scenarios to think about as well as how the data should be stored. This should be avoided at all costs and off-loaded to a third party such as Google or Facebook who spend vast amounts of money keeping their systems secure. In the event a developer needs to create their own access control, I would recommend re-using freely available code which follow good security practices (do not re-invent the wheel).
Protect Against File Uploads
File uploads represent a significant risk for the security of an application and developers must always be aware of this. Uploaded files could be malicious code designed to be run by the system to perform some arbitrary action eg browse local resources, attack other servers or exploit local
vulnerabilities. The best advice would be to avoid file uploads if possible however there are a few methods for reducing this risk. If the developer is expecting an image to be uploaded, the script could check the mime type of the file to verify the image type; performing a simple extension check is not sufficient. The first level of checks should inspect the file extension (in this case PNG, JPEG etc) and the second level of checks could check the mime type of the image. It is also very important the file name is checked as it may contain special characters which may cause issues within the script or more importantly on the system.
Protect Against SQL Injection
SQL Injection attacks are very common due to the countless number of SQL injection vulnerabilities and high-value targets (database). SQL Injection attacks can potentially expose an entire database to an attacker and since these databases generally contain all information in relation to the application this makes it a very high-level target. There are many ways to protect against this type of attack but the easiest solution is to use prepared statements with parameterized queries. Prepared statements tell the SQL database what to treat the user input as, eg String, Integer, Float etc. Parametrized queries can be utilised by first defining the SQL query, and then pass in each parameter to the query later. Some additional defences include enforcing least privilege or performing white list input validation as a secondary defence.
Enable Logging
This data is invaluable for identifying security incidents, monitoring policy violations, providing information about problems and identifying unusual behaviour. System-wide logs (apache, PHP etc) are very useful however the application has the most information about the user and the context of an event. Log data should be kept in a secure location, ideally not in the same location as the software being run since if this is exploited, the log data could be compromised. Types of events that should be logged are input validation failures (eg unsupported encoding), output validation failures (eg database), authentication events (eg failure or success) and session management failures (eg cookie session/PHP session mismatch). These log entries should include sufficient information such as when (date/time), where (what point in the application), who (machine user or human) and what (type of event & severity). These events will greatly help identify potential issues and the different types of attacks being used.
Note: This post was written towards the latter part of 2020 – I forgot to hit the publish button!