Application attacks stem from common coding vulnerabilities, insecure data handling, and weak protocol choices that leave software exposed to exploitation. Understanding how applications process and transmit data is foundational to recognizing and defending against these threats.
Application Attacks Overview
If you think about it, it's applications that really are the heart of why we have technology. It's applications that allow us to carry out different functions. Applications allow us to do our jobs better. They are what entertain us. It's what we do and use in our personal lives and our professional lives. But with all of that functionality comes vulnerabilities and attacks and risk, and so we need to know how to manage that.
Code, software, applications, programs are all similar terms, and they all kind of mean the same thing — although there are nuances and differences between each of those terms. Essentially, what an application is, is files on your computer that are running different programs. They're lines of code that tell the computer what to do and how to function.
So many of our applications are connected nowadays. That is, there's some sort of server that's running services on it and it's supplying services for a client, and the client machine has an app, and that app is getting services from one of those servers.
In order to access some services, we may need to install some sort of app. This is what we call client-based. If we have to install a client on the machine, or an app onto the machine, we call that client-based, versus agentless. Agentless means that we don't need a separate app, a specialized app, to run these services — that we will be able to utilize our machine to access those services directly.
Another thing to understand is client-side processing versus server-side processing. We could either run applications inside of the client and do the processing on the client, or we could do it on the server side.
Let me give a real basic example so we can understand what this processing looks like. Here we've got two data points. We've got a one and a two, and maybe that's being stored on the server. But what has happened is the client needs to be able to calculate something, and so makes a request to the server to do this calculation. So the 1 + 1 here is the calculation, and the answer is going to be three. The client really just needs to know this answer, three.
We can choose to do the processing locally on the server side, or send it to the client and have the client do the processing. If we do it on the server side, we would add these two together to come up with three and then send the client the three. If we do it on the server side, we would just send this data over there and the client could do the processing.
Once again, this is a real basic example, but essentially: where do we want to do the processing? There are pros and cons to either one. If the data is over on the client side, maybe they know this data right here. If it has to send that data to the server and then it comes back, that could be a slow process, and so we might want to choose the client side to improve the performance. Likewise, maybe the data exists on the server side over here — but not only that, the servers are really powerful, beefy servers and they can do lots of processing. Maybe then, from a performance standpoint, it's better to do it over here and then send the answer over there.
The other thing is from a security standpoint. If we want to conceal this data right here, the data points that we have, we may not want the end user to be able to see those data points, so doing that processing locally and then sending it over might be a little better. So there are advantages and disadvantages to where we process this information.
When we develop an application, there are certain consistent issues that come up very often. Let me just give an example here. We've got a username and password and somebody enters this information in — and it really could be just any type of data that's being entered. Let's say we just allow whatever to be entered into these fields. What happens is that if we just allow whatever to be entered in these fields, then it opens us up for some sort of injection attack, because it takes extra steps to code things in a way that makes us not susceptible to injection attacks. Injection attacks are very common. We would have to take precautionary steps in order to implement these fields in a correct way.
Just as an example here, you couldn't jump out of a helicopter and expect not to hit the ground hard unless you take certain precautions, like using a parachute to come down softly. It's the same type of thing: sometimes when we create applications, there are these common things that are just going to be a problem unless we take those precautionary steps. Unless we take these proper steps, there are going to be quite a few vulnerabilities that are going to arise in our application.
Even if we put certain safeguards into place, we also have to think about how we're communicating. There are a lot of common application layer protocols, and vulnerabilities that come with those protocols as well. So for instance, with web-based, if we were just to use port 80, everything gets sent in clear text, and that doesn't really work nowadays. We should really be using HTTPS for all web communication. There are very few exceptions to that.
There are a lot of tools and resources that can help us identify vulnerabilities, and leverage those vulnerabilities to attack systems.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →