consultant1027

It appears the -e file exists test operator doesn't work on files that are referenced via symbolic link directories? Anyone know of a solution to test for file existence in symbolic link directory?

Problem ended up being PHP Safe mode was on when it needed to be off.

It may very well be an Apache issue. I created a test script, all it contains is: <?php echo "Testing. Hello!<br>"; ?> It doesn't work. It has the same behavior as all the php scripts on most all the domains on the server (but not all). That is, after the first command in the script, all the source code is output to the browser. So running this script doesn't result in a page that shows: Testing. Hello! It displays this: "; ?>

This is my own dedicated server. I've posted a WinMerge comparison report of the phpinfo() between the old server and the new server here: http://www.penslimited.com/phpinfo_comp.htm

Upgraded to 5.2.17 and no luck. I suppose I need to just compare PHP Info between the old server and new. But not know what I'm looking for, that is going to be a pain to figure out what is wrong.

I moved several websites to a new server. I use a process.php script for a contact form on several of the sites. They are all now outputting the source code of the script. I have other sites running PHP scripts on the server with no issues. Here's the first few lines of code of the script. All the code starting after $form-> is output to the browser. <?php require_once 'config.php'; // make sure we're not being accessed directly if ( !is_array($config) || empty($_POST) ) die(); $form = new DynaForm($config); $form->setVariables(array_map('stripslashes', $_POST)); In addition, this script just returns a blank screen in the browser but runs fine from the command shell. <?php phpinfo(); ?> Here's the output running it from the cmd shell: phpinfo() PHP Version => 5.1.6 System => Linux serv1.crist.com 2.6.18-028stab070.14 #1 SMP Thu Nov 18 16:04:02 MSK 2010 i686 Build Date => Nov 29 2010 16:41:23 Configure Command => './configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-mime-magic=/usr/share/file/magic.mime' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--with-system-tzdata' '--enable-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-ncurses=shared' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--with-mysql=shared,/usr' '--with-mysqli=shared,/usr/lib/mysql/mysql_config' '--enable-dom=shared' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,/usr/lib/mysql/mysql_config' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/usr' '--enable-dbase=shared' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => /etc/php.ini Scan this dir for additional .ini files => /etc/php.d additional .ini files parsed => /etc/php.d/dbase.ini, /etc/php.d/dom.ini, /etc/php.d/gd.ini, /etc/php.d/imap.ini, /etc/php.d/ldap.ini, /etc/php.d/mbstring.ini, /etc/php.d/mysql.ini, /etc/php.d/mysqli.ini, /etc/php.d/ncurses.ini, /etc/php.d/odbc.ini, /etc/php.d/pdo.ini, /etc/php.d/pdo_mysql.ini, /etc/php.d/pdo_odbc.ini, /etc/php.d/pdo_pgsql.ini, /etc/php.d/pdo_sqlite.ini, /etc/php.d/pgsql.ini, /etc/php.d/snmp.ini, /etc/php.d/xmlreader.ini, /etc/php.d/xmlrpc.ini, /etc/php.d/xmlwriter.ini, /etc/php.d/xsl.ini, /etc/php.d/zendoptimizer.ini PHP API => 20041225 PHP Extension => 20050922 Zend Extension => 220051025 Debug Build => no Thread Safety => disabled Zend Memory Manager => enabled IPv6 Support => enabled Registered PHP Streams => php, file, http, ftp, compress.bzip2, compress.zlib, https, ftps Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters => string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, bzip2.*, zlib.* This program makes use of the Zend Scripting Language Engine: Zend Engine v2.1.0, Copyright © 1998-2006 Zend Technologies with Zend Optimizer v3.3.3, Copyright © 1998-2007, by Zend Technologies _______________________________________________________________________ Configuration PHP Core Directive => Local Value => Master Value allow_call_time_pass_reference => Off => Off allow_url_fopen => On => On always_populate_raw_post_data => Off => Off arg_separator.input => & => & arg_separator.output => & => & asp_tags => Off => Off auto_append_file => no value => no value auto_globals_jit => On => On auto_prepend_file => no value => no value browscap => no value => no value default_charset => no value => no value default_mimetype => text/html => text/html define_syslog_variables => Off => Off disable_classes => no value => no value disable_functions => no value => no value display_errors => Off => Off display_startup_errors => Off => Off doc_root => no value => no value docref_ext => no value => no value docref_root => no value => no value enable_dl => On => On error_append_string => no value => no value error_log => no value => no value error_prepend_string => no value => no value error_reporting => 2047 => 2047 expose_php => Off => Off extension_dir => /usr/lib/php/modules => /usr/lib/php/modules file_uploads => On => On highlight.bg => #FFFFFF => #FFFFFF highlight.comment => #FF8000 => #FF8000 highlight.default => #0000BB => #0000BB highlight.html => #000000 => #000000 highlight.keyword => #007700 => #007700 highlight.string => #DD0000 => #DD0000 html_errors => Off => On ignore_repeated_errors => Off => Off ignore_repeated_source => Off => Off ignore_user_abort => Off => Off implicit_flush => On => Off include_path => .: => .: log_errors => On => On log_errors_max_len => 1024 => 1024 magic_quotes_gpc => Off => Off magic_quotes_runtime => Off => Off magic_quotes_sybase => Off => Off mail.force_extra_parameters => no value => no value max_execution_time => 0 => 60 max_file_uploads => 20 => 20 max_input_nesting_level => 64 => 64 max_input_time => -1 => 60 memory_limit => 128M => 128M open_basedir => no value => no value output_buffering => 0 => 4096 output_handler => no value => no value post_max_size => 8M => 8M precision => 14 => 14 realpath_cache_size => 16K => 16K realpath_cache_ttl => 120 => 120 register_argc_argv => On => Off register_globals => Off => Off register_long_arrays => Off => Off report_memleaks => On => On report_zend_debug => Off => Off safe_mode => On => On safe_mode_exec_dir => no value => no value safe_mode_gid => Off => Off safe_mode_include_dir => no value => no value sendmail_from => no value => no value sendmail_path => /usr/sbin/sendmail -t -i => /usr/sbin/sendmail -t -i serialize_precision => 100 => 100 short_open_tag => On => On SMTP => localhost => localhost smtp_port => 25 => 25 sql.safe_mode => Off => Off track_errors => Off => Off unserialize_callback_func => no value => no value upload_max_filesize => 10M => 10M upload_tmp_dir => no value => no value user_dir => no value => no value variables_order => EGPCS => EGPCS xmlrpc_error_number => 0 => 0 xmlrpc_errors => Off => Off y2k_compliance => On => On zend.ze1_compatibility_mode => Off => Off bz2 BZip2 Support => Enabled Stream Wrapper support => compress.bz2:// Stream Filter support => bzip2.decompress, bzip2.compress BZip2 Version => 1.0.3, 15-Feb-2005 calendar Calendar support => enabled ctype ctype functions => enabled curl CURL support => enabled CURL Information => libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 date date/time support => enabled Timezone Database Version => 0.system Timezone Database => internal Default timezone => America/Los_Angeles Directive => Local Value => Master Value date.default_latitude => 31.7667 => 31.7667 date.default_longitude => 35.2333 => 35.2333 date.sunrise_zenith => 90.583333 => 90.583333 date.sunset_zenith => 90.583333 => 90.583333 date.timezone => no value => no value dom DOM/XML => enabled DOM/XML API Version => 20031129 libxml Version => 2.6.26 HTML Support => enabled XPath Support => enabled XPointer Support => enabled Schema Support => enabled RelaxNG Support => enabled exif EXIF Support => enabled EXIF Version => 1.4 $Id: exif.c,v 1.173.2.5 2006/04/10 18:23:24 helly Exp $ Supported EXIF Version => 0220 Supported filetypes => JPEG,TIFF ftp FTP support => enabled gd GD Support => enabled GD Version => bundled (2.0.28 compatible) FreeType Support => enabled FreeType Linkage => with freetype FreeType Version => 2.2.1 GIF Read Support => enabled GIF Create Support => enabled JPG Support => enabled PNG Support => enabled WBMP Support => enabled XBM Support => enabled gettext GetText Support => enabled gmp gmp support => enabled hash hash support => enabled Hashing Engines => md4 md5 sha1 sha256 sha384 sha512 ripemd128 ripemd160 whirlpool tiger128,3 tiger160,3 tiger192,3 tiger128,4 tiger160,4 tiger192,4 snefru gost adler32 crc32 crc32b haval128,3 haval160,3 haval192,3 haval224,3 haval256,3 haval128,4 haval160,4 haval192,4 haval224,4 haval256,4 haval128,5 haval160,5 haval192,5 haval224,5 haval256,5 iconv iconv support => enabled iconv implementation => glibc iconv library version => 2.5 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1 imap IMAP c-Client Version => 2004 SSL Support => enabled Kerberos Support => enabled ldap LDAP Support => enabled RCS Version => $Id: ldap.c,v 1.161.2.3 2006/01/01 12:50:08 sniper Exp $ Total Links => 0/unlimited API Version => 3001 Vendor Name => OpenLDAP Vendor Version => 20343 SASL Support => Enabled libxml libXML support => active libXML Version => 2.6.26 libXML streams => enabled mbstring Multibyte Support => enabled Multibyte string engine => libmbfl Multibyte (japanese) regex support => enabled Multibyte regex (oniguruma) version => 3.7.1 mbstring extension makes use of "streamable kanji code filter and converter", which is distributed under the GNU Lesser General Public License version 2.1. Directive => Local Value => Master Value mbstring.detect_order => no value => no value mbstring.encoding_translation => Off => Off mbstring.func_overload => 0 => 0 mbstring.http_input => pass => pass mbstring.http_output => pass => pass mbstring.internal_encoding => ISO-8859-1 => no value mbstring.language => neutral => neutral mbstring.strict_detection => Off => Off mbstring.substitute_character => no value => no value mime_magic mime_magic support => invalid magic file, disabled Directive => Local Value => Master Value mime_magic.debug => Off => Off mime_magic.magicfile => /usr/share/file/magic.mime => /usr/share/file/magic.mime mysql MySQL Support => enabled Active Persistent Links => 0 Active Links => 0 Client API version => 5.0.77 MYSQL_MODULE_TYPE => external MYSQL_SOCKET => /var/lib/mysql/mysql.sock MYSQL_INCLUDE => -I/usr/include/mysql MYSQL_LIBS => -L/usr/lib/mysql -lmysqlclient Directive => Local Value => Master Value mysql.allow_persistent => On => On mysql.connect_timeout => 60 => 60 mysql.default_host => no value => no value mysql.default_password => no value => no value mysql.default_port => no value => no value mysql.default_socket => no value => no value mysql.default_user => no value => no value mysql.max_links => Unlimited => Unlimited mysql.max_persistent => Unlimited => Unlimited mysql.trace_mode => Off => Off mysqli MysqlI Support => enabled Client API library version => 5.0.77 Client API header version => 5.0.77 MYSQLI_SOCKET => /var/lib/mysql/mysql.sock Directive => Local Value => Master Value mysqli.default_host => no value => no value mysqli.default_port => 3306 => 3306 mysqli.default_pw => no value => no value mysqli.default_socket => no value => no value mysqli.default_user => no value => no value mysqli.max_links => Unlimited => Unlimited mysqli.reconnect => Off => Off ncurses ncurses support => enabled ncurses library version => 5.5 color support => yes odbc ODBC Support => enabled Active Persistent Links => 0 Active Links => 0 ODBC library => unixODBC ODBC_INCLUDE => -I/usr/include ODBC_LFLAGS => -L/usr/lib ODBC_LIBS => -lodbc Directive => Local Value => Master Value odbc.allow_persistent => On => On odbc.check_persistent => On => On odbc.default_db => no value => no value odbc.default_pw => no value => no value odbc.default_user => no value => no value odbc.defaultbinmode => return as is => return as is odbc.defaultlrl => return up to 4096 bytes => return up to 4096 bytes odbc.max_links => Unlimited => Unlimited odbc.max_persistent => Unlimited => Unlimited openssl OpenSSL support => enabled OpenSSL Version => OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 pcntl pcntl support => enabled pcre PCRE (Perl Compatible Regular Expressions) Support => enabled PCRE Library Version => 6.6 06-Feb-2006 PDO PDO support => enabled PDO drivers => mysql, odbc, pgsql, sqlite pdo_mysql PDO Driver for MySQL, client library version => 5.0.77 PDO_ODBC PDO Driver for ODBC (unixODBC) => enabled ODBC Connection Pooling => Enabled, strict matching pdo_pgsql PDO Driver for PostgreSQL => enabled PostgreSQL(libpq) Version => 8.1.22 Module version => 1.0.2 Revision => $Id: pdo_pgsql.c,v 1.7.2.11 2006/03/14 10:49:18 edink Exp $ pdo_sqlite PDO Driver for SQLite 3.x => enabled PECL Module version => 1.0.1 $Id: pdo_sqlite.c,v 1.10.2.6 2006/01/01 12:50:12 sniper Exp $ SQLite Library => 3.3.6 pgsql PostgreSQL Support => enabled PostgreSQL(libpq) Version => 8.1.22 Multibyte character support => enabled SSL support => enabled Active Persistent Links => 0 Active Links => 0 Directive => Local Value => Master Value pgsql.allow_persistent => On => On pgsql.auto_reset_persistent => Off => Off pgsql.ignore_notice => Off => Off pgsql.log_notice => Off => Off pgsql.max_links => Unlimited => Unlimited pgsql.max_persistent => Unlimited => Unlimited posix Revision => $Revision: 1.70.2.3 $ pspell PSpell Support => enabled Reflection Reflection => enabled Version => $Id: php_reflection.c,v 1.164.2.33 2006/03/29 14:28:42 tony2001 Exp $ session Session Support => enabled Registered save handlers => files user Registered serializer handlers => php php_binary wddx Directive => Local Value => Master Value session.auto_start => Off => Off session.bug_compat_42 => Off => Off session.bug_compat_warn => On => On session.cache_expire => 180 => 180 session.cache_limiter => nocache => nocache session.cookie_domain => no value => no value session.cookie_lifetime => 0 => 0 session.cookie_path => / => / session.cookie_secure => Off => Off session.entropy_file => no value => no value session.entropy_length => 0 => 0 session.gc_divisor => 1000 => 1000 session.gc_maxlifetime => 1440 => 1440 session.gc_probability => 1 => 1 session.hash_bits_per_character => 5 => 5 session.hash_function => 0 => 0 session.name => PHPSESSID => PHPSESSID session.referer_check => no value => no value session.save_handler => files => files session.save_path => /var/lib/php/session => /var/lib/php/session session.serialize_handler => php => php session.use_cookies => On => On session.use_only_cookies => Off => Off session.use_trans_sid => 0 => 0 shmop shmop support => enabled SimpleXML Simplexml support => enabled Revision => $Revision: 1.151.2.22 $ Schema support => enabled snmp NET-SNMP Support => enabled NET-SNMP Version => 5.3.2.2 sockets Sockets Support => enabled SPL SPL support => enabled Interfaces => Countable, OuterIterator, RecursiveIterator, SeekableIterator, SplObserver, SplSubject Classes => AppendIterator, ArrayIterator, ArrayObject, BadFunctionCallException, BadMethodCallException, CachingIterator, DirectoryIterator, DomainException, EmptyIterator, FilterIterator, InfiniteIterator, InvalidArgumentException, IteratorIterator, LengthException, LimitIterator, LogicException, NoRewindIterator, OutOfBoundsException, OutOfRangeException, OverflowException, ParentIterator, RangeException, RecursiveArrayIterator, RecursiveCachingIterator, RecursiveDirectoryIterator, RecursiveFilterIterator, RecursiveIteratorIterator, RuntimeException, SimpleXMLIterator, SplFileInfo, SplFileObject, SplObjectStorage, SplTempFileObject, UnderflowException, UnexpectedValueException standard Regex Library => Bundled library enabled Dynamic Library Support => enabled Path to sendmail => /usr/sbin/sendmail -t -i Directive => Local Value => Master Value assert.active => 1 => 1 assert.bail => 0 => 0 assert.callback => no value => no value assert.quiet_eval => 0 => 0 assert.warning => 1 => 1 auto_detect_line_endings => 0 => 0 default_socket_timeout => 60 => 60 safe_mode_allowed_env_vars => PHP_ => PHP_ safe_mode_protected_env_vars => LD_LIBRARY_PATH => LD_LIBRARY_PATH url_rewriter.tags => a=href,area=href,frame=src,input=src,form=fakeentry => a=href,area=href,frame=src,input=src,form=fakeentry user_agent => no value => no value sysvmsg sysvmsg support => enabled Revision => $Revision: 1.20.2.3 $ tokenizer Tokenizer Support => enabled wddx WDDX Support => enabled WDDX Session Serializer => enabled xml XML Support => active XML Namespace Support => active libxml2 Version => 2.6.26 xmlreader XMLReader => enabled xmlrpc core library version => xmlrpc-epi v. 0.51 php extension version => 0.51 author => Dan Libby homepage => http://xmlrpc-epi.sourceforge.net open sourced by => Epinions.com xmlwriter XMLWriter => enabled xsl XSL => enabled libxslt Version => 1.1.17 libxslt compiled against libxml Version => 2.6.26 EXSLT => enabled libexslt Version => 1.1.17 Zend Optimizer Optimization Pass 1 => enabled Optimization Pass 2 => enabled Optimization Pass 3 => enabled Optimization Pass 4 => enabled Optimization Pass 9 => enabled Zend Loader => enabled License Path => Obfuscation level => 3 zlib ZLib Support => enabled Stream Wrapper support => compress.zlib:// Stream Filter support => zlib.inflate, zlib.deflate Compiled Version => 1.2.3 Linked Version => 1.2.3 Directive => Local Value => Master Value zlib.output_compression => Off => Off zlib.output_compression_level => -1 => -1 zlib.output_handler => no value => no value Additional Modules Module Name dbase sysvsem sysvshm

