Confidentiality

If this were a book intended for security professionals rather than software developers, I would also cover such topics as protecting your servers from data theft or how to protect intruders from seeing sensitive information written on whiteboards, but these are out of scope for the majority of software developers.

Integrity

Fortunately, data integrity is easier to check than one would think at first glance. You’ll see how later in the book.

Availability

Most developers would probably agree that protecting your websites against Denial of Service (DoS) attacks (when an attacker sends enough requests to a web server that prevents it from responding to “real” requests) and Distributed Denial of Service attacks (when an attacker sends requests from many different sources to prevent networks from blocking one IP to stop the attack) would fall under the “security” umbrella. But taking proper backups and testing their validity is very much a responsibility of security because it directly affects the availability of the website if a problem were to occur.

I will generally focus more on confidentiality and integrity over availability in this book, since most defenses against most attacks against website availability fall outside of the responsibility of the average software developer. There is one thing worth noting, however. As you will see later on, helping protect the confidentiality or integrity of your data can harm availability, since protecting confidentiality and integrity causes extra processing to occur, making a website more susceptible to certain types of attacks against availability. It will be tempting for some developers to skip protections in the name of efficient processing, which improves availability. In many cases, this is simply the wrong approach to take. It is rare (though not unheard of, as you’ll see later) for one feature to cause a serious availability-related vulnerability, so it is usually best to focus on confidentiality and integrity and fix any availability issues as they arise.

In other words, in most cases, focusing on confidentiality and integrity is better than skipping protections in the name of picking up a few milliseconds of performance.

Definition of “Hacker”

While we’re defining what “security” means, let’s now take a moment to state explicitly how this book will use the word “hacker,” as well as explicitly state what we mean by a hacker doing “damage.” When you hear about hackers doing harm to your website, it is easy to picture a hacker breaking into your system to make your website sell unsavory products. But should we call someone who accidentally takes information they don’t need because of a logic flaw in your website? Or should we call stolen credit cards “damage”?

For the sake of this book, let’s define “hacker” as anyone looking to compromise the Confidentiality, Integrity, or Availability of the data within your website, whether with malicious intent or not. We’ll also use the word “breach” for any incident in which the Confidentiality, Integrity, or Availability of your website is compromised. Finally, we’ll use “damage” as a shorthand for any negative fallout, even if that is only damage to your reputation because no specific monetary harm has been incurred.

Reconnaissance

If you want to build successful software, you’re probably not going to start by writing code. You’ll research your target audience, their needs, possibly create a budget and project plan, etc. An attack is similar, though admittedly usually on a smaller scale. Successful attackers usually don’t start by attacking your system. Instead, they do as much research as possible, not only about your systems but about the people at your company, your location, and possibly research whether you’ve been a victim of a cyberattack in the past.

Much of this research can occur legally against publicly accessible sources. For instance, LinkedIn is a surprisingly good source of useful information for an attack. By looking at the employees at a company, you can usually get the names of executives, get a sense for the technology stack used by the company by looking at the skills of employees in IT, and even get a sense for employee turnover which can give potential attackers a sense for number of disgruntled employees that might want to help out with an attack. Email addresses can often be gotten via LinkedIn as well, even for those that are not published. Enough people publicly post their emails that the pattern can be deduced, i.e., if several people in an organization have the email pattern "first initial + last [email protected]", you can be reasonably sure that many others do as well.

During this phase, a hacker would likely also do some generic scanning against company networks and websites using freely downloadable tools. These scans are designed to look for potentially vulnerable operating systems, websites, exposed software, networks, open ports, etc. It is not clear whether such actions are illegal, but they are common enough where most scans would not be remarked upon, much less prosecuted.

Penetrate

Research is important to know what attacks to try, but research by itself is not going to get a hacker into your system. At some point, hackers need to try to get in. Hackers will typically try to penetrate the most useful systems first. If a spear-phishing attack is attempted, then attacking the Chief Financial Officer (CFO) would probably be more helpful than attacking a marketing intern. Or if a computer is the target, attacking a computer with a database on it would be a more likely candidate than a server that sends promotional emails. However, that doesn’t mean that hackers would ignore the marketing intern – it’s also likely that the CFO has had more security training than the marketing intern, so the intern may be more likely to let the hacker in.

