Most "hacking" occurs at the server level, either through an OS security hole or an easily violated FTP password. So put your scripts on a solid server only accessible via https, don't use FTP to transfer files, and if you do, change that password often. If someone can hack the server, they can see your script, and it all comes down.
Secondly I cannot stress the importance of screening all data on input, remembering Selena Sol's mantra: all user input is a potential hack. Instead of trying to predict the "bad things" someone can input to your forms, it's easier to only allow exactly what you want to be submitted. For example, a name field will only contain alphabetic characters and possibly a ' or -, so only allow those ASCII characters to be input with a name field.
Secondly you can use Javascript to encrypt data prior to submitting (Google Javascript MD5.) What this will do is prevent any sensitive input, such as credit card numbers or your key, from being sent to the server as as clear text. You can do the same for data coming from the server, but if you have a secure cert installed, it's doing this already.
Use the file permissions tools of the OS to disallow any other system users to access files they should not be able to. This, really, is only relevant if some arbitrary user gets into the system, but it's just one more layer.
Shared hosting? Bad idea. Newbie programmer installs a free script on their site, script has security holes that allows hacker to gain access to the system, then they start nosing around and doing what they do.
Put your most sensitive files outside the domain root.
If you interact with a database, do not use field names, table names, or other naming that directly relates to your database. Worst of all, do not create a select statement directly from variables in your forms. This is an easy invite for an attempted hack:
<input type="hidden" name="table" value="customers">
<input type="text" name="fname" value="John">
<input type="text" name="cc" value="4007000000027">
I mentioned screening only to allow expected input; it is important to disallow any metacharacters or other nasty items that can be injected into your program. By default, if you only allow non-metacharacter input, you will be doing this, but it's important to make sure it doesn't allow metacharacters.
There is really a lot more, a search for script security, email injection, or sql injection will bring up tons of documents, each of them having something to offer.
This is intended for software registration. The basic process will be as follows:
1) The user will already have been provided a license code through another, separate, process. Security at this stage is provided by our payment processor
2) Using this license code the program itself will generate a serial number that will be unique to the computer and based on the CPU serial. The license and serial will be hashed to create an encrypted combination. I’m not really worried if this hash is intercepted by a hacker since it will be unique to this computer and useless to anyone else. This hash will be created by the program, not the online script
3) The user will go to our online registration page and enter the hash code generated in #2. This will be passed to the script, which needs to do three things:
èCheck to make sure that the hash is valid and that the license code in the hash has not been registered for a different serial. If it has return a license violation error.
èIf the license has not been registered already it will store the hash, either in a database or flat file. The only security I need here is to prevent hackers from deleting entries since this would let them re-register for another computer. I could care less if hackers read it since the hashes are only valid for a single computer
èOutput a third value that is a combination of the original hash plus some extra information that the user will then input directly into the program to complete the registration
So the script will have to be secure to prevent hackers from finding out what the code is that generates the registration code in the third step. This is really the only critical issue since the information transmitted cannot be used if it is intercepted by a hacker. I just need to be able to ensure that they can’t recreate the algorithm for step 3 to create their own registration codes.
I’m starting to think that some sort of compiled script, perhaps using C, would be best since it can’t easily be broken even if a hacker obtains it.
If the license has not been registered already it will store the hash, either in a database or flat file. The only security I need here is to prevent hackers from deleting entries since this would let them re-register for another computer.
Flat files are tough on hard drives and unwieldy, go with a database. Then research SQL injection attacks and plug up those holes, if there are any. IF you do use a flat file, this is one you want outside the domain root, if possible, so a casual web user can't stumble on it.
So the script will have to be secure to prevent hackers from finding out what the code is that generates the registration code in the third step.
The only way I know of that someone could do this is if the box gets rooted or someone hacks into an FTP or telnet login. If that happens, all bets are off anyway.
I’m starting to think that some sort of compiled script, perhaps using C, would be best since it can’t easily be broken even if a hacker obtains it.
Well it would help, but last I heard C code *can* be decompiled. :-) But first one has to get into the system to see those files.
rocknbil covered the essentials pretty well.
i would stress once again to read up on sql injection attacks and point out specifically that the vertical bar is probably the most dangerous character out there so make sure you "wrap that rascal".
That would prevent two things, one the hacker having easy access to the url of the perl script. Two hacker having easy access to the hash code to enter as input for a keygen, and maybe the complete registration field as well.
One thought I have is to make the script reliant on some value stored in the database. Say part of the hash key is in there. In this way simply hacking in and ftp downloading the script won't work.
