In this article, guide or tutorial (call it whatever you want), you will se what the hosters and developers should do to avoid the major security risks when using a *nix system and PHP + MySQL. This do cover the basics of PHP and MySQL security and will tell you methods to avoid the most used hacking attempts.

Safe_mode

Safemode activates a couple of settings that will:
* Force PHP to check UID permission before opening files.
* Prevent some calls, such as system(), from working. This is unless safe_mode_exec_dir is set.
* Set open_basedir to allow hosters to force file access to stay within a virtual directory.

There are though ways around safe_mode. Most PHP exploits use methods to get around the safe_mode restrictions.

One tips for the hosters is to not just turn on safe_mode without knowing what the actions are. You are not safe just because you turned on safe mode.

Safe Mode has also been removed totally in PHP 6.0.

Magic quotes and addslashes()
Lot’s of people recommend the use of addslashes(). This is however a prety poor advice today when connecting to a mysql database.
To prevent SQL injections, the best thing to do is to use a combination of methods. However, the best method is definately to use PDO or mysql_real_escape_string(). As a hoster, you should quickly upgrade to the latest PHP version to encourage safer and more secure functions for the users and their software.

So - how do I know if I’m vulnerable?

If the users can do remote code execution, you are in fact lucky if you’re still alive.
How do you see if you allow this then?
One thing could be if you check if this works on your site:

$file = $_POST[‘file’];
include $file;
</php>
or this
<pre lang="php">
$txt = $_POST[‘txt’];
eval(“echo $txt”);

Other functions that can be dangerous are fopen, fsockopen, popen and system. The last two functions are direct command execution and allows remote attackers to execude code on the system.

If you want to protect yourself against this you can as a DEVELOPER:
Control that all your $_POST and $_GET arrays are secure and that file operations such as includes/requires, eval statements and every type of file operation is validated before use.
When you write new software you should limit the use of dynamic inputs as this is the most common security whole in php scripts.

As a HOSTER you should, to provide security, disable allow_url_fopen in the php.ini, enable safe_mode and set open_basedir restrictions.

XSS - Cross-site scripting

Another huge and commonly used security whole is XSS or Cross-site scripting.
This refers to HTML injections or user agent injections which can effect all types of servers. This doesn’t hurt the server itself but makes the site leak information and the users that access the website can bring their information to wrong parts, such as their credit card or password.

An insecure output can look like this:

echo $_POST['text'];

While, if you want to be atleast quite secure, you can use the function htmlentities.

Developers
* Switch off register_globals and make sure that all the variables are properly initialized.
* Take user input from correct location, ie $_POST or $_GET, rather then relying on register_globals or $_REQUEST.
* Validate user input for syntax, length and type.
* Text can only be visable after using HTML entities.
* Variables that are sent back should be URL encoded using urlencode().

Hosters
Hosters can’t configure the server to be XSS (cross site scripting) safe but can remove all applications that have XSS attacks in their history. This means that the developers has to have XSS protection or their software will not be used at all.

SQL Injections
The most common and widely used hacking attempt is to use a SQL injection.
What can the developer do to protect the site and server from any SQL injection then?

* Validate the data when having dynamic SQL queries.
* Use PDO (Included in PHP 5.1 and later)
* At least use functions like mysql_real_escape_string().

Nowadays every developer should migrate to PHP 5.1 and use PDO since it has a SAFE SQL interface wich avoid all these issues.

addslashes() is not enough to avoid injections.
The php magic quotes, which automatically adds slashes to input data on the basis of database destination, is not enough as a security method either.

Developers
* Migrate to PHP 5.1 and use PDO.
* Use mysql_real_escape_string()
* Validate the data!
* Have a .htaccess file to ensure that register_globals and magic_quotes are forced off to provide properly initialization anv validation for the inputs.

Hosters
Provide PHP 5.1 and PDO for their clients. Configure MySQL to be the most secure as possible. Users should not be granted admin privileges and the database should be running in a chroot environment to avoid as much damage as possible if a successful attack has reached.

PHP Configuration

It is quite suprising that there is no real secure PHP configuration by default. Here’s a list of settings that should be set:
* register_globals (off by default in modern PHP, should be set off)
* allow_url_fopen (enabled by default, should be set off)
* magic_quotes_gpc (on by default, should be set off)
* magic_quotes_runtime (off by default, should be set off)
* safe_mode and open_basedir (disabled by default, should be enabled and configured correctly. But be aware that safe_mode isn’t really safe and can be totally useless)

