DEV Community

Cover image for Threats Driven - Web Applications Security, Part 2
Leonardo Felicissimo
Leonardo Felicissimo

Posted on

Threats Driven - Web Applications Security, Part 2

In the previous article I've started writing a quite about why I'm currently studying about Securing Web Applications. Now moving on, I'm going to deeper to the theme starting from the STRIDE Microsoft Model and exploring the Basic Security Design Principles from a paper of 1975 published by John H. Saltzer at MIT.

Sometimes when building an application, we think the only way to make it secure is to avoid hackers attack and this is not for devs, but a job for the operations team. Let's talk the true here (secure env). Which words come on your mind when you think about security? Password and Hackers (right?).

But, the process of secure an application starts when we firstly get an answer to the question: What might we fighting against?

The propose of Saltzer's paper is explore "the mechanics of protecting computer-stored information from unauthorized use or modification". Saltzer goes from the basic security design principles to state of art. The funny thing is that the points from the paper called as security basic principles, to me has sound like a WOW! (HHAHAH Jesus, what a gap I had!).

Once we have understood privacy protection and so, information security as the main security strategies objective, Saltzer helps giving a definition for the terms:

The words "privacy," "security," and "protection" are frequently used in connection with information-storing systems. Not all authors use these terms in the same way. This paper uses definitions commonly encountered in computer science literature.

The term "privacy" denotes a socially defined ability of an individual (or organization) to determine whether, when, and to whom personal (or organizational) information is to be released.

The term "security" describes techniques that control who may use or modify the computer or the information contained in it.

Saltzer propose a way of categorize the security issues in the following way:

Category Description
Unauthorized information release an unauthorized person is able to read and take advantage of information stored in the computer
Unauthorized information modification an unauthorized person is able to make changes in stored information--a form of sabotage
Unauthorized denial of use an intruder can prevent an authorized user from referring to or modifying information

I remember in older professional experience where a teammate from Infosec team has schedule a series of meetings related to Threat Modeling. And at least for me at the time it was awesome. Instead of built something based on basic security patterns familiar to us or accounting with what the framework have out of the box, the challenge was to built an architecture considering a couple of security threats from start.

For this, Microsoft propose a model called STRIDE a acronym that helps to organize the known threats in categories:

Category Description
Spoofing Illegal access and using of username and password for example
Tampering Malicious modification of data. For example, unauthorized changes to a database
Repudiation A weakness related to a lack of criptography and traceability of a transaction between two parties. One of parties deny has performed an action and the system is unabled to proof the integrity (I confess. It was being a challenge try to explain this part. Feel free to help me on comments! :D)
Information Disclosure Users accessing information on resources that they are not granted to access to, or steal information sniffing the traffic
Denial of Service Causes a fall down to a web app, forcing it to be unavailable
Elevation of Privilege When a user that doesn't have access to a resource break the deny and gain the access to using some way. SQL Injection for example.

Well, seeing the table and when we do a research about the them, seems that all involves the application data. At the end, all our security strategies have a single one objective, protect the user privacy prevent not authorized access to information.

Then, the conclusion at this moment is that if we want design a architecture considering security efforts we shouldn't just thinking on what to do or to use to avoid unauthorized access, but how to prevent from threats modeling security strategies since at start of architectural decisions.

Before of thinking the main structure of application and how should be the design patterns to use, or how are the test cases, design how should we use or plan for grant that this new API is safe from security threats?

In many projects we start building things doing the possible for see faster the database result returned on a http request or in a screen. The challenge when we start to consider a secure app, is start answering: How are the possible threats related to that we are going to build?

Concluding with Saltzer's words:

The objective of a secure system is to prevent all unauthorized use of information, a negative kind of requirement. It is hard to prove that this negative requirement has been achieved, for one must demonstrate that every possible threat has been anticipated. Thus an expansive view of the problem is most appropriate to help ensure that no gaps appear in the strategy. In contrast, a narrow concentration on protection mechanisms, especially those logically impossible to defeat, may lead to false confidence in the system as a whole.

In the next part I want to share the Security Basic Principles propose by Saltzer.

See ya!

Top comments (0)