by Jason Lustig 

As an ambitious college student, I am always looking for new and exciting business opportunities. So let’s do something then! I have an idea – let’s rob a bank. It won’t be that hard – right? I mean, they have security guards and all but that’s nothing a gun won’t stop. And if there are a few of us, it’ll be quite a bit easier. Right?

Wrong.

If we had actually tried to rob a bank, we would have found it much harder than we expected it to be, especially if we want to cause “real damage.” Banks, as well as most other high security areas like airports and government buildings, have a series of security measures in place to make sure that robberies and other heinous crimes don’t take place, and that if one did, the damage would be minimized. They use a method known as security by depth, which means they have multiple layers of security which you first need to know about, and then break through, before you can do anything remotely horrible. If a robber tries to get the bank manager to open a vault, the manager most likely could use a special key which would trigger an alarm, or would be armed himself. Metal detectors guard all entrances to airports, and you even have to check your bags when you enter places such as the United Nations building in New York City.

Why should our web applications be any different? They hold our data and our customers’ trust that often is just as or more valuable than its weight in gold. The truth is, we should treat our applications like a high-security building. The way to do this is simple: Trust no one. Don’t give anyone a “special security clearance.” Check everything. Data comes in, takes care of some business, and then leaves. Subject every piece of data entering the system to a series of rigorous tests and checks, and only then let it in. The more barriers that a request to our application has before it enters the “high-security area” where you can assume that all data is secure, and the better off you will be.

What security measures do high-security buildings have in place?

Metal Detectors. Why do some banks, and almost all airports, have metal detectors? Because metal is supposedly the key to committing a crime. Metal is the key ingredient in guns, knives, and other tools of mass destruction. On September 11th, we all saw what happened when people assumed that metal itself was enough of a sign of an attacker: people used something else (box cutters) that was below the low-water mark of metal to be detected and confiscated.
That’s the reason why high-security areas don’t stop at metal detectors, even though theoretically they stop the worst items from entering. When you fly to New York, should they chop off your hands and place them in the cargo hold, under the agreement that they would be re-attached when you reach your destination, because they could be used to strangle someone?

The question that needs to be asked is: What are the key ingredients to an exploit, that you want to catch with your “online metal detector?” The biggest one, that causes the most problems, is malformatted input, and that is what you should watch out for in the first layer of our in-depth security scheme.

Decide early on, what languages will you allow to use your program? English? French? Chinese? If you don’t need to support Unicode, why should you? At some point, true, you might want to sell your application to a budding Russian or Indian company, but if it’s just your company’s inventory tracking application that your sales representatives use when they visit clients, you probably will just be working with English (or whichever language you speak) – and so you can outright deny any requests that send data that isn’t entirely alphanumeric. Make your job easy by denying more that is strictly unsafe – because a bug could pop up somewhere else that makes those characters unsafe. Even though you thought they were safe, and ultimately it’s your job to secure your application, and you can’t blame others for your security woes.

{mosgoogle}

Questioning and Profiling. Does something not look right? Security forces will pull you aside and question you. We may not like it, but there is often a profile for the sorts of people who will commit a crime. Who looks more likely to commit a crime or terrorist act – the clean-shaven man in the crisp business suit driving a Lexus, or the long-haired, scraggly looking guy with a big backpack, baggy clothes, and a ticking noise coming from them? Similarly, you can (sort of) profile data coming from a questionable source. Don’t let anything coming through a known proxy or anonymizer even touch your application: yes, we might enjoy “privacy” on the internet, but too often they are taken-advantage-of by malicious users and crackers.

FDIC Insurance. Even if a crook managed to steal whatever cash were in the vault, each of the bank’s customers has up to $100,000 insured by the FDIC. The equivalent in web application development is backups. Have backups of everything – from your code to the database – and even if someone does get in, you won’t lose anything.

Security cameras. There are some key problems with logging, but you should monitor every single transaction that takes place within your program. That way, even if someone does break in, you have information about who did it and can try to do something about it, like get in touch with their ISP or ban all IP addresses related to it from even connecting to your server.

Multiple Security Checkpoints. While it is great to say “my entire application will be wholly secure,” some people need access to administrator functions and other goodies that could be dangerous in the hands of a malicious user or exploit code. Why should the database login that a regular user uses to connect to the database even have the ability to drop tables from the database, or delete rows in certain important tables? Break your application up into clearly defined areas for “administration” and “regular day-to-day use.” Have a different page layout and color scheme for each area. In addition to letting users know where they are and that they either can or cannot break things, the Administration section can also connect to the database using a different login than the Regular User section. This reduces the risk of a malicious user within the Regular User section, because they will not be able to do anything malicious with the database anyway.

In addition you can check security before doing actions. Take this code (PHP used in example):

// <? // if ($is_admin == 1) // { // /* do some more code */ // do_drop_table(); // } // ?>

// <? // if ($is_admin == 1) // { // /* do some more code */ // If ($is_admin == 1) // { // do_drop_table(); // } // } // ?>

Each and every page request that your application handles is like a person walking into a high-security area. The problem is, once someone gets in, it only takes one cold-hearted person to wreak havoc and destroy all of the machines you have in place (destroy your database), or mug all the other people in your application (also known as stealing others’ personal information).

Don’t Publish the Floor Plan. In today’s world, open-source software is everywhere. When your application is open-source, any malicious user can study the code to look for a possible exploit. Sure, there are lots of advantages to open-sourcing your program and I don’t suggest against it. However, there is nothing wrong with security by obscurity, as long as it is combined with security by design. Would a bank plaster its entire floor plan on the side of the building for anyone to read, on the assumption that people would find mistakes and tell them about it? No they would not, it would be a great boon for bank robbers everywhere.

Security by Obscurity, often looked down-upon by software developers, can be a great tool as yet another layer in your security strategy. It is very dangerous when used as the only security measure, but that can be said for any of these types of security. When you only have one layer of security, once you break through that, you’re done for. This can be said for logging (the intruder can disable logging), backups (they could destroy the backup copies), malformatted input (they could try to get someone’s login through social engineering), and it goes on and on.

When you work in real-world security management, there are a number of trade-offs that have to be made. The most obvious one (and the one that most people complain about) is the balance between security and people wanting to get things done. If everyone was double- and triple-checked by airport security, everyone would complain that it was impossible to get through security – lines would pile up incredibly long, and people would have to show up hours before their flight even starts taking luggage. That’s why we have random checks, and other methods to make security more “efficient” and less “bothersome.”

We have a huge advantage, writing web applications, over people in the real-world security industry. Computers never complain and most of the security measures that you put in place will never bother anyone. In fact, the mark of a well-designed security strategy is that nobody will even have to think about security. Users will be able to log into your application, take care of their business, and then go on to the next thing that they have to do. The security shouldn’t bother normal users – but it should bother the Russian mafia.

Only registered users can write comments.
Please login or register.