How this $#!+ works

If you've used (almost) literally any website at all ever, you've sent data over the interwebs. Whether it's a username/password to log in, or sometimes even just shopping online, you've used two main ways of sending data. Let's take a look at both of them, and even get into a little more details because that's what happens when they make me write a blog. Gonna get long-winded, folks.

The "Get" Request

So this is probably the most common of the two, but we're talking about a very specific implementation of it. And for this, we're gonna look at a funky URL. You're no doubt accustomed to the websitedotcom/pagename/pagename, but there's also a "GET" version of this. It'll look something like websitedotcom/?name=Thanos. You'll mostly see this when you're shopping online and you apply a filter to the shopping cart. Maybe you're looking at computers, so you'll see websitedotcom/computers/. But then you want to only show gaming PCs, not all of them. So the URL may change to websitedotcom/computers/?type=gaming.This is just an easy, general way of using a single 'page' to show a multitude of different data depending on what "type" is set to. It's what we developers refer to as "get variable", and we basically use it when the data being sent doesn't matter (at least for security reasons). Now, this definitely isn't the only way to do it, there's actually a fairly popular alternative that is built into most MVC pattern websites. And instead of using a get variable, they may just stick to a more standard URL that would look like "websitedotcom/computers/gaming". It looks better, at least in my opinion, but the end result for the user is exactly the same. But what if you want to send data without it being visible?

The "Post" Request

So these requests won't be seen by the user (kind of, more on that later) when being used. These are commonly used for forms. Login forms, contact forms, all of the ones where you are submitting data that you don't want just anyone to see. It works similar to GET in that the data gets sent to another page/file (be it on the same site or another) that processes the request and returns whatever value is programmed into the site. In a WordPress website, it's used everywhere. Whenever you post a blog, create/edit a page, change some settings, etc, they're ALL post requests. Not all of it is because of security, though. Sometimes it's used just so you don't have an impossibly long URL that has an insane amount of get variables just hanging out in the address bar.So let's look at what happens here once you click submit. The data gets sent "invisibly" to a specified destination, usually referred to as the action, where it is processed. So if you're logging in, the application will get the information from the database that matches your username, assuming it exists of course, then compare the password you provided to the password in the database. Quick sidenote on security, your password doesn't look like your actual password in the database. At least it shouldn't. Ideally, it's encrypted (we actually call it hashed in the dev world, but that's honestly splitting hairs) and stored securely. When you submit your password to sign in, it is also encrypted, then compared. So nothing gets "undone" for security purposes. If everything matches up, you're officially signed in.So POST is the best way to send data from one page to another. But is it REALLY invisible? lolnopenotevencloseDon't worry, we'll get there

HTTP/HTTPS

So we've written about this before recently, and even have a video about it, but basically, any data sent, even with a POST request, can still be seen as it's transferred over the network. And anyone who has what's often referred to as a data sniffer can see this data being sent/received. But that's where the "S" in HTTPS comes in. Basically, it means your site has an SSL. Put simply, an SSL basically encrypts the data before it's sent, then un-encrypts it on the other end. So sure, data sniffers can still see what's being sent, but it looks like a bunch of random nonsense. Much like your password in a database. Pretty cool, right?Encrypting this stuff is the real key here. Of course, it's not entirely 100% safe, but it's pretty damn close. Even if someone managed to capture the encrypted data, they'd have a hard time cracking it and getting your actual data out of it. Hacking someone is NOTHING like you see in the movies. It's not glamorous and fast. It's a painstaking task that could take literally years (sometimes even hundreds or thousands with our current technology that's so readily available to the general public) to complete. The fact of the matter is, most 'hacking' that you see is mostly just when someone sends unsecured data or someone guesses your password too easily.

Feeling Smarter Now?

Good. Now go to work and parrot all of this stuff back to your coworkers so they brag to your boss about how knowledgeable you are on the subject of cyber security that they offer you a high-paying salary in their IT department, making a lot more than you were making in sales, and you move up the corporate ladder as you continue to read our blogs on the subject until you become Chief Technical Officer, where you only stay for a few years before you split off to start your own startup software distribution company that becomes so wildly popular that even Microsoft or Apple can't compare to all the innovation you've managed to bring to the world of cyber security over your time in the field.Seems unlikely, right?so is hacking encrypted data.