The system penetration can happen many ways, from attacking vulnerable software on servers or finding a vulnerability in a website. Two of the most commonly reported successful attack vectors, though, are either phishing attacks or rogue employees. As a web developer, it’s your responsibility to make sure that attackers cannot use the website you are building as a gateway into your system. There are also important steps you can take to help limit the damage attackers can do via a phishing attack. We will cover all of these later in the book. For now, let’s focus on the process at a higher level.

Expand

Once an attacker has made it inside your network, they need to expand their privileges. If a low-level employee happens to click a link that gives an attacker access to their desktop, taking pictures of their desktop might be interesting for a voyeur, but not particularly profitable for a hacker. Hacking the desktop of the CFO could be more profitable if you could find information to sell to stock traders, but even that is rather dubious. Instead, a hacker is likely to attempt to escalate their privileges by a number of means. Many of these methods are out of scope for this book because they involve planting viruses or making operating system level exploits. We will talk about methods to help prevent this type of escalation of privilege in web environments later on.

Hide Evidence

Finally, any good hacker will make an attempt to cover their tracks. The obvious reason is that they don’t want to get caught. While that’s certainly a factor, the longer a hacker has access to a system, the more information they can glean from it. Any good hacker will go through great lengths to hide their presence from you, including but certainly not limited to disguising their IPs, deleting information out of logs, or using previously hacked computers to attack others.

Detecting Possible Criminal Activity

Whether you’re directly aware of it or not, you’re almost certainly already taking steps to stop criminals from attacking websites directly. Encoding any user input (which ASP.NET Core does automatically) when displayed on a web page makes it much harder to make the browser run user-supplied JavaScript. Using parameterized queries (or a data access technology like Entity Framework which uses parameterized queries under the hood) helps prevent users from executing arbitrary commands against your database. But one area in which most websites in general and ASP.NET in particular fall short is detecting the activity in the first place.

Detecting this activity requires you to know how users behave in the system. As one example, you're probably familiar with the idea of showing user details based on information within the URL, either in the query string or URL itself. You usually don't want users pulling information about ALL other users in the system by changing the URL, but if you’re not tracking the number of unauthorized or error requests against that URL, there is nothing stopping the hacker from getting the entire list of your users in your database, and there is no way for you to figure out who stole the information if you do realize that information has been stolen.

Being PCI or HIPAA compliant is increasingly dependent on having a logging system that is sufficient to detect this type of suspicious activity. And unfortunately, despite the improved logging system that comes with ASP.NET Core, there is no good or easy way to implement this within your websites. We will cover this in more detail later in the book.

Honeypots

A honeypot is the term for a fake resource that looks like the real thing, but its sole purpose is to find attackers. For example, an IT department might create an SMTP server that can’t actually send emails, but it does log all attempts at using the service. Honeypots are relatively common in the networking world, but oddly haven’t caught on in computer programming. This is unfortunate, since it wouldn’t take too much effort to set up a fake login page, such as at “/wp-login.php” to make lazy attackers think you’re running a WordPress site, that would capture as much information about the attacker as possible. One could then monitor any usage of that source much more closely than any other traffic, and possibly even stop it before it does any real harm.

Finding Sensitive Information

When deciding what in your website to protect, there is certainly information that is more important to protect than others. For instance, knowing how many times a particular user has logged into your website is certainly not as important as protecting any credit card numbers they may have given to you. What should you focus your time on?

If your data falls under one of these categories, chances are you should take extra steps to protect it. Don’t let these be a limitation, though. As one example, if your system stores information as trade secrets to your company, it would not fall under these categories but should absolutely be secured.

It is necessary to secure both Data in Transit and Data at Rest in order to secure your data, and each requires different techniques to implement, which we’ll explore later in the book.

