consultant1027
-
Posts
23 -
Joined
-
Last visited
Never
Posts posted by consultant1027
-
-
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?
-
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");
}
-e file exists & symbolic links - doesn't work?
in Linux
Posted
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?