If you want to uncomment your PHP Code, have a look at my script:

https://gist.github.com/1375986

Usage:

The script will read the content of the file, remove the comment, and write back to the file.
So the file will be CHANGED! You have been warned.

The output of the script should be the following:

stdClass is really just a wrapper around a array that can be casted to a array.
Good thing about it is, you can extend it with some failsave __get($key) function.

GistHub:
https://gist.github.com/1101526

References

Maybe i should first tell you something about references in PHP:
Normally, you do not use any of them in your code. You need to use the "&" Operator to create references.
Maybe take a look at the following code to understand:

Object Destructors

Another important point to know is, when does PHP call the destructor of a object?
PHP does reference counting, that means, if there is no reference pointing at a object, the garbage collector will destroy the object, but before he does so, the __destruct() method of the object will be called.
Some example code for understanding:

Concept

If i combine the two things we know now, how about using references to do some normally impossible things? Like using something to manage references and use our destructor to manipulate the reference that pointed to us before we get destructed?

I realized this with some code you can find here: https://github.com/JuliusBeckmann/PHP-Reference-Fun

To do so, created the following classes:

ReferenceManager
This static class will collect references, we might use again.

ReferenceType
A abstract class that uses the ReferenceManager to manipulate the outside reference that pointed at us before we got destructed.

Idea: Write protected objects

WriteProtected extends ReferenceType
This class uses the ReferenceType destructor call, to recreate itself via the outside reference fetched from ReferenceManager.

Take a look at the source code to fully understand: ExampleWriteProtected.php

Idea: Static typed objects

AbstractStaticType extends ReferenceType
Another thing to know, when our destructor get called, there is no outside reference to out object any more. If there was only, the value it pointed to got overwritten by the new assigned value.
This can be used to manipulate the new value to something we want to have.

Take a look at the source to fully understand: ExampleStaticTypes.php

Conclusion

This whole concept is just a idea proven with some experimental code.
I think there could be several more useful things that can be done with this concept that might help in real life coding hell, but till now, i will just look at it as a neat idea to keep in mind for later.

I tried to keep the class as simple as possible, but it should be universal and powerfull enough for easy handling. Some ideas i had before writing code:

Thoughts

• Methods should be named like the curl_* PHP functions
• Using CURL* constants and values directly
• External access to the handle
• curl_multi_* possible
• Straight forward, no extra logic where possible
• Using all curl_* functions available

Code

You can find the code on github;
https://github.com/JuliusBeckmann/Whiz-Framework/blob/master/Whiz/Http/Client/Curl.php
License is new BSD.

Examples

Instead of explaining the code now, i just give a example using as much methods possible:

Advanced examples

And some more advanced example code:

What happened

• I wrote a new article and watched the preview of it.
• Digg-Digg showed the buttons on the preview page.
• I published the article and tried the Like Button.
• The Like Button did not use the correct url, in my case: juliusbeckmann.de/article-name.html instead of juliusbeckmann.de/blog/article-name.html.

Explained

While watching the preview, die like button send the preview url to facebook. Now facebook tried to fetch the page, but was redirected because the article was not published yet. Facebook "guessed" a url and came up with "juliusbeckmann.de/" what got cached.
Now i published the articled, used the like button, but facebook does not use the new url, they used the old guessed and cached url from the preview.

Solution

Solution is simple: Do not show the facebook like button on preview pages that will not be visibile for facebook.

Hack for Digg-Digg

Hacking Digg-Digg is simple. Open the file "digg-digg.php" and find the function "dd_hook_wp_content".
Now replace this code:

with this code:

$_GET Vulerabilities

str_replace() validation

The str_replace() validation is still vulnerable against a directory change attack.
Simple hack would be:
index.php?file=....//somefile.php
Explanation:
str_replace() does not double replace. If you want to do so use code like this:

Another example for wrong str_replace() usage:

It is the same problem like above and easily hackable:
index.php?file=hhttp://ttp://www.google.com/

Suffix/Prefix validation

Adding a prefix and a suffix is good, but still vulnerable.
Possible hack:
index.php?file=../../../../etc/passwd%00
Explanation:
The "%00" is a nullbyte, so the internal representation of a zero. Everything behind the nullbyte will be ignored.
The the real command will look like this:
include('/path/../../../../etc/passwd');
On many systems this will include the /etc/passwd!

SQL validation

This is very dangerous! The $_GET value can be changed in the query and can give controll over the SQL query!
A simple fix could look like this:

Still not perfect but secure.

More

You have some more examples?
Let me know them! Thanks.

