php-general Digest 7 Oct 2011 23:23:38 -0000 Issue 7509
Topics (messages 315160 through 315169):
Re: Namespaced code with SabreDAV
315160 by: Tommy Pham
315166 by: Richard Quadling
Re: Secure data management
315161 by: Govinda
315165 by: Ian
315168 by: Paul M Foster
315169 by: Govinda
Re: Problem with code...
315162 by: tamouse mailing lists
315163 by: tamouse mailing lists
Re: Issues with simplexml_load_string()
315164 by: Benjamin Hawkes-Lewis
315167 by: Christoph Boget
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Thu, Oct 6, 2011 at 1:45 PM, Tommy Pham <tommy...@gmail.com> wrote:
> On Thu, Oct 6, 2011 at 7:37 AM, Andrew Mason <slackma...@gmail.com> wrote:
>
>> Hello all,
>> I am trying to use the wonderful SabreDAV library to create a webdav
>> share. I have a demo up and running however the framework / class i'm
>> using is namespaced, and SabreDAV unfortunately does not have a 5.3
>> style namespace declaration.
>>
>> I have an spl_autoload function registered in my base controller and
>> so long as I prefix the classname with a \ it all works:
>>
>>
>> $rootDirectory = new \Sabre_DAV_FS_Directory($rootDir);
>>
>> // The server object is responsible for making sense out of the WebDAV
>> protocol
>> $server = new \Sabre_DAV_Server($rootDirectory);
>>
>>
>> However, SabreDAV it's self has a large amount of other PHP classes
>> which it calls which obviously aren't prefixed with '\'
>>
>> Is there a way i can tell PHP any class name that get's instanciated
>> with 'Sabre_' should resolve to '\Sabre' ?
>>
>> Many thanks
>> Andrew
>>
>>
> If my memory serves regarding PHP's namespace, you could build something
> like this
>
> $file = APP_DIR.'\'.$class;
> if( file_exists( $file ) ) require_once $file;
>
> into your autoloader. You may have to adjust '/' to/from '\\' depending on
> your platform or you can use the constant DIRECTORY_SEPARATOR in the full
> path to the class. Then you don't need add \ before your class to
> instantiate. I don't know how the SabreDAV framework looks like but you may
> want to look at how Zend framework loads their class as to give you some
> idea what you may need to do in your autoload to circumvent SabreDAV being
> not 5.3 namespace declaration. You may also want to take a look at
> CodeIgniter's autoloading mechanism.
>
> Regards,
> Tommy
>
Here's another idea that you could do with the autoloader. The autoloader
is slightly modified from PureMVC's site to suit my needs. Using namespace
and everything that's PHP v5.3+, this is part of PureMVC framework that I've
ported over from the original Flash code a while back.
define( 'PMVC_BASE_DIR', str_replace( '\\', '/', __DIR__ ).'/' );
function __autoload( $class )
{
if( stristr( $class, '\\' ) )
{
$file = APP_DIR.str_replace( '\\', '/', $class ).EXT;
if( file_exists( $file ) ) require_once $file;
else throw new \Exception( 'Unable to find class '.$class.
' in the expected location '.$file );
} else
{
$_basePaths = array(
PMVC_BASE_DIR.'org/puremvc/php/patterns/facade/',
PMVC_BASE_DIR.'org/puremvc/php/interfaces/',
PMVC_BASE_DIR.'org/puremvc/php/core/',
PMVC_BASE_DIR.'org/puremvc/php/patterns/',
PMVC_BASE_DIR.'org/puremvc/php/patterns/command/',
PMVC_BASE_DIR.'org/puremvc/php/patterns/mediator/',
PMVC_BASE_DIR.'org/puremvc/php/patterns/observer/',
PMVC_BASE_DIR.'org/puremvc/php/patterns/proxy/' );
$classPaths = array_merge( explode( PATH_SEPARATOR,
get_include_path() ), $_basePaths );
foreach( $classPaths as $classPath )
{
$path = $classPath.$class.EXT;
if( file_exists( $path ) )
{
require_once $path;
return;
}
}
throw new \Exception( 'Unable to find class '.$class.' in '.
implode( PATH_SEPARATOR, $classPaths ) );
}
}
--- End Message ---
--- Begin Message ---
On 6 October 2011 15:37, Andrew Mason <slackma...@gmail.com> wrote:
> Hello all,
> I am trying to use the wonderful SabreDAV library to create a webdav
> share. I have a demo up and running however the framework / class i'm
> using is namespaced, and SabreDAV unfortunately does not have a 5.3
> style namespace declaration.
>
> I have an spl_autoload function registered in my base controller and
> so long as I prefix the classname with a \ it all works:
>
>
> $rootDirectory = new \Sabre_DAV_FS_Directory($rootDir);
>
> // The server object is responsible for making sense out of the WebDAV
> protocol
> $server = new \Sabre_DAV_Server($rootDirectory);
>
>
> However, SabreDAV it's self has a large amount of other PHP classes
> which it calls which obviously aren't prefixed with '\'
>
> Is there a way i can tell PHP any class name that get's instanciated
> with 'Sabre_' should resolve to '\Sabre' ?
>
> Many thanks
> Andrew
I've just downloaded SabreDav 1.5.3
Put Sabre directory in my include path.
And using the following code, ...
<?php
namespace GoingToBeUsingSabre;
require_once 'Sabre/autoload.php';
var_dump(new \Sabre_DAV_FS_Directory('D:/'));
print_r(array_filter(get_declared_classes(), function($class){ return
'Sabre_' === substr($class, 0, 6);}));
print_r(get_included_files());
?>
outputs ...
object(Sabre_DAV_FS_Directory)#1 (1) {
["path":protected]=>
string(3) "D:/"
}
Array
(
[166] => Sabre_DAV_FS_Node
[167] => Sabre_DAV_FS_Directory
)
Array
(
[0] => Z:\UsingSabre.php
[1] => D:\PHP\Includes\Sabre\autoload.php
[2] => D:\PHP\Includes\Sabre\DAV\FS\Directory.php
[3] => D:\PHP\Includes\Sabre\DAV\FS\Node.php
[4] => D:\PHP\Includes\Sabre\DAV\INode.php
[5] => D:\PHP\Includes\Sabre\DAV\ICollection.php
[6] => D:\PHP\Includes\Sabre\DAV\IQuota.php
)
They provide their own autoloader. As you can see, I've included their
autoloader and made 1 call to a root namespaced class. The registered
autoloader took care of the rest and loaded the additional classes as
needed.
Take a look at the Zend Framework's autoloader
(http://framework.zend.com/manual/en/zend.loader.autoloader.html)
Here is the same working example, but using ZF's autoloader ...
<?php
namespace GoingToBeUsingSabre;
require_once 'Zend/Loader/Autoloader.php';
$o_ZendLoaderAutoLoader = \Zend_Loader_Autoloader::getInstance();
$o_ZendLoaderAutoLoader->registerNamespace('Sabre_');
var_dump(new \Sabre_DAV_FS_Directory('D:/'));
print_r(array_filter(get_declared_classes(), function($class){ return
'Sabre_' === substr($class, 0, 6);}));
print_r(get_included_files());
?>
output now is ...
object(Sabre_DAV_FS_Directory)#2 (1) {
["path":protected]=>
string(3) "D:/"
}
Array
(
[168] => Sabre_DAV_FS_Node
[169] => Sabre_DAV_FS_Directory
)
Array
(
[0] => Z:\UsingSabre.php
[1] => D:\PHP\Includes\Zend\Loader\Autoloader.php
[2] => D:\PHP\Includes\Zend\Loader.php
[3] => D:\PHP\Includes\Sabre\DAV\FS\Directory.php
[4] => D:\PHP\Includes\Sabre\DAV\FS\Node.php
[5] => D:\PHP\Includes\Sabre\DAV\INode.php
[6] => D:\PHP\Includes\Sabre\DAV\ICollection.php
[7] => D:\PHP\Includes\Sabre\DAV\IQuota.php
)
Regards,
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--- End Message ---
--- Begin Message ---
>>>> http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
Hi everyone
I have read many many articles and blog posts in the last few days to bolster
my (still mostly newbie) understanding of the factors that play in to
preventing various methods of SQL injection prevention.. and by now I am well
aware that most everyone (expert) here says prepared statements are the most
secure method of (string hacking) SQL-injection prevention.. even to the point
of saying that one common (and at least previously-popular) alternative
"mysql-real-escape-string" is "..silly and technically insecure..".
I am learning and using the CodeIgniter (CI) framework for my current project
and, not wanting to leave myself vulnerable, I read posts on the CI forum on
this topic, to find out if I could (or needed) to use prepared statements in
CI.. and I read one forum thread where one dev shows how to hack the core
system of CI so that it can use PDO (for prepared statements) instead of the
built-in ActiveRecord (or "Query Bindings") which apparently rely on
mysql-real-escape-string. In that thread, the debate goes back and forth, as
it does in other threads.. and while the sentiment that prepared statements are
better because they remove the need to keep being ahead of the char-escaping
chase... I never did see any example of *how* mysql-real-escape-string fails.
The only thing I ever read that does show mysql-real-escape-string possibly
failing is in the example in this article:
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
or rather an article referred to there, here:
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
..which only comes up in certain circumstances..
("[snip]..The bottom line while the problem is serious, it would only affect
people changing character sets from single-byte encodings to multibyte ones. As
long as you stay away from multibyte encodings, with the exception of UTF8 you
should be safe...[snip]").
All well and good. I just wanted to understand, as a relative newbie, why such
bold seemingly definitive statements are made here on this list in recent
weeks, like ".. escaping doesn't work.." ?
http://marc.info/?l=php-general&m=131293616328301&w=2
http://marc.info/?l=php-general&m=131603743606025&w=2
Isn't it that it does work in most cases.. and one just needs to know in
which cases it can fail, and how to handle things in each case? I totally get
the point that prepared statements just remove so much of the head pressure of
sorting all this out.. BUT when someone (mostly new) like me comes along and
hears that "mysql-real-escape-string is simply not secure", then it just gives
an unclear and incomplete picture, and creates more head pressure.
Or is there definitive evidence, more recent than the above-mentioned articles,
that shows how to hack through mysql-real-escape-string even in an SQL
statement e.g. inserting into a UTF8 db, a properly escaped
(mysql-real-escape-string) var?
In case my post here is lacking understanding, then please forgive.. and better
yet, please explain! I post/ask because I am wanting to SEE the whole
everything like you few experts here who really know exactly what everyone is
talking about (or when they are just groping in the dark).
-Govinda
--- End Message ---
--- Begin Message ---
On 07/10/2011 05:46, Govinda wrote:
Hi everyone
I have read many many articles and blog posts in the last few days to bolster my (still mostly
newbie) understanding of the factors that play in to preventing various methods of SQL injection
prevention.. and by now I am well aware that most everyone (expert) here says prepared statements
are the most secure method of (string hacking) SQL-injection prevention.. even to the point of
saying that one common (and at least previously-popular) alternative
"mysql-real-escape-string" is "..silly and technically insecure..".
I am learning and using the CodeIgniter (CI) framework for my current project and, not
wanting to leave myself vulnerable, I read posts on the CI forum on this topic, to find
out if I could (or needed) to use prepared statements in CI.. and I read one forum thread
where one dev shows how to hack the core system of CI so that it can use PDO (for
prepared statements) instead of the built-in ActiveRecord (or "Query Bindings")
which apparently rely on mysql-real-escape-string. In that thread, the debate goes back
and forth, as it does in other threads.. and while the sentiment that prepared statements
are better because they remove the need to keep being ahead of the char-escaping chase...
I never did see any example of *how* mysql-real-escape-string fails. The only thing I
ever read that does show mysql-real-escape-string possibly failing is in the example in
this article:
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
or rather an article referred to there, here:
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
Hi,
Please bare in mind that the above example uses the mysql object, not
mysqli (the improved mysql extenstion). The above attack doesn't work
in mysqli (at least not in my setup!). There is also the issue of which
character set is used by mysqli_real_escape_string. To be sure issue
the mysqli_set_charset() call after connecting to the db.
With regards to procedure in MySQL, there is one gotcha that caught me
out. There is no way to ALTER a procedure, you must DROP and reCREATE
it again. This is fine in most GUIs such as Heidi SQL, as all the work
is done for you, but you must realize that when you issue the DROP
command it also DROPS any permissions you have on that procedure.
So to alter a procedure you must DROP, CREATE and then re-create the
permissions. If you have a replicated setup with multiple servers and
multiple web sites accessing them, this can be allot of permissions to
re-apply.
In web programming (or any other sort) you must ALWAYS assume that any
input is malicious. Using this principle you can then build secure
applications.
For example, the above article takes the $_POST input without any
validation. In this case it is a username. On my sites I tell users
when registering that their username can only contain certain
characters. If any other characters are supplied I strip them out.
I can then pass data to mysqli_real_escape_string knowing that there
will be no multi-byte characters in there to trip it up.
The same goes for other input, validate it all. There are built in
functions to do this for you [1], or you can build your own.
It is not just input to watch out for, you must also Escape your output
to mitigate Cross Site Scripting (XSS)[2] and other attacks.
There are many automated tools out there to help you test your
applications. You wont know its breakable unless you try to break it!
And if you don't, others will.
I suggest you go to the OWASP site [3] (The Open Web Application
Security Project) and have a look around.
Regards
Ian
--
[1] http://php.net/manual/en/ref.filter.php
[2] http://en.wikipedia.org/wiki/Cross-site_scripting
[3] https://www.owasp.org/index.php/Main_Page
--- End Message ---
--- Begin Message ---
On Fri, Oct 07, 2011 at 12:46:52AM -0400, Govinda wrote:
> >>>> http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
>
> Hi everyone
>
> I have read many many articles and blog posts in the last few days to
> bolster my (still mostly newbie) understanding of the factors that
> play in to preventing various methods of SQL injection prevention..
> and by now I am well aware that most everyone (expert) here says
> prepared statements are the most secure method of (string hacking)
> SQL-injection prevention.. even to the point of saying that one common
> (and at least previously-popular) alternative
> "mysql-real-escape-string" is "..silly and technically insecure..".
>
> I am learning and using the CodeIgniter (CI) framework for my current
> project and, not wanting to leave myself vulnerable, I read posts on
> the CI forum on this topic, to find out if I could (or needed) to use
> prepared statements in CI.. and I read one forum thread where one dev
> shows how to hack the core system of CI so that it can use PDO (for
> prepared statements) instead of the built-in ActiveRecord (or "Query
> Bindings") which apparently rely on mysql-real-escape-string. In that
> thread, the debate goes back and forth, as it does in other threads..
> and while the sentiment that prepared statements are better because
> they remove the need to keep being ahead of the char-escaping chase...
> I never did see any example of *how* mysql-real-escape-string fails.
> The only thing I ever read that does show mysql-real-escape-string
> possibly failing is in the example in this article:
>
> http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
>
> or rather an article referred to there, here:
> http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
>
> ..which only comes up in certain circumstances.. ("[snip]..The bottom
> line while the problem is serious, it would only affect people
> changing character sets from single-byte encodings to multibyte ones.
> As long as you stay away from multibyte encodings, with the exception
> of UTF8 you should be safe...[snip]").
>
> All well and good. I just wanted to understand, as a relative newbie,
> why such bold seemingly definitive statements are made here on this
> list in recent weeks, like ".. escaping doesn't work.." ?
>
> http://marc.info/?l=php-general&m=131293616328301&w=2
> http://marc.info/?l=php-general&m=131603743606025&w=2
>
> Isn't it that it does work in most cases.. and one just needs to
> know in which cases it can fail, and how to handle things in each
> case? I totally get the point that prepared statements just remove
> so much of the head pressure of sorting all this out.. BUT when
> someone (mostly new) like me comes along and hears that
> "mysql-real-escape-string is simply not secure", then it just gives
> an unclear and incomplete picture, and creates more head pressure.
>
> Or is there definitive evidence, more recent than the above-mentioned
> articles, that shows how to hack through mysql-real-escape-string even
> in an SQL statement e.g. inserting into a UTF8 db, a properly escaped
> (mysql-real-escape-string) var?
>
> In case my post here is lacking understanding, then please forgive..
> and better yet, please explain! I post/ask because I am wanting to
> SEE the whole everything like you few experts here who really know
> exactly what everyone is talking about (or when they are just groping
> in the dark).
There is more to SQL injection than getting the quoting correct. In my
understanding, prepared statements handles the other problems associated
with queries and SQL injection beyond just quoting. Here's a good
tutorial on how this works:
http://www.youtube.com/watch?v=bORZlmyDw0s
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
>>
> There is more to SQL injection than getting the quoting correct. In my
> understanding, prepared statements handles the other problems associated
> with queries and SQL injection beyond just quoting. Here's a good
> tutorial on how this works:
>
> http://www.youtube.com/watch?v=bORZlmyDw0s
Paul,
thanks.. I always appreciate more input as I cement my understanding of all the
various things to be aware of.
But here my question was coming from a slightly different angle than you seemed
to address.
You showed in that youtube video that type casting (if I said that right) might
be needed instead of mysql_real_escape_string() (in case the questionable input
is numeric instead of a string), but I was asking (essentially), "when is
mysql_real_escape_string() not enough for escaping *strings*?.. or, "when do we
have a case where one would normally trust escaping a user-input *string* by
using mysql_real_escape_string(), but where a clever hacker can get around?...
by, say, using some obscure multi-byte char?" - perhaps the way Chris Shiflett
shows how to hack past addslashes when using certain multi-byte character sets
in his article [1].
Again (for anyone following this thread), I understand that prepared statements
just remove so much of the headache.. but in case that is not available in some
setup, then when does mysql_real_escape_string() fail for escaping stings
(assuming the db/charset is UTF-8)?
[1] http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
-Govinda
--- End Message ---
--- Begin Message ---
On Thu, Oct 6, 2011 at 7:28 PM, Jason Pruim <li...@pruimphotography.com> wrote:
> Have a question about this block of code....
I'm not seeing anything immediately standing out as a problem.
> Sometimes... It is dropping the last $mailmessage line... The payment method
> in the actual email it sends...
Can you see if the last line is actually in $mailmessage before
sending the email? Maybe it's somehow getting truncated during the
mail step.
--- End Message ---
--- Begin Message ---
On Thu, Oct 6, 2011 at 7:28 PM, Jason Pruim <li...@pruimphotography.com> wrote:
> Have a question about this block of code....
I'm not seeing anything immediately standing out as a problem.
> Sometimes... It is dropping the last $mailmessage line... The payment method
> in the actual email it sends...
Can you see if the last line is actually in $mailmessage before
sending the email? Maybe it's somehow getting truncated during the
mail step.
*Update:* I just noticed this. The last line has no \r\n termination.
I'm thinking that may be necessary for some mailers/transports/etc?
--- End Message ---
--- Begin Message ---
On Thu, Oct 6, 2011 at 9:50 PM, Christoph Boget <jcbo...@hotmail.com> wrote:
> It seems like when dealing with nodes which have CDATA, I cannot get
> access to both the attributes of that node and the CDATA of that node
> with the same simplexml_load_string() call. Consider the following:
>
> $previewString =
> '<root><message><![CDATA[lkjlkjklj]]></message><buttons><button
> name="Add Me"><![CDATA[This is my free form
> text]]></button></buttons></root>';
>
> When passing LIBXML_NOCDATA:
>
> echo '<pre>' . print_r( json_decode( json_encode(
> (array)simplexml_load_string( $previewString, 'SimpleXMLElement',
> LIBXML_NOCDATA | LIBXML_NOBLANKS )), 1 ), TRUE ) . '</pre>';
>
> yields the following output :
>
> Array
> (
> [message] => lkjlkjklj
> [buttons] => Array
> (
> [button] => This is my free form text
> )
> )
>
> So I get the CDATA but I don't get the "name" attribute for the button.
http://us.php.net/manual/en/function.simplexml-load-string.php#80855 maybe?
--
Benjamin Hawkes-Lewis
--- End Message ---
--- Begin Message ---
> http://us.php.net/manual/en/function.simplexml-load-string.php#80855 maybe?
Thanks for that. I guess I should have scrolled a little further
down. It's so crazy that it works that way. Unless you export the
actual element (and not it's ancestors), you don't see the data at
all.
thnx,
Christoph
--- End Message ---
