I have this nasty habit of committing to teach things. Things I probably have no business teaching, but I find that lighting the fire motivates me to learn quickly. Earlier this week, I had an opportunity to share some of what I learned about how to describe web applications from a security standpoint. I had gone through this learning process sometime before, but with all of the craze around cloud, native and different XaaS offerings, I thought it would be a great time to refresh my knowledge and then pass a little bit of that on. My end goal was to teach security minded folks what makes a web application different than other parts of an attack surface. Whoops!
When we talk about web applications, most of us have ideas as to what those might be. But if we step back and think more broadly, the concepts of web applications are even more applicable to our daily lives. The same concepts are behind mobile applications, modern control & management architectures, and fields like automation and OT. API equipped solutions, for instance, leverage a form of HTTP messages to communicate. Almost any application on an iPhone or Android device is actually just a customized browser and UX, relying on a server somewhere else.
So what makes Web Applications different?
We get very used to talking about data center and network architectures based on how the infrastructure is plumbed. In a web application, what became very clear to me, was how many different ways someone might characterize that applications architecture. I think this is one of the most exciting, but confusing aspects of this area for me, so, with no illusions of mastery, I thought it might be great to share what weāve covered so far here. We will, soon enough š
Technology aside, there is another fundamental difference of these applications that leverage web technology. When we talk about defending networks and points, we are talking about things we’d rather not welcome outside interaction with. Web applications are different. Applications are designed to serve outside users. When you deploy a web portal, or expose an API, or publish a mobile application, all of these are being positioned, to serve an end user who is not local to that application. This greatly influences how it is, that a tester or adversary might approach attacking an application.
So how do we describe web applications from a security standpoint? What are we dealing with?
Describing Applications based on how Users experience them
One of the simplest ways to characterize an application (even for adversaries) is to think about how they present themselves to their intended audience. Think about what you see and experience when interacting with your favorites! You might find that they call into a couple of categories. Other applications may never see the light of day with you, but instead show themselves to their users – other applications! We might see them categorized like this:
- Single Page Application (Gmail or Google Maps): Whenever something changes, app dynamically rewrites the current page rather than loading entire new pages from the server.
- Multi-Page Application (Amazon.com): Every time a user requests a new piece of data or submits data, the server renders a new page and sends it to the browser.
- Microservices Architecture (Netflix or Webex): The application is a suite of small services, each running its own process and communicating via lightweight mechanisms.
- Serverless Architecture (AWS Lambda): Not usually a stand-alone app, but here the cloud provider dynamically manages the allocation of machine resources.
- Monolithic Architecture (WordPress): A monolithic app is self-contained; its components are interconnected and interdependent and usually taken as a whole.
The extremes of experience
How exactly does a User experience a Microservice Architecture? Arguably, Netflix can be shown in a couple of these categories. But it is important to show that users have zero concept of just how fluidly Netflix manages its scale to meet demand. That is a testament to how awesome their architecture is, and it follows that it probably has a huge impact on how its users feel about it!
Contrast that with something like Microsoft Access – if you’ve ever used that monolithic application, you have felt pain. Both the user experience and the maintenance became unruly, and are a large reason I chickened out of ever learning about databases. Mores the pity!
Describing applications based on their architecture
Back to that Microservices bit – that term can also be a shorthand for how an application is actually developed. While it is relatively new, there are other architectures that are still out there! Most folks learn on a simple, single-tier approach, but quickly move to a multi-tiered architecture. Why do they do that? Well, that segmentation of functionality just makes good sense. Modularity offers flexibility. Database getting unwieldy? Slap on a more scalable, high-performing one. Outgrowing the capabilities of your application stack? Scale that out and maybe even load balance! Each of those divisions in functionality ALSO offer opportunities to secure something! You can place Web Application Firewalls in there, or bake in input validation. You might even use ACLs to prevent tiers from communicating. Some of the common design models or approaches are shown below:
Microservice-based architectures take that modularity to new heights. Usually using a mix of highly-specialized containers in an elastic, automatically scaled fabric, applications can quickly ramp up the number of instances of any function in order to support the increased demand or respond to issues. Heck, if they do this well, they are even deploying updated containers while operating, with zero downtime!
That is a strange snowflake!
The odd-ball here is the Model-View-Controller approach. This one is included mostly because it defies the others. Why does it exist? In this case, the application developers are following a pretty prescriptive approach for gaining modularity through grouping functions for the presentation of the app (View) separately from the input functions (Controller) and the logic/state machine (Model) of the application. Why would we do this? If I grasp this right, this sort of model allows an application to mix and match for multiple uses at once. An example might be a multi-platform game. The same game might be available on iOS, Android, PC, Playstation, etc. And while the Model would be the same (allowing cross-platform support) each needs different Control and View work to make it possible. Make sense?
Describing applications based on their tech stack
Chances are you have learned something about web applications before. Most of us who have taken a basic programming course or faked it while regurgitating StackOverflow’s wisdom have even seen some of the underlying tech mentioned before! A tech stack is a combination of the services or languages that an application is build on. What is in a stack? Most applications need a database or some way of storing information. Presenting the information to the user is usually important too. You might also find that there is an operating system, a server tech, or something like that in there too.
Serverless applications are just there to make a liar out of me. In an effort to scale even faster and make stuff happen even cheaper, what could be cheaper than skipping a server workload altogether? Serverless (AWS Lambda, Azure Functions, etc.) offer the premise of not even having to have an always-on workload running. When you need some work performed, you can send it to one of these services which process and return it back to you lickety-split! You only pay for the nanoseconds of CPU time required.
When we describe web applications from a security standpoint, it helps both Red and Blue teams. Adversaries what to know what sorts of vulnerabilities are possible to exploit. Defenders need to know which vulnerabilities to patch and block. The underlying technology of an application influences that heavily. The great Log4j scare of 2021, for instance, exposed just how dependent applications of ALL shapes and sizes were dependent on Java libraries maintained by volunteers. Python’s package manager, Pip, is able to draw from reusable packages that have been recently poisoned with malicious code. Almost every database underlying any tech stack has had its own issues.
Describing the snowflakes
Science shows that every snowflake is unique. We use the name in technology to mock the supposition that an application or architecture is so unique that it requires special care and accommodation. But just because each has its own uniqueness does not mean there isn’t a way to describe it and understand it. In snow, they talk about how humidity and temperature tends to influence the shape and size of a flake. You’ll get needles, columns, disks and dendrites, just in different combinations and sizes. The same can be said when you describe web applications from a security standpoint. There is no application that is an exact copy of Amazon, Neflix, or Angry Birds. But with the descriptions above, you can certainly find similarities and use those to help understand what makes them tick, threatens them, and is needed to secure them.
Mike