Security is a serious concern for every web application developer, or at least this is what we like to think every time we use our credit card and give personal details on an online form.
Still, security breaches occur frequently on a wide range of web applications and involve an ever-growing number of users. This may be symptomatic of a general lack of awareness and attention to safety related issues.
This consideration was the starting point of the interesting speech held by Natalia Oskina and Giovanni Asproni, IT consultants for Zuhlke Engineering Ltd, at Codemotion 2018 in Milan, on the best practices to build modern and secure web applications.
Sad but true, in many development projects the fulfillment of security requirements lags behind the implementation of new features, bug fixing and the renewal of marketing strategies.
In other words, safety-first rarely applies to ordinary development cycles and security is usually conceived as an extra feature, instead of being the foundation of design and DevOps methodologies.
It’s not a surprise then, that the actual implementation of GDPR and NIS regulations, recently enacted in the European Union, is a serious problem for many web service providers.
As Oskina and Asproni pointed out, security related issues are indeed the most difficult to solve, especially by means of retrofitting at an advanced stage of development. When that’s the case, sealing security holes can be an expensive and long-running task, without taking into account the reputational damage that can result from a security breach.
Since retrofitting is not a winning strategy, security must be a primary concern from the design stage.
We should be thinking of security as a quality, not as a software feature.
This practically means that the implementation of security is not necessarily just a matter of skills, it is primarily related to the attitude of the people involved in the project.
On a practical level, tuning our mindset on safety concerns requires the definition of a threat model tailored to the domain of the application. Unlike an external attacker, when we think about the potential weaknesses of our own system we benefit from our knowledge on its inner workings. In other words, risk assessment is easier if we focus on safety issues while we define our business logic, rather than in the aftermath.
In this respect, the STRIDE model developed at Microsoft outlines the most common types of threats that will eventually plague any system exposed to web access: Spoofing of user identity, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege.
One way to stem potential threats falling in the STRIDE taxonomy consists in the integration of risk management directly into agile development methodologies under the forms of user stories. Since stories are commonly used to express functional requirements in a conversational form by users, they could also focus on safety concerns rather than software features.
Ideally, in this scenario, one or more stakeholders should act as security guards that analyze the entry points and the assets that are interested by every functionality to assess the trust levels and the boundaries for any user activity in terms of what a user can and cannot do, under the assumption that every user can be an attacker.
The use of dedicated tools like the Microsoft Threat Modeling Tool can effectively support this analysis through the use of diagrams that model user activities. These tools engage designers and developers into a cyclic revision activity providing automatic threat identification based on STRIDE, suggesting the most appropriate countermeasures.
Another practical approach consists in the definition of attack trees. These are a schematic representation of threats that can help in the identification of vulnerabilities in the infrastructure or in the business logic. The root of the tree is the malicious goal and its branches constitute viable paths that flow from the normal interaction between the users and the system.
Whatever strategy is pursued, the integration of security management will of course have an impact on development. On the other hand, it is also true that many different threats are automatically mitigated by the adoption of general guidelines like the use of encryption techniques to ensure data protection and the adoption of HTTPS in favor HTTP. Spanning these requirements transversely to the implementation of every feature can scale down security concerns dramatically.
Aside from this, Oskina and Asproni warned about the subtle threats that are not strictly related to implementation. An important role in security is indeed the definition of proper DevOps practices, like the enforcement of control policies to rule the access to crucial resources like the sources repository, which are normally not exposed to the external environment, but can be used to pursue an attack from within the boundaries of the infrastructure.
Finally, Oskina and Asproni stressed the importance of setting priorities for the implementation of security constraints based on a cost-benefit analysis. The practical advice is to start from changes that require minimal effort yet have a big impact on the overall security level, e.g. switching to HTTPS. Only after this step should the attention be drawn on average effort tasks that apply to specific scenarios, since they occur less often.