• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

Going Live

Here are some additional security issues that are not necessarily specific to dynamic sites created by GoLive, but are good rules of thumb to follow for any site. These are the author’s personal suggestions, and are not endorsed by the CIA, KGB, or any other international espionage agency:

  • You might not expect to see this listed as the first security tip, but it’s one that I think is pretty important. Know your realistic security concerns and don’t go overboard. Security overkill costs money, imposes restrictions and inconveniences, and in 999 out of 1,000 cases, isn’t necessary. What’s the worst that can happen? What are the realistic chances that someone has any interest in your site? Have you done something foolish like put unencrypted bank or credit card account numbers in a document or database accessible to that server? Do your customers have any real interest in hiring the needed talent to illegally hack in and view your other customers’ records, and even if they did, would that harm anyone? Know the answers to these kinds of questions before you spend money on security.

  • You might notice on the Rooftop Records site that some of the links to detail pages and so on end with something like this: detail.php?album_id=3. You could go to that URL and see album number 3; then you could put your cursor into the address field, backspace over the 3, type in a 4, and then you could view album number 4. You can see how it’s possible that one customer could easily view another customer’s record this way, or one salesperson could view another salesperson’s accounts. Solve this by using server-side variables, session variables, or cookies rather than URL arguments whenever possible. These cannot be edited by the user. If access to some of your records requires a user to be logged in (I can’t change my credit card on Amazon unless I’m logged in), set a cookie or a session variable for that user, embed that value in all his authorized database records, and be sure to include that parameter in all queries.

  • Most developers never think of this, but statistically, it’s far more likely that someone will walk into your office and carry your server away than it is that you will ever be hacked. Take physical security precautions, and you will remove most of the threat right then and there.

  • Hacking is much easier from inside your office over the LAN than from outside via the Internet. Take appropriate network security measures as well as server security measures. And lock the door where the server lives.

  • Usually the sensitive information is not on your Web server at all but rather on a database server or file server. Take care that these machines receive the bulk of your physical and electronic security before you worry about the Web server. Professional thieves know that there are a hundred ways to steal your data without having to learn Unix.

  • Don’t put anything inside your server folder that doesn’t have to be there. ASP works with a Microsoft Access database residing inside the config folder. Don’t do that.

  • Use unguessable passwords and change them at frequent, irregular intervals. Don’t write them down. Don’t type them in a document and put it on a computer that’s on your network.


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint