Example:

function foo() {
    $a = 'bar';
    return $a;
}

Try this, instead:

function foo() {
    return 'bar';
}

Simple, but this drives me nuts, and I see it all of the time.

C++ Web applications are not going to be a game-changer. If this were true, it would have happened a long time ago. Will I forget about PHP? Of course not! Many (probably most) shared hosting solutions won’t even allow you (with very good reason) to execute arbitrary binary files on their servers. Mine won’t. You also can’t (to my knowledge) do this technique on Windows servers.

I WILL, probably, write a few C++ web applications to run on my laptop, just because I’m a nerd, and the satisfaction I’d get if from just knowing every time I hit the Home button, I’m seeing web pages dished up by a C++ script… I’ll stop there.

What kind of solutions do I see this as a replacement for PHP (or Ruby, or Python, or ASP, or JSP, or whatever you use)?

• You are looking to build a robust web application to be run on your own private web servers.

I’m thinking, if Twitter was written in C/C++, we wouldn’t have as many Twitter-outages .

• You are looking to build a high-end distributable web-based software package.

For example, a software package, where the codebase sits on a server, and clients (or internal employees), interface with it through a web browser. Now we’re talking APPLICATION, more than just a website.

• You are looking to build a web application, and have the ability to run arbitrary binary scripts on your server (such as a private server), and runtime speed is crucial.

With FastCGI and precompiled binary scripts, well-written C/C++ code will trump compile-on-the-fly approaches of PHP, Perl, Python, etc. (Of course PHP has memcache..)

Enough jibber-jabber. Let’s create a C++ CGI script! First, you’ll need to configure Apache to execute CGI scripts. It’s general practice (but you may not care.. I don’t) to create a single directory, and only allow CGI scripts in that directory to be executed. You’ve probably seen a lot of cgi-bin/ directories on various websites. Let’s say we create a directory at /var/www/cgi. In this directory, we’ll put our CGI scripts. Let’s tell Apache.

You’ll want to edit your httpd.conf file (on Ubuntu, it’s in /etc/apache2). Add this (as root/sudo):

<Directory /var/www/cgi>
    Options ExecCGI+
    AddHandler cgi-script .cgi
</Directory>

The Options ExecCGI+ line is the one that allows CGI scripts to be executed. If instead of using a single directory, you opted to make the whole ServerRoot allow CGI scripts (like I did), you’ll want to make sure the Options aren’t overridden elsewhere in the server conf. Namely, check for something in /etc/apache2/sites-available/default (or where ever else your system may store Apache config). In this file, You may see another <Directory> block for your server root. Add ExecCGI to the Options list.

You can also create arbitrary file extensions for your CGI scripts with the AddHandler directive. Imagine the possibilities.

Now, restart Apache. On Ubuntu:

sudo /etc/init.d/apache2 restart

When Apache comes back up, you should be ready to roll. You may feel like throwing in a test Perl script before we get to the C++, just to make sure things are working as expected. If you aren’t a Perl Monk (most of us aren’t), do this:

which perl

Will tell you where perl is installed (if at all). It’s probably /usr/bin/perl. So then, create this Perl script:

#!/usr/bin/perl

print qq(Content-type: text/html\n\n);
print qq(Hello, world!);

Make sure to chmod that bad boy to at least 755, and hit it in the browser, you should see “Hello, world!”. If not, you probably got one of these:

• You saw the perl code

That means the CGI script didn’t attempt to execute, check back over the steps, make sure you restarted Apache.

• You got Forbidden

You either aren’t allowed to execute CGI scripts, or didn’t get the right permissions.

• Internal Server Error

Perl code is probably messed up. Check out tail /var/logs/apache2/error.log for what SHOULD be a more detailed error message.

• File not found

You probably have a typo in the filename or the address bar .

Well, hopefully you have that working now, lets throw down some C++ code.

I’m not going to teach you C++, so if this code doesn’t make sense, you should look into learning C++ before approaching this technique (obviously).

#include <iostream>
#include <cstdlib>

using namespace std;

int main() {

	cout << "Content-type: text/html\n\n";
	cout << "Hello World (Wide Web)<br />" << endl;

	cout << getenv("REMOTE_ADDR") << endl;

}

Save this as hello.C, or whatever you want.. and compile the code:

