Today's Posts Follow Us On Twitter! TFL Members on Twitter  
Forum search: Advanced Search  
Navigation
Marketplace
  Members Login:
Lost password?
  Forum Statistics:
Forum Members: 24,256
Total Threads: 81,169
Total Posts: 566,839
There are 29 users currently browsing (tf).
 
  Our Partners:
 
  TalkFreelance     Business and Website Management     Articles From The Experts :

Making secure php programs

Thread title: Making secure php programs
Closed Thread  
Page 1 of 3 1 2 3 >
    Thread tools Search this thread Display Modes  
05-09-2007, 08:34 PM
#1
Village Genius is offline Village Genius
Village Genius's Avatar
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
 
Posts: 6,892
iTrader: 18 / 100%
 

Village Genius will become famous soon enough

  Old  Making secure php programs

Making Secure PHP Applications

There are 2 basic types of attacks that a cracker will try to gain access you don't really want him to have. This lesson runs though what the cracker does and how you can fight against. This is really anything but a definitive guide to security, there is no possible way to cover security in a 4 page article. But this is a good start to security. To conclude the introduction, XSS attacks are too broad of a range and wont be covered here.

Basics
Generally, scripts that don't have their source revealed to the public are harder to crack. Scripts which you can get the source from always have to take more precautions. Either way, the same precautions should be taken, not giving the source doesn't make it uncrackable. Security is extremely important, I learned that when I had a bug in img911's script that allowed php files to be uploaded. There was a script that gave the uploader full control of my files, the site was only a week old! People will come to your site and try to gain access if they can. It is a matter of time before it happens to you, are you ready?

Attack One: SQL Injection Attacks
What it is
This is by a good margin the most common type of attack because of its shear power, that and its easy to do. SQL injection attacks inject commands via user imputed data that could cause damage to your database.

How it works
SQL injection attacks happen when you modify data that is being sent into a database, for instance
showimage.php?id=1
You could change that to
showimage.php?id=1'; DELETE FROM images WHERE 1;
That would create an error for the sql if there is any command passed the WHERE clause, but the DELETE command would run and work. This gives the cracker full control of your database, anything you could do with mysql_query, he can do. He doesnt just have to use get data, he can use POST data that is being sent from a form, he can also edit cookies that the site uses.


How to prevent
There are a few ways to prevent an SQL attack.