User Experience and Security

When talking about how far is too far to go with security, I would be remiss if I didn’t talk about what security does to user experience. First, though, I should define what I mean by this term. User experience, or UX, is the term for making a user interface as intuitive and easy as possible. The line between UX and user interface (UI) design is blurry, but the way I usually think of it is that UI is about making the site beautiful, and UX is making the site easy to use.

It’s not too hard to notice that security and UX often have competing goals. As we’ll see throughout this book, many safeguards that we put in place to make our websites more secure make the websites harder to use. I’d like to say again that our goal is NOT to make websites as secure as possible. No company in the world has the money to do the testing necessary to make this happen, nor does anyone want to drive away users who don’t want to jump through unreasonable hoops in order to get their work done. Instead, we need to find a balance between security and UX. Just like with costs, our balance will vary depending on what we want to accomplish. We should feel more comfortable asking our users to jump through hoops to log into their retirement account vs. to log into a site that allows users to play games. Context is everything here.

Zero-Day Attacks

Vulnerabilities that exist, but haven’t been discovered yet, are called zero-day vulnerabilities. Attacks that exploit these are called zero-day attacks. While these types of vulnerabilities get quite a bit of time and attention from security researchers, you probably don’t need to worry too much about these. Most attacks occur using well-known vulnerabilities. For most websites, keeping your libraries updated will be sufficient protection against the attacks you will face that target your third-party libraries.

Spoofing

Spoofing refers to someone appearing as someone else in your system. Two common examples are a hacker stealing the session token of a user to act on behalf of the victim, or a hacker using another computer to launch an attack against a website to hide the true source of the attack.

Tampering

Has the hacker changed my data in some way? What I said in the “Integrity” section of the CIA triad applies here, and we will get into ways to check for tampering later in the book.

Repudiation

In addition to checking to see if the data itself has been tampered with, it would be useful to know if the source has been tampered with. In other words, if I get an email from you, it would be useful for both of us if we could prove that the contents of the email were what you intended and that you, and no one else, sent it.

The ability to verify both the source and integrity of a message is called non-repudiation . Non-repudiation doesn’t get the attention it deserves in the development world, but I’ll talk about it later in the book because these checks are something you should consider adding to API calls.

Information Disclosure

Hackers often don’t have direct access to the information they need, so they need to get creative in pulling information out of the systems they’re attacking. Very often, information can be gleaned using indirect methods. As one example, imagine that you have created a website that allows potential customers to search arrest records for people with felonies, and sells access to any publicly available data for a fee. In order to entice customers to purchase the service, you allow anyone to search for names. If a record is found, prompt the user to pay the fee to get the information.

However, if I’m a user who only needs to know if any of the individuals I’m searching for have any felony, then I don’t need to pay a penny for your service. All I need to do is run a search for the name I’m looking for. If your service says “no records found” or some equivalent, I know that my individual has no felonies in your system. If I’m prompted to pay, then I know that they do.

A more common example of information disclosure (or, as it is often called by penetration testers, information leakage) can be found during a login process for a typical website. To help users remember their usernames and passwords, some websites will tell you “Username is invalid” if you cannot login because the username doesn’t exist in the system and “Password is invalid” if the username exists but the password is incorrect. Of course, in this scenario, a hacker can try all sorts of usernames and get a list of valid ones just by looking at the error message.

Unfortunately, while the default ASP.NET login page didn’t make this particular error – the website is programmed to show a generic error message if either the username is not found or the password is invalid – they made one that is almost as bad. If you want to pull the usernames from an ASP.NET website that uses the default login page, you can try submitting a username and password and checking for the amount of time it takes for the page to come back. The ASP.NET team decided to stop processing if the username wasn’t found, but that allows hackers to use page processing time to find valid usernames. Here is the proof: I sent 2000 requests to a default login page, half of them with valid usernames and half without, and there was a clear difference between the times it took to process valid vs. invalid usernames.

We’ll discuss this example, and how to fix it, in greater detail in Chapter 7.

