Keeping your website secure :)

[Moudi]

First of all lets talk about public exploits that are :

SQL injection.
XSS ( cross site scripting )
LFI ( Local file inclusion )
RFI ( Remote file inclusion )
Upload fields.

SQL injection

Most websites from 2005 are vulnerable to SQL injection. I will not give a tutorial on how to preform such an attack but here's how to know if you are vulnerable :

If you have any SQL links such as : news.php?id=1
Put a ' next to the one so it will be news.php?id=1'

If it gives an SQL array error than your website is injectable.

also login fields. If your field looks like this

<?php
$user = $_POST['u'];
$pass = $_POST['p'];

if (!isset($user) || !isset($pass)) {
    echo("<form method=post><input type=text name=u value=Username>
<input type=password name=p value=Password>
<input type=submit value=Login></form>");
} else {
    $sql = "SELECT `IP` FROM `users` WHERE `username`='$user' AND `password`='$pass'";
    $ret = mysql_query($sql);
    $ret = mysql_fetch_array($ret);
    if ($ret[0] != "") {
        echo("Welcome, $user.");
    } else {
        echo("Incorrect login details.");
    }
}
?>

Than it is injectable. A user can login as any other user including admins. all he has to do is insert any username in the user field and

* '
or

* 1=1--
In the password field.

For the Login field thing you can find alot of invulnerable login fields on Google .

Now for the id?=.. thing and how to avoid it .. here you go :

I) Presentation of the problem.
   ___________________________

There are two types of SQL injection:

* Injection into the variables that contain strings;
* Injection into numeric variables.

These are two very different types and to avoid them, it will act
differently for each of these types.

######################
The variables containing strings:
######################

Imagine a PHP script that fetches the age of a member according to its
nickname. This nickname has gone from one page to another via the URL
(by $ _GET what: p). This script should look like this:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...
$pseudo = $_GET['pseudo'];
$requete = mysql_query("SELECT age FROM membres WHERE pseudo='$pseudo'");
...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Well keep you well, this script is a big SQL injection vulnerability.
Suffice it to a bad boy putting in place the username in the URL a query
like this:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
' UNION SELECT password FROM membres WHERE id=1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


It is to arrive to show (just an example), for example the password for
the member with the id 1. I will not explain in detail the operation for
fear that someone is not nice to walk around. Well, so let us go to the
security:).

II) Security .
_______________

To secure this type of injection is simple. You use the function
mysql_real_escape_string ().

######################
Uh ... It does what it?
######################

This feature adds the "\" character to the following characters:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
NULL, \ x00, \ n, \ r, \, ', "and \ X1A
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

######################
And what's the point?
######################

As you have noticed in previous injection, the attacker uses the quote
(to close the 'around $ nick): if she is prevented from doing that, the
bad boy will only have to look elsewhere . This means that if one
applies a mysql_real_escape_string () to the variable name like this ...

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...
$pseudo = mysql_real_escape_string($_GET['pseudo']);
$requete = mysql_query("SELECT age FROM membres WHERE pseudo='$pseudo'");
...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The application is completely secure.
Explanation

######################
Injection hacker to recall:
######################

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
' UNION SELECT password FROM membres WHERE id=1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Well if we apply mysql_real_escape_string () to the variable $ name used
in the query is what will the injection:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
\' UNION SELECT password FROM membres WHERE id=1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This means that we do not even come out of assessments around $ nick in
the request because the \ has been added. There is another function
somewhat similar to mysql_real_escape_string () is addslashes (), why
not have used? Well recently, a security hole was discovered on this if
it is used on a PHP 4.3.9 installation with magic_quotes_gpc enabled.

######################
Numeric variables:
######################

This type of injection is less known than the previous one, making it
more frequent, and it starts as just now with an example. This time, it
displays the age of a member according to its id, and by passing it by a
form ($ _POST) to change:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
...
$id = $_POST['id'];
$requete = mysql_query("SELECT age FROM membres WHERE id=$id");
...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


mysql_real_escape_string () would be nothing here, since if an attacker
wants to inject SQL code, it will not need to use quotes, because the
variable $ id is not surrounded by quotes. Simple example of
exploitation:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 UNION SELECT password FROM membres WHERE id=1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This injection did exactly the same as the previous one, except that
here, to avoid it, there are two solutions:

     * Change the contents of the variable so it contains only numbers;
     * Check if the variable actually contains a number before using it in a query. 

##########
Method 1:
##########

We'll use a function , intval () This function returns regardless of the
contents of a variable its numerical value. For example:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$variable = '1e10';  // $variable vaut '1e10'
$valeur_numerique = intval($variable); // $valeur_numerique vaut 1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Now back to our sheep:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$id = intval($_POST['id']);
$requete = mysql_query("SELECT age FROM membres WHERE id=$id");
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

That is: you can stop there and is more than enough, but I recommend you
continue to find another method, or you have air beast if you find this
method on a code that is not yours without understand it.

############
Méthode 2:
###########

Here we use a function that returns TRUE when a variable contains only
numbers and FALSE if it is not the case this function is is_numeric (),
we will use it in a condition that checks whether is_numeric ( ) returns
TRUE well.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$id = $_POST['id'];
if (is_numeric($id))
{
$requete = mysql_query("SELECT age FROM membres WHERE id=$id");
}
else
{
echo "Trying to hack me ? Okah BAI";
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

##################################################################
What is the best, depending intval () and is_numeric ()?
##################################################################

Well I will say that they are both equally effective, they are equal.
But I prefer inval () since with is_numeric () write more code, and if
the variable does not contain only numbers, the request is canceled (in
principle, but of course you can run the same query by choosing an
default value for the variable used). Well that's it! You know all about
securing your applications. If you apply these methods, there is
absolutely no risk of having a fault type SQL injection on its website
(or PHP).

XSS ( Cross site scripting )

Alot of vulnerabilities are found in forums such as VBulletin So i suggest you only use MyBB.

an XSS Flaw can be found in a search field that uses $_GET function. All you need to do is replace the $_GET with $_POST

Also in VBulletin it can be exploited in admin posts and such.

Now why MyBB ? Its because cookies are deleted after each admin CP session.

RFI/LFI

An rfi/lfi flaw is a vulnerable script that users

include($file.php)

I have no idea on how to fix this i just can exploit it. lol


Upload fields

Make sure when creating upload fields to only allow .jpg formats and dont allow html tags. .

The attacker can simply put filename.php%00.jpg

The %00 is an encrypted null code. this will exclude the .jpg and the file will be uploaded as php.
Wich will give the attacker access to your website by uploading a shell or a CGI-Telnet backdoor.


More precaution

go to Whois lookup and Domain name search

And type ur hosts ip. make sure to browse all websites and make sure none are vulnerable to those exploits.

If the server was rooted and mass defaced. Your website will also be included in the defacement.

I wrote the tutorial but not the SQL avoid part, its from milw0rm

[James.H]

Nice thorough tutorial.

Can you include a cookies section too ?

As when I first made a site using a login system using cookies (back in 2005) other users much smarter than me would do cookie poisoning. I know how to prevent that now but I'm sure your version would be better

+ rep

[Moudi]

I would do a research and post some modifications
thank you

[Irfan_A]

Good information.

If i am not wrong, SQL injection is caused by error from programmer about 75% and from administrator about 25%. Programmer don't input validation, he forget or don't know about single quote ( ' ) if it applied. I know that percentage from three-day workshop about hacker that i attend last week.