|
|
|
|
Thread title: Making secure php programs |
|
|
|
|
|
Thread tools
Search this thread
Display Modes
|
|
05-09-2007, 09:38 PM
|
#11
|
Status: Watermelon Man
Join date: Nov 2006
Location: London
Expertise:
Software:
Posts: 3,312
|
Great article Village, will come in handy when I start working out this PHP shiznizz
|
|
05-09-2007, 09:42 PM
|
#12
|
Status: Senior Member
Join date: Jul 2005
Location:
Expertise:
Software:
Posts: 835
|
Originally Posted by Village Idiot
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
|
Status: Sin Binner
Join date: Mar 2007
Location:
Expertise:
Software:
Posts: 19
|
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
|
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
Posts: 6,894
|
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
|
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
Posts: 6,894
|
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
|
Status: Community Archaeologist
Join date: Jul 2004
Location: Scotland
Expertise: Software Development
Software: vim, PHP
Posts: 3,820
|
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
|
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
Posts: 6,894
|
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
|
Status: Geek
Join date: Apr 2006
Location: Denver, CO
Expertise: Software
Software: Chrome, Notepad++
Posts: 6,894
|
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
|
Status: Sin Binner
Join date: Jun 2007
Location:
Expertise:
Software:
Posts: 31
|
Very intresting i never new about the delete part .
|
|
02-02-2008, 10:55 AM
|
#20
|
Status: Member
Join date: Feb 2006
Location:
Expertise:
Software:
Posts: 191
|
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.
|
|
|
|
|
|
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
|
|