There is one final point worth making about Information Leakage. The vast majority of books and blogs that I’ve read on security (quite frankly including this one) don’t give this topic the attention it deserves, largely because it is so dependent upon specific business functionality. The login example given earlier is common on most websites, but writing about (or creating a test for, which we’ll talk about later) the felony search leakage example would be difficult to do in a generalized fashion. I’ll refer to Information Leakage occasionally throughout this book, but the lack of mentions is not indicative of its importance. Information Leakage is a critical vulnerability for you to be aware of when securing your websites.

Denial of Service

I touched upon this earlier in the chapter, but Denial of Service (DoS) attack is an attack in which an attacker overwhelms a website (or other software), causing it to be unresponsive to other requests. The most common type of DoS attack occurs when an attacker simply sends thousands of requests a second to a website. Your website can be vulnerable to DoS attacks if a particular page requires a large amount of processing, such as a ReDoS (Regular Expression Denial of Service) attack, when a particularly difficult-to-process regular expression is called a large number of times in short succession.

Another example of a DoS vulnerability happened in WordPress a couple of years ago. A publicly accessible page would take an array of JavaScript component names and combine the component source into a single file. However, a researcher found that if someone made a request to that page with ALL components requested, it took only a relatively small number of requests to slow the site down to the point it was unusable.

Just a reminder, a Distributed Denial of Service attack, or DDoS, is something subtly different. DDoS attacks work similar to DoS attacks in that both try to overwhelm your server by sending thousands of requests a second. With DDoS, though, instead of getting numerous requests from one server, you might receive requests from hundreds or thousands of sources, making it hard to block any one source to stop the attack.

Elevation of Privilege

One example: in many companies, especially smaller environments, web developers have access to many systems that a hacker would want access to. If a hacker were to successfully compromise a web developer’s work account via a phishing attack, that hacker could have high access to a large number of systems. Instead, if the company uses layered security, the developer’s regular account would not have access to these systems, but instead they would need to use a separate account to access more sensitive parts of the system. In cases where the web developer needs to access servers only to read logs, the new account would follow the principle of least privilege and only have the ability to read the logs on that particular server. If a hacker were to compromise the user’s account, they would need to attempt an elevation of privilege in order to access specific files on the server.

It’s important to note here that there’s more to fear here from the company’s perspective than external bad actors. Statistics vary, but a significant percentage of breaches (possibly as much as a third, and that number may be rising)³ are at least aided by a disgruntled employee, so these concepts apply to apps written for internal company use as well.

Brute Force Attacks

Some attacks occur after a hacker has researched your website, looking for specific vulnerabilities. Others occur by the attacker trying a lot of different things and hoping something works. This approach is called a brute force attack . One type of brute force attack is attempting to guess valid usernames and passwords by entering as many combinations of common username/password combinations as possible. Another example of a brute force attack was given earlier in the chapter; attackers attempting to take down your website by sending thousands of requests a second would be considered a brute force attack.

Unfortunately, ASP.NET does very little to help protect you against brute force attacks, so we will explore ways of preventing these later in the book.

Attack Surface

One of your goals should be to reduce the attack surface as much as reasonable to reduce the places that an attacker can get a foothold into your systems – and reduce the number of places you need to keep secure.

Security by Obscurity

Long story short, if you want something protected, actively take steps to protect it.

Man-in-the-Middle (MITM) Attacks

The responsibility for stopping many MITM attacks falls under the responsibility of the network and administrators, since they are generally the ones responsible for preventing the type of access outlined in the last two bullet points. But it is vitally important that you as a developer be thinking about MITM attacks so you can protect both the Confidentiality (can anyone steal my private data?) and the Integrity (has anyone changed my private data?) of your data in transit.

Fail Open vs. Fail Closed

One question that software developers need to answer when creating a website is: how will my website handle errors? There are a lot of facets to this, and we’ll cover many of them in the book, but one important question that we’ll address here is this: are we going to fail open , i.e., generally allow users to continue about their business, or fail closed, i.e., block the user from performing any action at all?