Developers should during installation test using ini_get() for common hosting mistakes such as allowing things usch as register_globals or magic_quotes_gpc.

Summary

What can the developers and hosters then do to make sure they are safe towards hacking? It’s not possible to be bulletproof in this business, but if you keep your software up to date and make sure all the common mistakes are undone you will in general be safe. Here’s a compilation of what the developers and hosters should think of when securing their scripts and systems.

Developers
* Ensure that all variables are properly initialized before use.
* Ensure that the users only can affect file operations to the degree you had in your mind creating the function.
* Ensure that your scripts are totally compatible with safe mode restrictiongs and will work under things such as suPHP.
* Move the secrets and logs out of the web roots if scripts are supposed to work on a shared hosting environment.
* Use PDO for MySQL queries.
* Validate the data with length, type and every kind of method you can think of.

Hosters
* Enable safe_mode (be aware that it though isn’t really safe and can be useless)
* Use open_basedir restrictions!
* Make sure that users have a place outside web root to store logs and secrets.
* Run PHP under a least privilege model, as a user or via use of PHPsuExec or suPHP.

Google recently released a new REST API which will replace their old SOAP API (which they haven’t given out keys for since 2006)

This is very good news for those who want to do searchqueries “server-side”.

Documentation: http://code.google.com/apis/ajaxsearch/doc…entation/#fonje
Video: http://google-code-updates.blogspot.com/20…om-outside.html

Google släppte igår ett nytt REST API som skall ersätta deras SOAP API (som de slutade att dela ut API nyckar till 2006):

Here’s some PHPcode of how to use this API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
$url = “http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=Hello%20World”
 
// sendRequest
// note how referer is set manually
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_REFERER, “http://www.knark.com”);
$body = curl_exec($ch);
curl_close($ch);
 
// now, process the JSON string
$json = json_decode($body);
// now have some fun with the results…
?>

Tavis Ormandy is the guy from the Google Security Team who “makes it happend”.

He’s a researcher on the Google Security Team and faces the unpleasent responsibility of passing all googles products pass the security tests. Tavis is also an open-source contributer, working as a co-lead of the Gentoo Security Team as well. He is one of the faces that should make the Linux Gentoo distribution safe.

In September 2006, Tavis reported vulnerabilities in the gunzip decompressor on behalf of Google. Here is the link to the report made by Tavis: http://www.scary.beasts.org/security/tavis_gzip.txt

He has also discovered lot’s of other vulnerabilities such as PCRE (Perl Compitable Regular Expressions) and Perl Unicode Regular Expression buffer overflow. Links to these hacks can be found here: (PCRE) (UNICODE)

Summary: We should be glad of Tavis work since he’s making the web and the servers safer by contributing and telling the software creators before making the exploits public.

Here’s some collected links that can be interesting:
Tavis Ormandy’s blog
Secwatch profile
Milw0rm profile

Since PHP 5.1.2 the hash function is enabled by default. To create a sha256 hash you simply write:

hash("sha256", $data, false);

There you have your sha256 hash!

SQL injections are common nowadays and plenty of sites get hacked because of insecure database calls.

Making it bulletproof against injections is hard and will take time, but making safer calls are essential and doesn’t take that long to make.

So, what is a SQL injection?

To clearify it I will give a very easy example:

A database may look something like this:
ID | USERNAME | PASSWORD

When you make a call to that database your query can look something like this:

SELECT * FROM database_name WHERE id = '2'

So far no problems.. But when you code it, it will be something like this (the insecure way):

$sql = "SELECT * FROM database_name WHERE id = '".$_POST['id']."'";

If you make that query and has a id that is “2″, there will be no problem, but if you change it to something else, you will get some problems.

What if $_POST[’id’] would contain something like: ‘ or 1=1– ?

The query would now be:

$sql = "SELECT * FROM database_name WHERE id = '' or 1=1--";

That would automaticly select the whole database since that “or 1=1″ definetly is true.

That was a very short description of what a SQL injection is so how can we now prevent without using any PDO? Using PDO may be the most secure way but requires more knowledge too.

Three lines of code will secure your code against the most known injections and will make it a lot harder to inject your site and hack it. One of this lines will take care of XSS hacking methods too:

1
2
3