g++ -o hello.cgi hello.C

Now, make sure that hello.cgi is in /var/www/cgi (or wherever you specified), and hit it in the web browser. You should see an output something like:

One of the biggest pitfalls I can foresee, is that server-side scripting is not an interactive technique. Thats why scripting languages are perfect for dynamic web pages. C++, not being a scripting language by nature may cause you some headaches. Just be sure to write smart, efficient code.

You can also download a C++ CGI library, to help out with accessing header data, such as Cookies, GET and POST variables, etc. Here is a link to an ANSI C library for CGI Programming.

There are many possibilities and issues here. Dynamic web applications are generally written in a client-side scripting language. The nature of these scripting languages is to compile on-the-fly. This means you store the code, in plain-sight. Not very good when you’re trying to sell software, and anyone who purchases it has the ability to reverse engineer your product.

Some technologies, such as JSP, allow you to compile the code down to bytecode, however, by nature of its design, Java bytecode is compact and simple to reverse engineer. Encryption techniques such as ZendGuard are crackable (unencryption has to happen somewhere). ActionScript (Flash) is promising, it compiles down to binary SWF files, however, tools exist to convert these SWF files into their FLA counterparts.

There may be no guaranteed, fool-proof way to protect your code, but one thing that has obviously worked well for stand-alone software vendors is binary compilation. Great, so how do I compile my web code to binary? Simple! Just write your web applications in C/C++ (or other language that compiles to binaries), and run them as CGI scripts.

I had a major AH-HA moment, when I realized that all a CGI script needs to do, is print out the content MIME type, and the actual content, Apache will take care of the rest. This approach will only work on Unix based hosts, as Windows does binaries a little different (suckers). But as the vast majority of web hosts run on Unix, this isn’t a huge deal.

I’m going to create a 2nd post, demonstrating this technique. Look for it in the not-so-distant future.

Update: The 2nd post is up! Running C/C++ Code as a CGI Script

Prepared statements are immune to SQL injection attacks. That’s right, immune. When you use prepared statements, you don’t have to worry about properly escaping inputs, it is handled for you.

Aside from the security, prepared statements when you want to perform a query multiple times with different parameters.  The structure of prepared statements is intended just for that.  In fact, its the idea behind prepared statements.  Prepare the statement, run it several times with new sets of parameters.

The downside of prepared statements is the execution speed. Before the query can be executed, it is “prepared” and parameters must be bound. In a high-load setting, the increased execution time might be noticeable, but for average instances, its negligible.

When digging through old, crappy code, it is pretty common-place to see developers incorrectly using prepared statements. How is this possible? Is it a vulnerability issue? Well, one of the main ideas behind a prepared statement, is that the statement may need to be executed several times, but the statement only needs to be “prepared” once. If you have a loop which executes a query, prepare the statement before entering the loop. Inside the loop, you bind the parameters and execute. Don’t prepare the statement inside the loop.

Preparing a statement is a string manipulation, doing it multiple times is extra load on precious CPU time. I created a simple MySQL schema and PHP script to test this scenario, to get an idea of the extra execution time resulting in this improper usage of prepared statements. The table I used simply had 3 fields:

id int unsigned not null auto_increment primary key,
hash varchar(255) not null,
hashType tinyint unsigned not null

The simple table and the fact that my laptop has virtually no load meant that the queries ran FAST. 20,000 executions took place in ~3 seconds. I upped the number to 300,000 queries. Preparing the statement 300,000 times resulted in a script execution time of 35 seconds (average over 3 trials), and preparing the statement once and then executing 300,000 times resulted in a script execution time of 33 seconds (average over 3 trials).

2 seconds isn’t significant, no, but this was on a dual-core laptop which saw the load peak at 0.61 during the trials. Imagine this running on your shared hosting database. On mine, I saw a 3 second difference when only running 5,000 queries.

I also read up a little on the topic.  It turns out that Jeff Atwood posted a pretty similiar post a couple years back.  Jeff made an assertion that I should make as well.  Like Jeff, I am not a cryptographer, so don’t trust my advice like I am a security EXPERT.  He also taught me about rainbow tables.  Rainbow tables, in short, are a massive database of precomputed hashes.  With our hash inside of a hash technique, the final hash product is too long for modern rainbow tables to be effective.  This is great and all, but there are a few problems with my method.  One thing you need to realize when dealing with system security is there will almost ALWAYS be security holes.  We do our best to prevent them, but we can’t promise to be 100% successful.