You know, I'm thinking now, if the main reason I'm doing this is for security (protection against SQL injection), if I have to have a line of code that binds all the variables to the parameters in the SQL prepared statement anyway, why not save the hassle and just write a simple function that I can pass one or more variables to which returns their values sanitized by mysql_real_escape_string (and also escapes % which mysql_real_escape_string doesn't). Then I could leave all the rest of my code as-is and not convert to prepared statements. I'm I going to get some other MAJOR benefits going with prepared statements, other than performance in the context of executing SQL statements in loops with changing parameters?

Looks like I may have to go with PDO anyway since it does handle it by mysqli prepared statements looks like they don't? PDO::FETCH_ASSOC: returns an array indexed by column name as returned in your result set

That example isn't using prepared statements. Looks like I stumbled across a major short coming of prepared statements - looks like there is no method of returning results in an associative array without wirting your own function/class to do it. Read the comments from this manual page. You've got to be kidding me with prepared statements there's no $stmt->fetch_assoc() or $stmt->bind_assoc($some_array) function?!?! http://us2.php.net/manual/en/function.mysqli-stmt-fetch.php

I'm converting a site to use prepared statements. I want to use MySQLi instead of PDO (read this if you want to know why: http://dealnews.com/developers/php-mysql.html ) Can someone provide an example of a simply query that first binds a couple parameters than loops through the results with WHILE statement. I've figured everything out except I don't want to have to explicity bind all the results values to variables! I just want to loop throug the results set as rows of associative arrays. Having to bind all the results values would be a major PAIN! How do you just loop throught the results as associative arrays without having to bind the results when using prepared statements?

I suppose if you have a site what has lots of SQL calls in it already, a simpler way to squashing SQL injection would be to write a function that santizes an array, escaping \x00, \n, \r, \, ', ", \x1a and % for any variables used in the SQL statement? And just run it prior to preparing the statement? Seems though on a brand new site, it would be best to just start out using prepared statements from the beginning?

There a lot of code snippets out there for sanitizing input for XSS and SQL Injection vulnerabilities. Most codes use mysql_real_escape_string to protect against SQL Injection, although it doesn't sanitize % which means it is not 100% fullproof. For XSS there are lots of code snippets out there but none of them appear to use the new filter extension introduced in PHP 5.1 (which is enabled by default in 5.2). I now am able to protect an entire website for XSS vulnerabilities simply adding this at the top of the script: $_POST = filter_var_array($_POST,FILTER_SANITIZE_STRING); $_GET = filter_var_array($_GET,FILTER_SANITIZE_STRING); (I don't ever access $_REQUEST) The only downside I can see to this, is that for instance, in some cases I might want to allow HTML tags to be passed int the input, such as a simple News Article creation tool where I want the user to be able to include HTML tags that point to external images <img> or include links in the article <a>. There's a very popular input filter class at: http://www.phpclasses.org/browse/package/2189.html It is quite comprehensive and VERY configurable with separate functions for XSS and SQL Injection filters. For example on the XSS (process) filter I can specify exception to the tags it will filter such as <a> and <img> I believe many coders may filter their input one variable at a time. The fact of the matter SEEMS you can just do it in one fell swoop if you do need to allow HTML tags in ANY of your input at any time. Unfortunatly on SQL Injection you have clean each individual variable, unless you use prepared statements via PHP Data Objects with MySQL (PDO). So I'm doing a reality check as far as the cleanest, simplest way to squash XSS and SQL Injection vulnerabilities. It seems if I need to allow some HTML tags in input, but don't want to sanitize each individual input value, I'll need to use the input_filter class that allows me to specify exceptions as the new PHP built-in filter functions don't have that option. If I don't want to worry about sanitizing individual variables for each MySQL statement, I should just convert all my queries over to use prepared statements. Am I missing anything, or is there a better/easier/cleaner way?