$_POST = array_map("htmlspecialchars", $_POST);	# Will secure from XSS
$_POST = array_map("trim", $_POST); # Remove spaces before and after posts
$_POST = array_map("mysql_real_escape_string", $_POST); # Protects from most known SQL injections

Just add these lines in the top include file and you will always have your $_POST protected from the most known SQL injections. One easy way of securing your web applications a little further.

Since a couple of Swedens largest sites got hacked and the passwords are floating across the internet, we thought writing a small guide of how to not do the same mistake as those people have done, not using any salts. So, first of all, what is a md5 hash?

MD5 stands for Message-Digest algorithm 5 and has a 128bit hash value. An MD5 hash is typically a 32-character hexadecimal number. At first, there were problems cracking MD5 hashes, but in later time there have been something called a “rainbow table” which easily can crack md5 hashes. So, what to do to protect ourself against those rainbow tables? Use something called a “salt”. The reason why you have to add salts is because lot’s of people are using words such as “mydamncatsname” or “ilovejesus” which hashes have been generated and then if you compare your databases password-hash against the generated list, you will find out which password you have in your database. If you then have a salt such as “fsjlk4u9pfs” and the hash would generate the word ilovejesusfsjlk4u9pfs or something, which is not likely at all that a dictionary will have.

So how to implement this salt then? Does it involve some tremendous programming effort? No. It’s the easiest thing you can do.

To simplify this, heres a code snippet of how a salt works.

1
2
3
4

<?php
$salt = "kfoe56";
$hash = md5($salt.$password);
?>

That is a static salt, which is better then nothing, but not far as good as a dynamic salt. There is absolutely no reason why to use a static salt since it’s not any harder to create a dynamic salt.

A dynamic salt can be something that uses the userid or something like that. This is a pretty good example of how a dynamic salt can be used:

1
2
3
4

<?php
$salt = $userid;
md5($salt.md5($password.$salt));
?>

The time to crack that password is by far longer then a normal hash.

So please, use some damn salt when you store your users passwords.

Cdsrc will summarize the popularity in programming languages in the early 2008. This list is based on TIOBEs programming community index.
To summarize it first: Java is leading. If you take both C and C++, they would have the lead, so our conclusion is that C/C++ is slightly more popular then Java. This list is basicly based on how much resources there are available for each language which means that languages such as PHP get lots of attention. Even though PHP is a very popular language, it has it’s drawbacks when it comes to perfomance issues which means that it can never be used in a high-performing software.

The language “Lua”, which most people never heard of became known when they included it in WoW (World of warcraft). You can script some simple scripts to increase your abilities (your own, not your characters) in WoW.

Visual Basic has also made an increase through the last months, possibly because of Windows Vista. Another interesting jump was made by Python. Python has passed both Perl and C# and the curve is showing even further increases.

The language with the most interesting future could be Ruby, which has backed down a little bit, but has a lot of interesting techniques that got to get rewards at some time.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Java 	20.849%
C 	13.916%
(Visual) Basic 	10.963%
PHP 	9.195%
C++ 	8.730%
Python 	5.538%
Perl 	5.247%
C# 	4.856%
Delphi 	3.335%
JavaScript 	3.203%
Ruby 	2.345%
PL/SQL 	1.230%
SAS 	1.204%
D 	1.172%
COBOL 	0.932%
Lua 	0.579%
FoxPro/xBase 	0.506%
Pascal 	0.456%
Lisp/Scheme 	0.413%
Logo 	0.386%

This was the list of the top 1-20, now to be followed by the 21-50:

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

ColdFusion 	0.353%
ActionScript 	0.342%
Ada 	0.337%
Fortran 	0.305%
RPG 	0.251%
MATLAB 	0.241%
Awk 	0.213%
Prolog 	0.212%
ABAP 	0.195%
LabView 	0.169%
Groovy 	0.168%
Transact-SQL 	0.155%
Smalltalk 	0.133%
Bash 	0.133%
Tcl/Tk 	0.130%
Haskell 	0.119%
Forth 	0.116%
CL (OS/400) 	0.114%
Natural 	0.105%
ML 	0.092%
Focus 	0.091%
Ch 	0.088%
PL/I 	0.088%
Lingo 	0.087%
Factor 	0.084%
REXX 	0.075%
Objective-C 	0.071%
0.059%
Erlang 	0.057%
VBScript 	0.056%