Möglichkeiten:

Einfache Neuzuweisung des inkrementierten Werts:

Der Wert von $i wird genommen, um eins erhöht und dieser Wert dann wieder in die Variable $i geschrieben.

Die 1 wird genommen und der Wert von $i dazuaddiert. Dieser Wert wird dann in$ i gespeichert. Achtung beim dekrement, hier entsteht ein Vorzeichenwechsel.

Ein Kurzschreibweise für $i = $i + 1;

Der Variable $i wird eins hinzuaddiert. ++$i wird auch Pre-Inkrement genannt, da es (pre = vor) vor der Verwendung angewendet wird. Erklärung was "pre" genau bedeutet:
$i = 1; echo $array[++$i]; => Es wird auf den Wert von $array[2] zugegriffen. $i hat danach den Wert 2.

Der Variable $i wird eins hinzuaddiert. $i++ wird auch Post-Inkrement genannt, da es (post = nach) nach der Verwendung angewendet wird. Erklärung was "post" genau bedeutet:
$i = 1; echo $array[$i++]; => Es wird auf den Wert von $array[1] zugegriffen. $i hat danach den Wert 2.

Benchmark:

Welche der Möglichkeiten ist die schnellste?
Für den Benchmark habe ich diesen Code verwendet:
--- wird nachgereicht ---

Als Ergebnis habe ich auf meinem Eee mit Atom N280 und Ubuntu 9.04 bekommen:

Ergebnis:

Man kann deutlich erkennen dass die normalen Wertezuweisungen mit $i + 1 langsamer sind als die Post/Pre oder Kurzsyntax-Varianten.
Bei den beiden langsameren Varianten muss der Computer zusätzliche Lade und Speicheroperationen machen welche bei den schnelleren drei Varianten entfallen können. Dazu gibt es meist eine in- und decrement Funktionen in Machinensprache welche dies nochmal wesentlich beschleunigen kann.

Wenn man mit der Post, Pre oder Kurzvariante Variante arbeiten kann sollte man diese immer bevorzugen. Es gibt auch Optimizer für PHP die teils an solchen Stellen ansetzten um noch etwas mehr Geschwindigkeit zu erreichen.
Mit diesen Ergebnissen im Hinterkopf könnte die nächste Schleife ein bisschen schneller werden.

Lets start with the baaad examples:

The user we have is named "Bob", he likes to use his password "donuts".

Force users to use secure passwords

This is the first point where we have to interact. It does not matter how good our system will encrypt or hash Bobs password, with a simple one like this it does not make sense at all. We need to force Bob to use a more secure password. Good password contain of upper and lowercase letters, numbers and maybe even special chars. But this is not the subject of this article, so we continue with our bad examples.

We forced Bob to use a more secure password like "IlikeD0nuts".

Plain text passwords

The simplest way to store and validate Bobs password would be saving it "as is". The only good thing about this method is, we can send him his password back in case he forgot it. (Hint: If you ever use a "Remember password" function and they send your plain password back, the used some kind of this bad technique.)
The bad thing about this is, if a attacker gets read access to the database, he can read out Bobs password. The attacker is now able to login as Bob and do whatever he wants with Bobs account. If Bob has used the password also for his Email account or anything else the attacker can find out, Bob might get in serious trouble.
As you can see, storing plain text passwords is very bad and should NOT be done.

MD5 / SHA1 passwords

The next better way to store a password, is NOT to store the password. Yes, do NOT store the password, store something that is equivalent to the password but cant be reconverted to the password again.
This one way encryption method is called "hashing". Most famous and versatile hashing methods are MD5 and SHA1. Both can do a one way encryption like this: The MD5 of the string "abc" is: md5('abc') = 900150983cd24fb0d6963f7d28e17f72. The MD5 of "abc" will always be 900150983cd24fb0d6963f7d28e17f72. But if only one char changes, the MD5 will also change. md5('abd') = 4911e516e5aa21d327512e0c8b197616. So this function can create a hash out of a string which is "unique" for this string. But there is NO function like this: unmd5('4911e516e5aa21d327512e0c8b197616') = "abd" because it is a one way encryption. Like a one way flight, you cant get back home when you are at your destination.
You can play around a little bit with these function on: http://php-functions.com/
This feature of a hash can be used to validate a password. So if Bob registers his new account, we do NOT save his password "donuts" in our database, we save md5('donuts') = 6c493f3632cf8c85348ebd89d1e3cafa. A attacker cant see directly what 6c493f3632cf8c85348ebd89d1e3cafa means. If Bob wants to login, we just have to check if md5($password_bob_entered) = 6c493f3632cf8c85348ebd89d1e3cafa. When it is true, Bob must have entered "donuts".
This way of saving password is the first step in the right direction, but still no good practice. The problem is, that a MD5 will always be the same for a specific string, this hole is used by several online pages and programs to reverse a md5. Just search for "md5 cracker" and you will find tons of ways for cracking MD5 or SHA1 hashes. This plus the fatal use of simple passwords like "donuts" (Google: "donuts") will make cracking only a matter of time. So once again, storing simple MD5 or SHA1 hashes is NOT secure.