Talking to myself... Found this article. Seems magic quotes ain't so magic. Taken out of PHP 6, so forget that as an easy solution I guess? http://www.tizag.com/phpT/php-magic-quotes.php

I've heard using prepared statement is the best (cleanest, most fullproof) way to prevent SQL injection. I've also read: "setting the magic_quotes_gpc php.ini variable to Off, will automatically apply addslashes to all values submitted via GET, POST or cookies. 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. Thus, most experienced developers elect to switch this feature off." The question is will turning magic quotes off, have some other bad side effects other than performance, and is the performance hit really an issue on a fairly underutilised server? Although we do perform some complex select statements that retrieve thousands of records at times. So what is it, go through the code and use prepared statements or just turn magic quotes off?

Ya, I see the point about XSS but that's not going to effect the website in question, just the client machine. At it is the user that is responsible for maintaining their client machine (running anti-virus and spyware protection, etc.). But I suppose it would be a little embarassing if someone did get infected a traced it to an XSS exploit on a major site, like cnn.com or something. It doesn't compromise your server, so your just looking out for the unprotected users out there. Correct me if I'm wrong.

I've got a few sites with older code that we need to patch for various security holes and I'm trying to determine the most efficient strategies for doing it. The three most common vulnerabilities we are currently focusing on are: 1) XSS Vulnerability on User Form Input Notes: Does someone want to explain to me why this is even that big a deal. This involves inserting Javascript code into form inputs that re-display the input. I'm unclear how this could compromise security on the server or for any other users other than the one viewing the page? Wouldn't this require some sort of a trojan on the client-side to really do anything or is there some JS code you could inject that would actually modify the server's pages for all users? Anyway I came across a well writting sanitizing function to filter XSS Javascript code from user input and just run all input through that function prior to processing it. I can't think of a simpler, easier way to address it site wide. Would there be a problem with writing a function that instead of santizing a passed value, it simply sanitizes ALL of the $_POST and $_GET values in a PHP script at the beginning of the script so you don't have to bother sanitizing each value individually? 2) SQL Injection - (inserting SQL syntax into user form input to modify a SQL query) Out of all the most common serious exploits, this is by far the most common. This is easily prevented by sanitizing all user input that could be used in a SQL query with something like the mysql_real_escape_string function in PHP, although it doesn't cover every single possibility as it does not allow for % characters if I'm correct. So I believe the way to be fullproof is to actually write your own sanitizing function? I'm curious what other methods people have implied? It would seem easier if you could just build your query then sanitize the query instead of the values, but I don't think that's possible as the sanitize function wouldn't know what is the legitimate query and what is the injection. The big question is, can there be a function which essentially does both without any harm, sanitizes all $_GET and $_POST values for XSS and SQL injection? It seems there must be some cases though where a legitimate value might get corrupted in the sanitization process but I can't think of any examples off hand. 3) URL modification This is more of a security logic issue than a universal exploit. An example would be if a UserID is passed in the URL and you modify it to another ID and it brings up the other users's information. In that case the solution is obviously to only pass the userID in a cookie. Or if there is say, an entity ID for something that 'belongs' to that user and you modify it to see the entity that belongs to another user. In that case you must check the cookie with the UserID and make sure it matches the entity owner's user ID. Doesn't seem like you can apply a single universal function to handle URL modification. Needs to be done on a case by case basis. Maybe though in the URL you could pass a hash of the value you don't want tampered with then check the hash? That seems like overkill. Seems URL modification has to be handled on a case by case basis. There's actually a 4th issue. 4) Hidden form values Some sites may pass sensitive information from page to page via a hidden form value, such as a password. This seem like a major problem on the face of it, but let's think about this a little more. The hidden value is only visible to the user of the client machine by virtue of viewing the HTML source. The only way it would be visible to another user is if someone else used the same machine and viewed the same page prior to the previous user's session ending. So say you made sure you removed the hidden values. Say you went even further to put a no-cache directive in the page so the back button wouldn't bring up the page AND you made sure there was like a 5 minute login timeout. That's essentially what many online banking sites do I guess. But still, if someone leaves their computer and another person sits down prior to the timeout, you've still got a problem. No 100% solution here. In fact, if a password was being passed as a hidden variable, someone would have to hope they left the PC and be smart enough to sit down and view the HTML source. Ya, like that's a really common occurence?! So would the best solution be to simply use an md5 hash of the actual value if you are going to pass the value in the hidden form. Seems better than storing it in a cookie, since someone could read the cookie values on a person's machine. Bottom line is always never store highly sensitive data in a cookie (or pass it in a hidden form variable) but it seems the cookie method is much more insecure, since the cookie file can remain on the person's machine indefinitely. I'd appreciate any feedback if anyone has some slick solutions or good points about these security issues. (Or maybe just a URL to a site that is the authority on handling this stuff. - sorry I'm really busy and don't have a lot of time to search all night - I type faster than I read Are there any other major/common exploits that commonly get overlooks when coding sites I'm not discussing?

We have an e-commerce site built from ground up with PERL. Lots of ad-hoc changes over the years so the code is heavily customized to the niche industry of the site, but not very optimized/well-organized and lacks some features. We want to convert our current E-commerce site from PERL to PHP, re-code much of it for better organization/efficiency and improve/add a lot of features (gift registry, better coupon issuance/acceptance, complex discounting rules, tighter integration with PayPal and Google Checkout, just to name a few). Instead of re-inventing the wheel on some of thee features we'd like to just take an existing modifiable PHP-based package and merge it's features with our own niche-specific features. After some considerable research, I decided on X-cart. I'm about 60% done with merging the code between the two systems and frankly, even as a fairly seasoned PHP coder, I've found X-cart's code to be unecessarily convoluted in places, especially for the checkout process, let alone the design of the checkout process shows that not a lot of knowledge on maximizing sales conversions was applied to the design. So we are heavily modifying the checkout process (amongst other areas of the code) and it's been a pain as the coding is organized in a fairly unintuitive mish-mash kind of way in my opinion although I realize that is to make the application flexible and modular so it can accept third party modules easily. Then, there's the dealing with updates now that we've modified it. We've figured out the utility to use to identify what's been modified so on the files we have customize we can manually patch them. The thing is, these updates seem to have a lot of security patches. So now I'm thinking, is it such a good idea to build a mid-tier e-commerce site based on such a widely distributed product instead of a fully custom product or lesser known cart-engine that won't draw the attention of so many hackers? (Not that coding from scratch won't have any security bugs.) But again, these features such as gift registry, conditional discounting, robust coupons/gift cert system (expiration dates, etc.) are pretty standard features that we don't want to waste time coding from scratch. I've heard CubeCart is easier to modify as the code is more simple, which may work for us as it is lesser known than X-cart and we just want a basic base to build off of. But I've heard overall X-cart is better. I've also heard good things about CS-Cart, but it sounds like it may actually be a little more difficult to customize the code than X-cart? Not sure. And finally I'm hearing good things about Viacart. Anyone have experience hacking up the code for X-cart and one of these other carts. Is X-cart still the best way to go considering my objectives? My gut is saying, we probably should just stick with X-cart, but I want to perform a reality check with people with similar objectives and experiences out there before investing a lot more time into hacking up X-cart. Thanks.

I've got a project where I'm maintaining the website and another group is maintaining the MySQL DB which we remotely access. We're using the mysqli library in our PHP code. We've had no problems connecting to the DB. They removed a user from MySQL, but not the one we use to logon to the DB. All of the sudden the website cannot connect to the DB anymore. I can connect fine still using the same credentials as the website if I connect from my local machine using SQLyog. Obviously they made some other changes other than just deleting one user account on MySQL. They're running version 5.0.45. I'm waiting to here back about what other changes they made but it strikes me odd the the website cannot connect and I can from SQLyog. It's almost as if the website is trying to connect on a different port or something and they closed the port, but we aren't specifying a port in the PHP code when we connect. Any suggestions as what to look for is much appreciated.

I'm testing a PHP app that uses the curl_exec to do an HTTPS POST to a website. The website is returning an error, thinking that I'm submitting a SOAP envelope instead of a regular HTTPS POST request, even though the Content-Type of the POST is application/x-www-form-urlencoded. I don't have control of the website I am posting to and want quicker turnaround on debug information. I doubt there is a way to force the curl_exec to simply echo everything it is POSTing to the server so I can see the headers and data? If not, does anyone know of a website I can point to that will accept and HTTPS POST and simply display everything in the POST for me?

I got it to work. One of those things where something is slightly mispelled an you don't notice it. Arghh!

Heck, I can't even get something like this to work. Is there a problem in PHP 4.4.x with passing variables to functions as references? function change(&$somevar) { $somevar = 20; } $test = 10; change($test); $somevar is empty inside the function and after exectuing it $test is still 10! Help!

Maybe I should elaborate: I have a function that assigns values to three arrays. It seems the best way to do this is pass them as arrays. So I'm calling the function like: setarrayvalues(&$array1,&$array2,&$array3); Then a function that sets the values: function setarrayvalues(&$somearray1,&$somearray2,&$somearray3) { array_push($somearray1,"some value"); . . . } I found initially my problem is that I wasn't initialliazing the array anywhere (still living in the PERL world). But I have to initialize the arrays in the function it doesn't work if I initialize them in the main program before I call the function! Doesn't make sense to me. At any rate the array is empty when it comes back from the function! function setarrayvalues(&$somearray1,&$somearray2,&$somearray3) { $somearray1 = array(); $somearray2 = array(); $somearray3 = array(); array_push($somearray1,"some value"); . . . }

Anyone know how to push values to an array that was passed to a function by reference. This doesn't work: function something(&$somearray) { array_push($somearray,"new value"); }