Method 1, Clean the data
The first way is to strip slashes, quotes and other things that have no legit purpose in the query. THIS IS NECESSARY IN ANYTHING THAT IS USER INPUTED AND WILL BE USED WITH A DATABASE! User inputted data is anything that can be edited from the outside, GET data (.php?getdata=data), user inputted POST data and cookies can all be edited by a user. Anything coming from those must be cleaned or your script is not safe. I use this function to clean my data
PHP Code:
function sql_safe($value
{
    
// Stripslashes
    
if (get_magic_quotes_gpc()) 
    {
        
$value stripslashes($value);
    }

    
// Quote if not integer
    
if (!is_numeric($value) || $value[0] == '0')
    {
        
$value mysql_real_escape_string($value);
    }
    return 
$value;

Just make all your user inputed data data like this
PHP Code:
$var sql_safe($_GET[“data”]); 
This way, all invalid data is stripped out and your database is safe. This method is not an option, every application you make must have this or equivalent code, this is the only sure fire method that cant be hacked. If you do this with all your data, your site is safe from SQL injection attacks. The next two methods are icing on the cake, not hacker proof methods.

Method 2, Table prefixes
Fact of life is everyone makes mistakes, chances are pretty high you will forget to clean one user inputted data down the road, as small as the chance is, a cracker might find it. Most programs use standard names for their database, such as in a forum the table that holds the posts would be named “posts”. Crackers know this and will try every relevant name to the type of site it is. The best way to get around this is to add a prefix to your table name, instead of “posts”, make it “forum_posts”, even a common prefix like that makes it a good deal harder to hack. I use the first 3 letters of my control panel login name as my db prefix. Do not rely on this method, it just makes it harder for a cracker to get in should you miss a step.


Method 3, Don't give sql user delete rights
This method is anything but a strict guideline, most of the scripts I make require deleting rows. But if it isn't needed and you don't have to delete rows, don't give the user permission to. This will make it so that if you forgot to clean and he got the prefix, he can't delete anything. Use it when you can, but don't change a script to cater to this, it is little more then a final precaution.



Attack 2, forged data

What it is
Forged data is when you edit a cookie to make yourself look like an admin. The only way to let this happen is flawed design, generally static data or not confirming the data is question. As rare as it may seem, it is an error Ive seen allot, even in some scripts that are for sale. This one is more obscure, but it can happen if you encounter the wrong person. This can be worse then sql injection attacks because it is less apparent; you don't have to destroy anything. Lastly, you normally have to have access to the script to do this, but not always.

How its done
Cookies can be edited easily, they are just text files on your computer. A cracker will go in and change the data to imitate what the script thinks is an admin. In firefox, to view the cookie all you have to do it go to tools -> options -> privacy -> view cookies. To change them you have to shut the browser off and go to C:\Documents and Settings\name\Application Data\Mozilla\Firefox\Profiles\profile name\cookies.txt

All your cookies reside in there, it is not encrypted so you can change anything you want to.


How to protect it

A lesson in how to make secure login cookies
What many scripts do is lay cookies like this
cookie 1:
username

cookie 2:
pass

cookie 3:
rank

This makes it easy to see if they are an admin or not, but there is one huge problem, all you have to do is change the rank cookie to what it looks for with an admin and you are in. This is a flawed design, what you have to do is this

cookie 1:
user ID

cookie 2:
user pass, encrypted via sha1 (you use sha1 when storing it in the db, right?)

When it sees a cookie, it will go into the database and see if the user with that id has that password. If it does, the user is who it says it is, you can see their rank in the database. If the data doesn't match, you delete the cookie and they are off. The only way to hack this is to know the pass, and if the cracker knew that he wouldn't be going in the back door.

Hold as little data as you can in the cookie, all it needs to do is provide solid data that the user in question is legit, not what rank they are.

I hope this article will help you make more secure PHP applications, if their is anything that has slipped my mind for this, please drop me a pm.

05-09-2007, 08:47 PM
#2
sketchie is offline sketchie
sketchie's Avatar
Status: Senior Member
Join date: Jul 2005
Location:
Expertise:
Software:
 
Posts: 835
iTrader: 1 / 100%
 

sketchie is on a distinguished road

  Old

You failed to say anything about XSS injections. Which are very popular at the moment!

Though I do like your tip about not giving the MySQL user deletion rights

05-09-2007, 08:50 PM
#3
Village Genius is offline Village Genius
Village Genius's Avatar
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
 
Posts: 6,892
iTrader: 18 / 100%
 

Village Genius will become famous soon enough

  Old

edit: Too broad, I also am not a javascript guru so im not gonna cover it.

05-09-2007, 08:54 PM
#4
sketchie is offline sketchie
sketchie's Avatar
Status: Senior Member
Join date: Jul 2005
Location:
Expertise:
Software:
 
Posts: 835
iTrader: 1 / 100%
 

sketchie is on a distinguished road

  Old

Also as far as I'm aware, Ereg(i) functions (well eregi at the least) is not Binary safe and I'd recommend using something else.

05-09-2007, 08:58 PM
#5
Village Genius is offline Village Genius
Village Genius's Avatar
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
 
Posts: 6,892
iTrader: 18 / 100%
 

Village Genius will become famous soon enough

  Old

Originally Posted by sketchie View Post
Also as far as I'm aware, Ereg(i) functions (well eregi at the least) is not Binary safe and I'd recommend using something else.
im pretty sure it is, php.net normally says if it isnt, nothing there about it

05-09-2007, 09:03 PM
#6
sketchie is offline sketchie
sketchie's Avatar
Status: Senior Member
Join date: Jul 2005
Location:
Expertise:
Software:
 
Posts: 835
iTrader: 1 / 100%
 

sketchie is on a distinguished road

  Old

Here's a list of what's not safe:
http://uk.php.net/manual/en/ref.regex.php
on the php.net site as you asked :P

PCRE are safe though .

05-09-2007, 09:09 PM
#7
Village Genius is offline Village Genius
Village Genius's Avatar
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
 
Posts: 6,892
iTrader: 18 / 100%
 

Village Genius will become famous soon enough

  Old

oh, I didnt realize that, changed to str_replace. Nice and binary safe.

05-09-2007, 09:22 PM
#8
sketchie is offline sketchie
sketchie's Avatar
Status: Senior Member
Join date: Jul 2005
Location:
Expertise:
Software:
 
Posts: 835
iTrader: 1 / 100%
 

sketchie is on a distinguished road

  Old

I'd like to say sorry I feel I've been abit rude with my criticisms. You have indeed covered alot of the key aspects on PHP security. However, I feel that you can't really teach it all in one tutorial.

In an ideal world, tutorial websites would teach beginners these practices from the start. I could only wish I hadn't picked some of them up myself, and that I knew what I don't... If that makes sense.

05-09-2007, 09:26 PM
#9
Village Genius is offline Village Genius
Village Genius's Avatar
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
 
Posts: 6,892
iTrader: 18 / 100%
 

Village Genius will become famous soon enough

  Old

You haven't been rude at all, my goal is to help people make secure code, being pointed out on a mistake only helps.

And I should add a line about it not being definitive, books have been made on this subject, 4 pages wont even scratch the surface.

05-09-2007, 09:30 PM
#10
unclekyky is offline unclekyky
unclekyky's Avatar
Status: Junior Member
Join date: May 2005
Location:
Expertise:
Software:
 
Posts: 43
iTrader: 0 / 0%
 

unclekyky is on a distinguished road

  Old

I would also recommend the use of mysql_real_escape_string when passing data to the database.

Great tutorial!

EDIT: sorry, i didn't read the sql_safe function good enough! Its in there

Closed Thread  
Page 1 of 3 1 2 3 >


Thread Tools
Display Modes

  Posting Rules  
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump:
 
  Contains New Posts Forum Contains New Posts   Contains No New Posts Forum Contains No New Posts   A Closed Forum Forum is Closed