MD5 / SHA1 hashes with salt

This technique is similar to the previous, with one difference, store something additionally called "salt". Like salt in a soup this extra string will make cracking password catchier. The procedure goes like this:
Bob registers with his password "donuts". We generate a random(!) salt, like "8ft$U3", and will hash his password like this: md5("donuts"."8ft$U3") = 9aaa94551048442a835f5ae875687714. Now we save his name, the salt and the salted password hash in our database. The clever ones of you might have noticed, we just made a secure password out of the simple "donuts". This technique is popular today and sometimes called "good practice". But this is dead wrong. In times of multicore CPUs and incredible fast graphic cards, breaking such a salted hash needs, if the password is not too complex, only a few hours. Current highend graphic cards are able to calculate billions of md5 per second, so breaking thousands of hashes is only a matter of time before a attacker can start his raid against all the cracked user account. So do NOT use simple salted hashes.

MD5 / SHA1 hashes with salt hashed multiple times

As we learned from the previous technique, cracking hashes is only a matter of time. So what takes cracking hashes longer? It is complexity. We can add these complexity by rehashing the hash again and again till we reached a level where cracking such a hash will take ages.
I wrote this PHP class for demonstration, you can use it wherever you want, but keep the copyright header:

PHP Secure Hash Class

The class is using everything what makes a hash complex enough to save it from being cracked. Salts are completely generated from special chars. Salts are random. Hashes are rehashed random multiple times. The whole hash is stored in a special format which can be saved easily in a database. The format looks like this: $method$salt$iterations$hash$.

Ideas for even more secure hashes

I wrote about storing hashes in a database. The common way nowadays for an attacker is to find a SQL injection to read out your database. This is a major hole in security of websites. The whole password verification data is stored inside a database. My idea is to add another vector to this data which is not saved inside the database. Something like a global salt for all password hashes. This way, a attacker needs access to the database and to the source of the config files.
This idea is also implemented in my secure_hash php class.

Pitfalls of password hashing

There a a few pitfalls you have to care about when using hashes.

First, the charset of the password string is important. You have to understand how a hashing function works. It is not just randomizing a string and producing some chars. A hashing function does NOT work with chars, it works with their byte interpretation. It is also possible to create a MD5 from a file. So if your website is using the LATIN charset, your passwords will be hashed with the LATIN byte interpretation of these chars. If you use UTF8, these hashes can be completely different! A example: the umlaut 'ä' is in LATIN "961fa22f61a56e19f3f5f8867901ac8cf5e6d11f" but in UTF8 is is "89d39ea0600180286a2f794d8b2c4d5b02450ed9". Keep this in mind if you want to change the charset of your site.

Check for system chars! If i say system chars, i mean things like blanks, tabs, newlines and carriage returns. For example the string 'a' will be this SHA1: "89d39ea0600180286a2f794d8b2c4d5b02450ed9", but the string 'a ' will be "9384a39d69d104db5d1db7ccceae2ce0cb6c01c2".
To reduce this risk use the trim() function to remove this chars from the passwords.

Other Algorithms than MD5 or SHA1 (Update)

Jani Hartikainen mentioned in his comment, that there are more algorithms than just md5 and sha1 and some of them are very slow compared to md5.
That is a good point, which has some up and downsides.

Using a uncommon algorithm brings more security, because a attacker might not know the algorithm or have a tool for cracking it. Also is a slower hashing routine a problem for the attacker.

There might be a problem with uncommon algorithms, if you want to move to an other hoster, he might not support your hashing routine.

If you want to use something else then MD5 or SHA1, just have a look at MHash or Hash PHP modules.

If you want to use your own hashing method, my PHP Secure Hash Class supports it. Just have a look at the example class "secure_hash_example".

Personally, i would not use something like whirlpool, tiger or haval, because they create dependencies which make the whole system more complex. I would let the simplicty win here.

I hope you learned how to store passwords secure and will make the Internet a safer place.