As one (somewhat contrived) example, let’s say that you use a third-party API to check password strength when a user sets their password. If this service is down, you could fail open and allow the user to set their password to whatever they submitted. While less than ideal, users would be able to continue to change their password. On the other hand, if you chose to fail closed, you would prevent the user from changing their password at all and ask them to do so later. While this also is less than ideal, allowing users to change their password to something easily guessable puts both you as the webmaster and them at risk of data theft and worse.

In Listing 2-1, the programmer put in manual checks for user in role, intending to redirect them to the login page if they are not in the “Admin” role. (As many of you already know, there are easier ways of doing this, but we’ll get to that later.) But if an error occurs, this code just lets the user go to the page. But in this case, an ArgumentNullException is thrown if the user is not logged in, and then the code happily renders the view because the exception is swallowed. This is not the intended behavior, but since the code fails open by default, we’ve created a security bug by accidentally leaving open a means for anyone to get to the admin page.

Separation of Duties

Separation of Duties can be most easily explained by thinking of a small business accounting for the cash coming out of the cash register at the end of the day. You probably wouldn’t want the same person adding the totals of all the receipts as the person counting all the money at the end of the day. Why? With one person, it would be easy to pocket a couple of receipts and steal that money. Separating the money counting from the receipt calculations makes it harder to steal from the company.

In software development, this most obviously applies when talking about access to production systems and production data. I’m sure most of you have had challenges debugging a production issue because you had to work through others to get the information from the production server you needed. But, without that protection, a software developer could fairly easily steal data, write that to some place in the production server, steal it periodically, and then erase evidence afterward. There are other instances like this too, and I’m sure you can come up with a few if you think about it for a bit.

We will talk about separation of duties further in Chapter 11.

Fuzzing

A term that you’ll hear from multiple people in multiple contexts is fuzzing. We won’t talk much about fuzzing in this book, but it is worth taking a little bit of time talking about what it is in case it comes up in conversations about security.

Generally, fuzzing is the term for altering input to look for security bugs. For instance, if your system is expecting a single digit integer in a particular field, sending double digit integers, negative integers, floats, letters, symbols, and/or integers above four billion could all be considered fuzzing. Fuzzing, especially targeted fuzzing (i.e., changing input based on context rather than randomly sending any content that doesn’t match the original), can be a great way to find some types of bugs in web applications. With this definition, you can fuzz anything in a website that takes user input, including the URL, form fields, file uploads, etc.

The reason I mention fuzzing here is that a subset of people within the security community use the word “fuzzing” to mean subtly different. For these people, fuzzing is the term used for testing binary files by changing the inputs, looking for application crashes. These types of fuzzers, like AFL⁴ or ClusterFuzz,⁵ generally don’t work well against websites and so aren’t tools that a typical web developer would use regularly. But if you go to security conferences and talk to other developers, be aware that not everyone uses the term “fuzzing” the same way.

Phishing and Spear Phishing

You may already be familiar with the term “phishing,” which is the term when hackers try to trick users into divulging information by trying to appear like a legitimate service. One common attack that fits into this category would be an attacker sending out emails saying that your latest order from Amazon cannot be shipped because of credit card issues, and you need to reenter that information. The link in the email, instead of going to amazon.com, would instead go to the hacker’s site that only looks like amazon.com. When the user enters their username, password, and credit card information, the attacker steals it. Spear phishing is similar, except in that a spear-phish attack is targeted to a specific user. An example here might be if the attacker sees on LinkedIn that you’re a programmer at your company, and you’re connected to Bill, a software development manager, the attacker can try to craft an email, built specifically to fool you into thinking that Bill sent an email requesting you to do something, like provide new credentials into the system you’re building.

At first glance, it may seem like preventing phishing and spear phishing is outside of the scope of a typical web developer. But, as we’ll discuss later on, it’s very likely that phishers are performing attacks to gain access to systems that you as a developer are building, and therefore you need to be thinking about how to thwart phishing attacks to your systems.