SitePoint Sponsor |
|
User Tag List
Results 51 to 75 of 93
Thread: Top 7 PHP Security Blunders
-
Dec 24, 2005, 13:22 #51
- Join Date
- Feb 2004
- Location
- Los Angeles
- Posts
- 1
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Just a quick note to say that rather than reproducing the functionality of magic_quotes_gpc, it is a better practice to turn magic_quotes_gpc off altogether, and use database-specific escaping functions (like mysql_real_escape_string) which will cover a much wider range of special characters.
-
Dec 25, 2005, 08:18 #52MattSitePoint Community Guest
Or switch to ASP.Net. The security features are much stronger and SQL injection is nearly impossible unless you do something really stupid.
-
Dec 26, 2005, 12:31 #53
- Join Date
- Mar 2005
- Posts
- 2
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
@ Matt: Sure, switch to .Net, unless you would rather develop inexpensive, rapid, versatile web apps served by *nix and Apache as about 60 per cent of the websites on the Internet do. And it might mean you become a better coder in the end, teaching yourself to observe the good programming habits with a very useful language listed in this very good article.
-
Dec 26, 2005, 13:52 #54TxFrog1999SitePoint Community Guest
Just a quick note about invalid input from a form, while its true you should never rely on a pure JavaScript solution to validating form input it is best to use JS and even a simple AJAX solution to do a pre-server validation either before or while the form is being filled out. By using JS before running the form through the server it should cut down on the amount of hits on the server-based script as the immediate feedback JS provides will allow most users to fix errors in the form before submission.
-
Dec 26, 2005, 14:21 #55
- Join Date
- Nov 2002
- Location
- Belgium
- Posts
- 147
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
To my opinion using open_basedir has less use because it only applies to PHP and not to any other language you may use: Perl, Ruby, Python, ...
-
Dec 27, 2005, 13:13 #56
And it's "no one", not "no-one" ;) (front page).
-
Dec 27, 2005, 17:41 #57colderSitePoint Community Guest
1) You have to quote your array indexes. You've luck that php assumes undefined constants as strings. Enabling notices' reporting would have displayed that.
2) Disabling register_globals at runtime using ini_set() is useless, variables will already be defined. Consider http://php.net/configuration.changes as a better alternative for shared hosts.
3) For SQL injections : if the input is supposed to be numeric, check it using is_numeric() OR cast it to a numeric value using sprintf()/intval(). If it's supposed to be a string, use mysql_real_escape_string() and quote it. There is absolutely no need to currupt the input deleting some keyword/chars.
-
Dec 28, 2005, 06:22 #58DavidSitePoint Community Guest
Good, clear presentation of the key issues.
-
Dec 28, 2005, 18:23 #59colderSitePoint Community Guest
1) disabling regsiter_globals at runtime is useless: variables will already be defined
2) quote your array indexes. (page1)
3) mysql_real_escape_string() > addslashes() and the correct method is to apply stripslashes when get_magic_quotes_gpc returns true, and always use mysql_real_escape_string() after it. You can also cast values that are supposed to be integers, using intval() for example.
-
Dec 29, 2005, 09:36 #60
Good to see that you still didn't correct that typo. At least now i have a good laugh every time I open the front page
.
-
Dec 29, 2005, 22:13 #61
- Join Date
- Nov 2005
- Posts
- 0
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
A good article overall but I think some of the methods you described arent really the best (or easiest) way to go around solving the problems.
The thing that really jumped out to me was "enable magic quotes gpc" to solve this problem... That is one of the worst solutions to the problem!
IMO, the best method is to check for magic quotes gpc with
PHP Code:if( get_magic_quotes_gpc() == 1 ){ ... }
PHP Code:if( get_magic_quotes_gpc() == 1 ){
function cleanVar( &$var ){
if( is_array( $var ) ){
$var = array_map( "cleanVar", $var );
} else {
$var = stripslashes( $var );
}
return $var;
}
cleanVar($_POST);
cleanVar($_GET);
cleanVar($_COOKIE);
}
Safe mode is very annoying in many cases, and I'm glad to see that many servers are turning it off (and it (along with Register Globals and Magic Quotes) will very likley be removed in PHP6 (source: http://www.php.net/~derick/meeting-notes.html)). It would be good, but in many cases it just gives loads of problems when you want to write to a file. Only the most insecure servers really benefit from it.
Come to think of it, if you read the PHP6 notes you can see right away that relying on Magic Quotes is not a good idea, as its likley to be removed in the future.
EDIT: Didnt realise this linked to a bigger discussion, I'm sure much of what I have said has been said already.
-
Jan 5, 2006, 10:27 #62
- Join Date
- Mar 2005
- Posts
- 58
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Magic quotes are a pain (e.g. http://www.sitepoint.com/blogs/2005/...tes-headaches/) To stop SQL injection attacks use Pear::DB or AdoDB placeholders
-
Jan 5, 2006, 10:55 #63AnonymousSitePoint Community Guest
$month = $_GET[month];
That raised a red flag right off for me. Always quote strings, such as array keys. You clearly don't have error_reporting set correctly (E_ALL or, for PHP5, E_ALL | E_STRICT). Combined with the suggestion about using magic_quotes_gpc and addslashes (as mentioned already, never use addslashes; always use the database-specific escape function), this article loses a bit of credibility.
-
Jan 5, 2006, 19:00 #64
- Join Date
- Mar 2005
- Posts
- 7
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think it would be best to let PHP speak on the issue. For me, the greatest resource ever for PHP is the PHP manual.
Read the security section of the PHP manual and get to know it well.
Compare
http://us3.php.net/manual/en/securit...quotes.why.php
to
http://us3.php.net/manual/en/securit...tes.whynot.php
Choose accordingly...
-
Jan 6, 2006, 04:40 #65
- Join Date
- Jan 2006
- Location
- not the hell
- Posts
- 11
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
any more new PHP security tips? it's too old.
-
Jan 6, 2006, 04:43 #66
Guys, stop trying to correct their articles. SitePoint clearly doesn't give a ****
.
-
Jan 6, 2006, 06:09 #67
- Join Date
- Jan 2005
- Location
- NY
- Posts
- 140
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
For an Administration script I wrote, I retrieve the password FIRST and then compare the md5'ed USER INPUT to the stored md5 version, which I retrieved first.
User data never touches my database, unless I trust the user or I enforce data structure limitations/format.
-
Jan 12, 2006, 10:42 #68
- Join Date
- Sep 2004
- Location
- Raleigh, NC
- Posts
- 2
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
When you're expecting an integer to be used in a SQL...
(SELECT * FROM `t` WHERE `id` = $UserInput)
... the malicious user could supply input such as "0; DELETE FROM `t`;" to attack you. I find a simple and effective solution is to cast user input to an int before using it in the query. Any string data will be chopped off, no more SQL injection.
-
Jan 12, 2006, 13:57 #69
- Join Date
- Oct 2004
- Location
- Brooklyn, NY
- Posts
- 359
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Icheb
It has been bookmarked by more than 500 people on del.icio.us:
http://del.icio.us/url/6a721e590a294c9278ff8c4396ad65f8
(This is almost exactly how many people have bookmarked the PHP Security Guide.)
SitePoint is ranked 681 on Alexa:
http://www.alexa.com/data/details/?url=sitepoint.com/
In other words, this is a very popular and very misinformative article. This is hurting the PHP community, and I am extremely disappointed that neither the author nor SitePoint seem to care.
If there was a more appropriate place for me to have directed my initial comments, please feel free to let me know. I'm very interested in getting this article corrected.Chris Shiflett
http://shiflett.org/
-
Jan 13, 2006, 00:56 #70
- Join Date
- Apr 2000
- Location
- Melbourne, Australia
- Posts
- 2,571
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Actually, I've just updated the article to correct most of the critiques that were raised against it in this thread. If anyone is motivated to do so, please let me know if there are any significant issues I have missed.
Kevin Yank
CTO, sitepoint.com
I wrote: Simply JavaScript | BYO PHP/MySQL | Tech Times | Editize
Baby’s got back—a hard back, that is: The Ultimate CSS Reference
-
Jan 13, 2006, 10:28 #71
- Join Date
- Oct 2004
- Location
- Brooklyn, NY
- Posts
- 359
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Kevin Yank
I'll restate the items from my original (likely incomplete) list that have not been completely addressed. Hopefully others will do the same, and I'll be happy to clarify anything that needs it.
User-provided data simply cannot be trusted.
You should check the user's access privileges upon every load of a restricted page of your PHP application. If you check the user's credentials on the index page only, a malicious user could directly enter a URL to a "deeper" page, which would bypass this credential checking process.
It's also advisable to layer your security, for example, by restricting user access on the basis of the user's IP address as well as their user name, if you have the luxury of writing an application for users that will have predictable or fixed IPs.
Always name these include files with a .php extension, so that even if all your protection is bypassed, the Web server will parse the PHP code, and will not display it to the user.
Executing code out of context is an additional and unnecessary risk. I would argue that it's safer to instruct Apache to deny access to .inc resources (in httpd.conf) and store includes outside of document root. That's Defense in Depth. Naming includes .php eliminates the potential to add this extra safeguard, plus it just exchanges one risk for another.
To prevent this type of attack, you need to be careful about displaying user-submitted content verbatim on a Web page. The easiest way to protect against this is simply to escape the characters that make up HTML syntax (in particular, < and >) to HTML character entities (< and >), so that the submitted data is treated as plain text for display purposes. Just pass the data through PHP's htmlspecialchars function as you are producing the output.
However, I think it's pretty important that we remind developers of the importance of character encoding consistency. I blogged about this recently, using Google's XSS vulnerability as an example:
http://shiflett.org/archive/178
This shows how htmlentities() doesn't offer sufficient XSS protection without indicating the character encoding.
SQL Insertion Vulnerabilities
This feature safeguards against inexperienced developers who might otherwise leave security holes like the one described above, but it has an unfortunate impact on performance when input values do not need to be escaped for use in database queries.
Credit card numbers and customer information are the most common types of secured data, but if you transmit usernames and passwords over a regular HTTP connection, and those usernames and passwords allow access to sensitive material, you might as well transmit the sensitive material itself over an unencrypted connection.
The www and admin directories are the only directories whose files can be accessed directly by a URL; the admin directory is protected by an .htaccess file that allows users entry only if they know a user name and password that's stored in the .htpasswd file in the root directory of the site.
If you're on a shared host, use the ini_set() function in all your pages and disable this setting.
Thanks again for your efforts. It helps your users to know that their attempts to help out are worthwhile. :-)Chris Shiflett
http://shiflett.org/
-
Jan 13, 2006, 15:11 #72
- Join Date
- Mar 2005
- Posts
- 5
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I find it sad that even after it was 'updated', it still won't even run without produce notices. Not to mention the fact that the terribly slow regex is being used instead of is_numeric().
-
Jan 13, 2006, 15:26 #73
- Join Date
- Feb 2004
- Location
- Huldenberg (Belgium)
- Posts
- 426
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by bartb
The Path of excess leeds to the tower of wisdom (W. Blake)
-
Jan 16, 2006, 09:55 #74Tino DidriksenSitePoint Community Guest
Quote: "If you're on a shared host, use the ini_set() function in all your pages and disable this setting."
ini_set() happens a long time after register_globals has done its evil deed. The best way to turn off register_globals in a shared environment is to use "php_value register_globals 0" in your .htaccess.
-
Jan 19, 2006, 00:04 #75oopsSitePoint Community Guest
It will be very hard to find even sha-1 collision if you don't know the actual hash. And how and why should the user ever know that?
Bookmarks