I’m going to revisit the salted hash to create a better salting, hashing, hacker-hater method of storing passwords.  I’ll make another disclaimer-like notice first.  Most people use only a handful of unique passwords (and by handful, I mean: one.. or two) across a galaxy of login systems.  If you develop a system to store a user’s password it is your responsibility to store it in the most secure way you can.  I don’t recommend you use my salty hash method, I simply mean for it to be an enlightening moment of: “Oh crap, I should really think about how I’m storing my users’ passwords.”  There are always security holes.  I’ve already thought about one in my original.  I thought my method worked well, because the salt wasn’t exposed in the stored value. I liked this, but then realized a problem: two user’s with the same password will generate the same hash.  This is much the problem with storing a non-salted hash, and is the principle used in cracking hashes via brute force/rainbow table.  Hashing strings until the two generated hashes match.

Here is my improved method, in (PHP) code:

// our password this time, is a little bit stronger than ‘password’
$password = “#aBc.123@”;

// some alpha-numeric values and special characters, for use in our salt
$salt_material = “abcdefghijklmnopqrstuvwxyz1234567890 \”!@#$%^&*()_=+-{}[],./<>?;’:”;

// salt will be a string of random length, 1-9
$salt_length = rand(1,9);
$salt = “”;

//build the salt from our material at random choice
for($i = 0; $i < $salt_length; $i++) {
$salt .= $salt_material[ rand(0, strlen($salt_material)-1) ];
}

// calculate the hashes, and then reverse the strings
// not sure about the added strength, but I like the idea of reversing the sums
$salt_sum = strrev( md5($salt) );
$password_sum = strrev( md5($password) );

// now create the sum of our salt + password
$salty_hash = md5( $salt_sum . $password_sum );

// create a hash which exposes our salt, so we know what it was.
// since our salt_length is only 1-9, this information doesn’t have to be
// separated, its always the first char
$resulting_hash = $salt_length . $salt . $salty_hash;

// for added measure, an idea I read elsewhere.
// again, not sure about the added strength, but I like the idea of it
$secure_hash = sha1($resulting_hash);

// and now, the final result
$final_product = $salt_length . $salt . $secure_hash;

Now, each time the hash is calculated, it should be a unique value, however we should be able to recreate it (provided the user inputs the correct password).  Four runs of the script resulted in the following hashes:

