Jeffrey van Binsbergen.nl

The Big Security Checklist

Is your website or application secure or will your company be the next one leaking all customer details? The internet is filled with people looking for flaws on every website they can find and some don't have good intentions. In the past I was also one of the people crawling the internet for anything interesting. During my research I discovered that there were security flaws everywhere. Now it is time for me to help you and your company to prevent (most) of those flaws.

Never trust external data

Any data coming in your (web)application can contain something you didn't expect. The values can be changed or the format can be different than what you expected. For websites that will be everything in a web request (url, get/post parameters, Other posted content, Cookies, Referer, User-agent, etc.). For other applications this can be everything it reads from a file, url, socket or even UI input.

A few examples of results when not checking your received data are: SQL Injections (you get a query instead of just a number), Buffer overflows (Usually able to run own code), Errors which give some more info about your environment, Uploaded scripts instead of uploaded images. Accessing admin features (missing authentication checks), XSS attacks (User submitted HTML/JavaScript on your site). It can also be something as stupid as ordering non-existent product plans: When your website gives the user to choose between 1 and 2, and the attacker changes the form so it submits 3 or -1 or the famous JGDGDSKJGDSJSDG.

The big amount of glitches/hacks in games is purely possible because the client is allowed to send his own (modified) location and inventory. Note that for games this is usually done because of performance and latency reasons (You don't really want to have your server check every collision of every player movement). Games can encounter this by doing simple checks (Is the player moving faster than allowed?) and having report systems.

This also applies on anything encrypted! Encryption only prevents people in between to see the data (and usually tampering with it). The data is still encrypted on the machine of a user. A user can just attach a debugger to every process and see/change the real data. SSL connections are usually even easier: You can just create a self signed certificate, trust that certificate, redirect a connection to go to your own tunnel software which tunnels the connection to the real server. This allows you to see and change any data being sent to the server and back.

Don't just trust data coming from another server in your network either as someone can gain access to that machine and start doing the same tricks.

Give your application only access to the resources it needs

This is the point I've seen most companies fail at. Usually an attacker will come in using a leak in your web application. Web applications can be quite big and they are facing the internet. It just takes one small bug/undocumented feature in your (or your framework/server) code and Mr. Anderson will be able to do more than he is supposed to.

First your database connection. Is this done under a user which only can access the website database and not anything else? Good! SQL injections can still happen and database servers allow some nasty queries, like executing commands or reading files. Sometimes I saw that the old 'mysql.user' table was accessible with all the bruteforce-able password hashes of all users. Most of the times they even had a /phpmyadmin ready to use with the just gained credential information. Easy-mode! Even with just access read access to the right table you can find out the Admin-user password hashes and brute force them, giving your thankful hacker a new area to find even more and bigger security holes.

File access is also something you should pay attention to. Often a website is hosted on a web server with multiple other websites. Think about what a security researcher can see when looking in your inetpub/wwwroot folder: (Decompilable) source codes, config files, log files. Always run a website under a limited user account with only (read) access to the folders it needs to access. You wouldn't be the first to get broken into because of an old forgotten promotion site. This is also why you should be aware to host your website on a shared web host: One flaw in their configuration, and all websites are compromised. You would be surprised how often those big web hosts make mistakes on this area.

Network access to any other resources: What servers are accessible from your web or application server? Are there any file shares or internal web services which doesn't require any authentication? Is the data between servers encrypted?

Remember: Gaining administrator-access to everything is not the goal of a security specialist. It is to gain access to interesting data, or giving him any advantages normally not possible (For example with a web shop: Marking an order as paid or changing prices).

Stay up-to-date

Software bugs happen a lot. Even a small piece of software written by the best group of programmers is bound to have a few bugs. Luckily new versions with bug fixes are released to counter those bugs (often even before they are known to the public). A down side with releasing those new versions: People can compare the versions and find out what bugs were fixed.

Always make sure applications on your environment are on the latest stable version, including your Operation System. Any flaw in any application on a server can be helpful when trying to access even more resources. A flaw in your server application may allow a user to run code under a very limited user account, but by also using a flaw in an unpatched Windows installation the code can suddenly be run evaluated and do everything.

Limit access of people

You may have the world most secure system but you also still have people in your company with access to resources to be able to do their jobs. Those people are a common attack point for security specialists. It is probably the most difficult one to deal with when protecting yourself from nasty security incidents.

Educate people to recognize phishing attempts and test them often. Teach people that an attack may come from anywhere (mail, phone, in real life or even in their personal life) from anyone (customers, friends, co-workers with less access). Never leave your computer unlocked and don't just run anything. Maybe that program a friend downloaded for you is infected with a trojan because he used an untrustworthy source. That program can log your keystrokes and screen when you log in when working at home a month later.

Also update the software on all workstations. Keep track what people are running and on which version it is. Disable applications and plugins an employee doesn't need (like the Flash or Java browser plugin). A common way of attacking nowadays is by putting some malicious advertisement on big popular websites which get probably visited by half of your company's employees. Those advertisements can use exploits (Browser, Java, Flash, etc.) to run code on the machine without the user even noticing. Of course run a decent virus scanner, but be aware that it won't stop everything.

An attack can even be from the person itself. Audit and monitor everything and don't give the person access to more resources than he/she needs. Do remember that you're dealing with people, please be thoughtful of what limitations you apply and how users will experience them. When people need access to something for an assigned task, don't make them fill in 3 forms and wait 8 weeks.

Make logging in a bit more secure by adding two-factor authentication whenever possible (Not just your employees, your website users as well). Give instructions on how to choose a safe password and enforce it by applying password restrictions. Do not use easy guessable default passwords for new employees and do force them to change it at the first time they log in.

Monitor any suspicious behavior

Watch any errors happening on your websites. When poking around your overly interested visitor will usually trigger some errors before finding anything useful. Pay attention to requests after that: If the errors stop he may have given up, or he have found something. For a security researcher errors are usually a sign that input is badly/not checked. Just hiding the errors is not enough, there are more ways to notice that you are able to do more than you're supposed to.

Suspicious behavior can also happen from within a company. Is a person trying to access a lot of resources? Pay attention to it and find out if it was for a valid reason.

Be thankful to those reporting a flaw

If you're very lucky, someone found a flaw on your website and actually reported it to you instead of abusing it. Of course it goes without saying that dealing with this flaw must be your number one priority. But also reward the person for reporting it. For you it is just a small gift, for them it is a reason to stay nice and keep reporting bugs to companies. Most places I've reported serious security flaws to didn't respond or started threatening me directly. As you would probably understand, the choice of 'Reporting the bug' will be less obvious after that.

Conclusion

Breaking in a system is like puzzling, and with most puzzles: People who do it often get quite good at it. It is not uncommon for a security researcher to use multiple holes in different systems to get to the interesting data. Always expect to get weird data in your applications and add checks for it. Make sure your software is on the latest stable version and limit what is possible when having access to a part of the environment.

Review your security often for your current environment but also review your new software designs for security flaws. When in doubt: Let a professional security specialist check your security.

Show all articles