The web is evolving like never before and HTML 4 has been around for almost a decade. Developers and publishers want a new technique to provide enhanced functionality.

To give us, the publishers, more flexibility, HTML 5 will introduce a wide range of new, exciting features such as form controls, APIs, multimedia and some new structure.

The work on HTML 5 started 2004 is held by W3C HTML WG and WHATWG. There are also a couple of other representatives from the major browsers; Mozilla, Opera, Microsoft and Apple.

HTML 5 is still a work in progress and got plenty of more developing hours left before release. This article is written as a brief of “What to come” for all us, the developers and publishers.

The HTML 5 structure

Allmost all HTML 4 pages is dividing the pages into headers, footers, containers, sidebars, contents, etc. Yeah, you name it and they have it. In this case we use what is called a “div element”. In the new HTML 5, we are introduced to new elements that represent this sections. Instead of using:

<div class="header">

We can now use another method, which structures it all far better:

<header>

A theoretical page could in HTML 5 look like:

<body>
  <header>This is the header text</header>
  <nav>This is our navigation</nav>
  <leftsidebar>This is our left sidebar</leftsitebad>
  <content>This is the main content</content>
  <rightsidebar>This is our right sidebar</rightsidebar>
  <footer>The footer..</footer>
</body>

I think you get the point here..

The video and Audio elements

Since the startup of sites such as YouTube, the demand of good video and audio elements have been increasing. HTML 4 is lacking in the matter of successfully embedding and controlling multimedia. Therefore, most sites have been using flash to provide with those functionalities. Flash is currently the only widely used plugin which is cross-browser compatible and have the desired APIs for the developers.

The new HTML 5 video and audio elements have the purpuse of making this easy. Opera has already released a build with partial support for video elements. With this, you use the video element and then the browser will provide the user with a default user interface. An example of code in this matter is:

<video src="myvideo.ogv" controls width="400" height="300">
   <a href="myvideo.ogv">Download my video</a>
</video>

The controls attribue is a boolean variable which asks whether you want the inbuilt browser UI or not. In this case, we want!

It’s also as easy to implement audio into the page. The attribues between

<audio src="mymusic.oga" controls>
   <a href="mymusic.oga">Download my video</a>
</audio>

As you see, it looks about the same.. Of course you cant choose the width and height of the audio-sample.

Another good idea of this new elements are that you can choose different sources of the media depending on what codecs the user have. To implement this action you just add another source, with another video type:

<video>
    <source src="myvideo.3gp" type="video/3gpp" 
    media="handheld">
    <source src="myvideo.ogv" type="video/ogg;
    codecs="theora, vorbis">
    <source src="myvideo.mp4" type="video/mp4">
</video>
<audio>
  <source src="mymusic.oga" type="audio/ogg">
  <source src="mymusic.mp3" type="audio/mpeg">
</audio>

Some more resources on this project can be found here:
* Event Streaming to Web Browsers (Opera)
* Improve your forms using HTML5! (Opera)
* An HTML5-style “Google Suggest” (Opera)
* Making legacy pages work with Web Forms 2 (Opera)

* http://www.456bereastreet.com/archive/categories/html_5/

The computer science portal csdir.org has published another good tutorial. This one is about hacking and tells us what an exploit is, how to compile one and how to use it. This hacking tutorial is of great use for newbies and avarage users. This site also has a couple of other great tutorials;

The bash tutorial which is a complete guide of how to use bash to script useful scripts. This tutorial is probably the best in the area.
It can be found here: http://csdir.org/tutorials/bash-tutorial/

The third tutorial they offer is the Ansi C tutorial which is a great starting tutorial for programmers that want to know more about the C programming language. The ANSI part is just meaning the American National Standards Institute.

We on cdsrc really recommend those three tutorials.

Hackers have started to exploit a vulnerability whole in Apples software Quicktime. This whole is still not fixed since Apple has not yet released a patch.

So far are only Windows-users targetted, but Mac-users are not safe either. The vulnerability whole was discovered 23 November and was achieved because Quicktime doesnt validate incoming data securely. This time it’s connected with the rtsp protocol which is used for streaming video.

The hackers can with this method make a takeover of the targetted computer. Failed attacks will cause DOS (denial of service) conditions.

The hack itself is a buffer-overflow that targets the Header Content-length.

For more information of how to secure it, take a look at symantec.

The code for the hack itself can be found at milw0rm.