7{5@a#@@f77a51b733b65590d284b990099fc764239fbd63
4n+b44c38fe32b4f9a095d7534610bce0f4d72d2976f7
9r{j&f2i”t9ea7035cf81de87a07980e9884d26db67e510728
4;xd”a9ff52b67313cc2d183b977226747a6685540a43

No hashing algorithm is completely unbreakable.  Hashing algorithms such as MD5 or SHA-1 have been shown to be breakable (MD5 much more easily than SHA-1), but storing the MD5 hash of a password is still SIGNIFICANTLY more secure than storing the plain text, or an easily crackable custom hashing algorithm.  Cracking an MD5 sum can take a few minutes, several hours, or even days, depending on the CPU power available, SHA-1 even longer.

We can create an even more secure hash by combining the efforts of a custom hashing algorithm and MD5 to create a unique custom hashing mechanism.  This is an example of how you should store your users’ passwords. We want to “salt” the original string, and then hash the salted version, and store only the hash.  When it comes time to authenticate a user’s login attempt, we run their input through the hashing function.  If the two hashes match, they’ve inserted the correct password.

Here is an example of such a custom salted hash:

Our string to be hashed is “password.” First, let’s come up with a salting mechanism.  For this example, we’ll use something simple.  The salt used has to be retrievable and positively recreatable. “Password” has 8 characters.  Lets take (in PHP)

$salt = floor(strlen("password") / 2);

That is the length of the string, divided by two, rounded down to the nearest whole number.  In our case the answer is 4.  floor() does nothing for us here, but if the string length is odd we want a whole number, and we want the same whole number every time a string of that length is used.

Now we have our salt, 4.  Let’s hash up the 4.

$salt_sum = md5( decbin($salt) );

I took 4, converted it to binary (results in 100), and found the MD5 sum of that as a string, the result is: f899139df5e1059396431415e770c6dd

Lets prepend that to our input string, “password” and find the MD5 sum:

$hash = md5($salt_sum . "password");

Now, our result is: c88e94b4d0f8e1c303f3b79d131a2d13 — and THAT is what we want to store.  Now we can recreate that, and now our MD5 sum is incredibly difficult to break, with the pre-hashed value containing a 32 character “random” string, plus the original 8.

Here are a few commands you’ll need to know to get started:

1. cd

cd stands for ‘change directory’ and is one you’ll probably use most frequently.  The syntax is very simple:

cd destination

A few tricks to know when working with this command:

cd ..

Changes to the directory UP one hierarchical level.

cd ../..

Changes to the director UP two hierarchical levels.. etc.

cd ../myFolder

Changes to a folder called ‘myFolder’ which is a subfolder of the current parent folder.  This is a relative path.

cd /

Changes to the root folder of the filesystem.

cd /var/www

Change to an absolute path.

cd ~

Change to your shell’s home directory.  By default, this is your system home directory, such as /home/yourUsername

cd ~/Desktop

Change to the Desktop folder under your home directory, equivalent to something such as cd /home/yourUsername/Desktop

2. cp

cp is the copy command, and is another frequently used command.  This is another command with very simple syntax.  Learning the syntax of cd is useful for using cp. The syntax is:

cp file-to-be-copied.php /destination/newfilename.php

Here are a few examples and tips for working with cp:

cp index.php home.php

Creates a copy of the index.php file, named home.php

cp index.php /someDirectory

Creates an index.php under the folder /someDirectory.  Not supplying the new name gives the copy the same name, index.php

cp someDirectory/ /destination/

Creates a folder ‘someDirectory’ under the ‘/destination’ folder.  This doesn’t copy any of the files, just the folder itself.

cp someDirectory/ newDirectoryName/

Creates a folder in the same directory with the name ‘newDirectoryName’ .. again, no files are copied just the folder (and its ownership/permissions). Apply a relative or absolute path before the directory name to create it somewhere else.

cp -r someDirectory/ newDirectoryName/

Creates a copy of the directory ‘someDirectory’ named ‘newDirectoryName’.  using the ‘-r’ flag will copy the folders contents “recursively.”

3. ls

ls is the command used to list all of the files in your present working directory.  It is as simple as typing: ls.  You can add flags for more views:

ls -a

will show you ALL files .. includes the hidden files (hidden files start with period, such as “.htaccess”)

ls -l

will show you the files in a list format. This method shows you more information about the file, such as the owner, the size, and the last modification date.

Combine the two flags, to get ls -al and you will see all files in a list format

4. pwd

pwd echoes out your “Present Working Directory” to the screen.  Cool.

5. rm

rm is the always useful remove command.  Type

rm filename.php

to remove the file ‘filename.php’. There are a lot of flags to be used with rm, but they can be dangerous. We’ll wait until you are more comfortable in the command line.

6. rmdir

rmdir is rm’s brother. rmdir clearly stands for “Remove Directory”.  You can only remove a directory that is empty.  If its not empty, you’ll first need to delete all of the files in the directory.  There are easier ways to remove things in bulk, or to remove non-empty directories, but as I said, they can be dangerous.  We’ll wait until you are more comfortable in the command line.

7. mv

mv stands for Move.  It is the command you’ll use to relocate files.  You can consider moving a file to be the same thing as renaming it.  Renaming a file from “fileA.php” to “fileB.php” is the same as moving its location to be “/directory/fileA.php to /directory/fileB.php.

Use mv as:

mv fileA.php fileB.php

to rename fileA to fileB.  Or you can use mv like:

mv fileA.php /some/other/dir/

to relocate fileA.php to /some/other/dir/fileA.php

This is all I have for now.  There will hopefully be more later.  Enjoy, n00bs

1. Iconfinder.net
2. WebDesignDev
3. GeoCities
4. Quirksmode
5. InstantDomainSearch
6. Cooltext (For those not so professional in photoshop or gimp)
7. Logomaker

That’s all I got right now.  This is what I use a lot for inspiration or resources.  You should already be  aware of most, if not all, of these sites.  Just giving them their due respect.