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 35 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 2 of 3 < 1 2 3 >
    Thread tools Search this thread Display Modes  
05-09-2007, 09:38 PM
#11
Seb is offline Seb
Seb's Avatar
Status: Watermelon Man
Join date: Nov 2006
Location: London
Expertise:
Software:
 
Posts: 3,311
iTrader: 36 / 100%
 

Seb is on a distinguished road

  Old

Great article Village, will come in handy when I start working out this PHP shiznizz

05-09-2007, 09:42 PM
#12
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

Originally Posted by Village Idiot View Post
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.
Well thats cool then!

On the subject of databases and also password protection, it may be worth mentioning hashing/encrypting things such as passwords when they're stored, as a suprising amount of people don't do this!

I couldn't not link to this great read on helping to secure passwords (it's about collisions when hashing):
http://youngcoders.com/showthread.php?t=16159

Oh and hey Kyle , Nice to see you off YC .

05-10-2007, 05:32 PM
#13
VincePirez is offline VincePirez
Status: Sin Binner
Join date: Mar 2007
Location:
Expertise:
Software:
 
Posts: 19
iTrader: 0 / 0%
 

VincePirez is on a distinguished road

  Old

I haven't read all of the responses, but I see no use of strip_tags() anywhere here..... Don't forget about XSS vulnerabilities, etc.

05-11-2007, 03:45 AM
#14
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 My Original Post
To conclude the introduction, XSS attacks are too broad of a range and wont be covered here.
This isnt a definitive resource, I only covered a few types of attacks, XSS not included. I may revise it some time though.

06-05-2007, 11:13 PM
#15
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

If someone wants to submit a article on XSS, I will add it in with full credit and all.

06-06-2007, 12:43 AM
#16
Salathe is offline Salathe
Salathe's Avatar
Status: Community Archaeologist
Join date: Jul 2004
Location: Scotland
Expertise: Software Development
Software: vim, PHP
 
Posts: 3,820
iTrader: 25 / 100%
 

Salathe will become famous soon enough

Send a message via MSN to Salathe

  Old

I haven't paid any attention to this topic until now, but if people are going to take away and use the code provided here then I'd like to ask you about something.

Why are the three str_replace calls there? Surely that goes against using mysql_real_escape_string since if any potentially malicious characters do get escaped, you then remove them leaving a backslash behind.

PHP Code:
$value $_GET['value']; // oranges'

// Example using VI's sql_safe function
$safe_value sql_safe($value); // oranges\
echo "SELECT * FROM mytable WHERE mycol = '{$safe_value}';";
// SELECT * FROM mytable WHERE mycol = 'oranges\';
// ^ Malformed query

// Without the str_replaces
$safe_value sql_safe_no_str_replaces($value); // oranges\'
echo "SELECT * FROM mytable WHERE mycol = '{$safe_value}';";
// SELECT * FROM mytable WHERE mycol = 'oranges\'';
// ^ Properly escaped 
Sure, you might prevent potentially malicious attacks getting through but you'll also make a mess when there needn't be one.

Also, consider what happens if an empty string is fed into the function. Will it, or wont it, mess up your query?

All that said, it's late and I might be barking up the wrong tree! Correct me if I'm being stupid.

06-06-2007, 02:53 AM
#17
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

Its possible, the way I gave was the method I was taught, it hasent failed me so far.

06-11-2007, 02:57 PM
#18
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

After looking further into it, your right. All the str_replaces are really doing is what mysql_real_escape_string() is doing. Thanks for pointing that out.

06-16-2007, 08:46 PM
#19
ProxyBear.com is offline ProxyBear.com
Status: Sin Binner
Join date: Jun 2007
Location:
Expertise:
Software:
 
Posts: 31
iTrader: 0 / 0%
 

ProxyBear.com is on a distinguished road

  Old

Very intresting i never new about the delete part .

02-02-2008, 10:55 AM
#20
RaZoR^ is offline RaZoR^
RaZoR^'s Avatar
Status: Member
Join date: Feb 2006
Location:
Expertise:
Software:
 
Posts: 191
iTrader: 1 / 100%
 

RaZoR^ is on a distinguished road

  Old

In terms of cookies, I've always gone along the lines of storing the user's sessionID. Although the principle of hashing the data still applies.

Another great tip for hashing is to create a custom encryption method and encrypt the data to be stored in the database, and decrypt it when you retrieve the data. This is good because if a cracker got into the database using any method, they would find it a bit more difficult to crack because they wouldn't know what the password hashes were made up of. It immediately makes dictionary attacks more difficult, and if you make a good encryption which increases the length of the plaintext before it's hashed, you can slow down brute-force attacks a lot as well. Most of the time, it will keep all your users safe, but even just a weak encryption might keep your users safe whilst you restore a database backup, secure a hole and post an announcement on the site telling people to change their passwords on your site and any other sites with the same password.

The alternative I had to that was to salt the hashes. The salt is a string that's put into every password to make the hash much harder to crack. A 1-character hash might just prevent dictionary attacks; a 5-character salt would be much more effective towards both dictionary and brute-force attacks. The salt doesn't need to go anywhere specific; in the middle is best (split the password in half, then define a new variable to hold the first half, the salt, the second half), but the salt could even just go at the start or the end ( $passwordHashed = md5($password . $salt); ). The salt can either be a fixed salt, stored in the script, or it could be randomly generated when the user creates their account and stored alongside their database record. Hard-coding it into the text file means anyone with database access still won't have it, unless they manage to crack a password and see it sticking out. Storing a random one in the database means that the cracker will find it more difficult to tailor their cracker to crack all the md5 hashes they have because all the salts will be different.

Sorry, I'll shush now lol... very good article though... a solid ground for building up knowledge of security, and covers the most important aspect, SQL injection.

Closed Thread  
Page 2 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