Security: Learn to help yourself

In this industry there is a growing and needed focus on security. There is always the threat of viruses, spyware, worms and hacker attacks. Many people feel that the larger companies are more vulnerable to attacks than small businesses. In truth, however, it’s often the other way around.

As a hosting company we do what we can to mitigate network intrusions. We feel it is our responsibility to offer these services as part of our base products. I used to get a kick out of companies announcing that they were now offering SPAM protection on their mail servers. Wouldn’t you do that by default? That is why MaximumASP invests in its network security using intrusion prevention systems, enterprise firewalls and virus protection. We literally block hundreds of thousands of possible attacks every hour coming into our network.

Many people think that if these tools are in place they are safe from the possible threat of being hacked. These systems simply protect the network but there is another side that many people do not think about or address. It is application security. It is important that people understand that the way an application is written must also be secure. There are many vulnerabilities on the application level that we see.

It is impossible for MaximumASP as a hosting company to throw some hardware network device up and protect from these types of attacks. The only way to prevent someone from taking advantage of these vulnerabilities is to correct the issues within the code itself.

Some developers are not aware of these risks. A SQL or Code injection, according to Wikipedia, is “a technique to introduce (or "inject") code into a computer program or system by taking advantage of the unenforced and unchecked assumptions the system makes about its inputs. The purpose of the injected code is typically to bypass or modify the originally intended functionality of the program.” The functionality most often bypassed is system security. Cross-site scripting attacks have been used most recently in phishing schemes.

Here are some tips to help you avoid the potentially disastrous effects of some of these attacks:

  1. Never trust any type of client side input. This means forms such as HTTP POST data, parameters set within a URI (HTTP GET) or cookie information.
  2. Always filter all un-needed characters from all client side input. This is especially true for any type of special characters. The following are characters that should never be allowed to pass in any client side input:
    • | (pipe sign)
    • & (ampersand sign)
    • ; (semicolon sign)
    • $ (dollar sign)
    • % (percent sign)
    • @ (at sign)
    • ' (single apostrophe)
    • " (quotation mark)
    • \' (backslash-escaped apostrophe)
    • \" (backslash-escaped quotation mark)
    • < > (triangular parenthesis)
    • () (parenthesis)
    • + (plus sign)
    • CR (Carriage return, ASCII 0x0d)
    • LF (Line feed, ASCII 0x0a)
    • , (comma sign)
    • \ (backslash)
  3. Include the URL encoded value of all characters you are filtering. For example the ‘ (single apostrophe) is equal to %27 when url encoded. The & (ampersand sign) is equal to %26 when url encoded. The URL http://example.com/example.asp?test=test’or%201=1%20-- is the same as http%3A%2F%2Fexample.com%2Fexample.asp%3Ftest%3Dtest%E2%80%99or%25201%3D1%2520—
  4. If you are going to pass any authentication information from your client to server SSL must be used to protect your data.
  5. Session cookies values should be very long and random. If your session values are easily guessed it is possible for an attacker to guess the value and steal or alter a session.
  6. Authentication information should not be passed within a cookie. Cookies can be stolen from a client’s system and used to authenticate just like a username and password.
  7. Application Session cookies should expire on logout or after a short period of inactivity.
  8. Remove all developer notes from production code. Often developers leave comments and notes within code that could be of use to an attacker. This is fine during development of an application but before this code is viewable to the public these notes and comments should be removed.
  9. Enable custom error messages at your webserver. Custom error pages allow you to remove the default error pages that could help an attacker learn how your system works.
  10. Always protect administrative or management URL’s with authentication and SSL. Never rely on hard to guess or hidden files or directories to protect these pages.
  11. If authentication is required for a web application always require strong passwords and ensure these passwords are being stored on your system in a secure method.

Web Application vulnerabilities like SQL injection, cross-site scripting and brute force attacks are the number 1 way we see customer accounts compromised on the MaximumASP network. If you follow the simple rules above when developing your webapplication your chances of becoming compromised are greatly reduced.