ID: 30698
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Bogus
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.3.9
New Comment:
I'm sorry - but I think I did understand what you wrote.
Perhaps the fact that you've needed to explain this to me does indicate
that the documentation here could be improved. I do still believe that 2
things would be beneficial:
ii)Clarify this sentence : "Single and double quotes are escaped by
backslashes in substituted backreferences."
[on manual/en/reference.pcre.pattern.modifiers.php]
>From this sentence, it is not clear, to me, at any rate, that:
modify("\\1") and modify('\\1')
will result in *different* outputs.
ii)A warning (somewhere) that this could potentially permit an SQL
injection attack, and the user ought to beware.
I do apologise for bugging you about this: I'm sure you have more
important things to worry about! If you'd prefer, I'll write something
about it in the user contributed notes.
Best wishes
Richard
Previous Comments:
------------------------------------------------------------------------
[2005-04-13 09:55:50] [EMAIL PROTECTED]
Content of ellipsis in my post is important for you to understand it:
modify("\\1") ... resulting in
------------------------------------------------------------------------
[2005-04-06 00:41:59] php at richardneill dot org
Sorry if I'm being daft here, but my reading of the documentation is
that both single and double quotes are always escaped.
However, as per your post:
modify('\\1') ....resulting in
single quote ', a double quote \", and a backslash\
modify("\\1") ... resulting in
single quote \', a double quote ", and a backslash\
My reading of this is that the first time (single quoted
backreference), only the double quotes, but not the single quotes are
escaped. The reverse is true the second time.
Perhaps a better sentence for the documentation would be
"Single XOR double quotes are escaped by backslashes in substituted
backreferences"
I apologise for getting them the wrong way round earlier!
My main point isn't that it works wrongly, but that the behaviour may
be confusing, and that especially for less wizardly programmers such as
myself, it would be helpful if it were spelled out a little more. I made
a mistake, which I was lucky to catch before I received an SQL injection
attack, and that's why I hope that other people will at least have more
warning before they err similarly.
Best wishes,
Richard
------------------------------------------------------------------------
[2005-04-05 19:28:03] [EMAIL PROTECTED]
The code is escaped, then executed. Read again the post from 5 Apr
3:46pm CEST.
------------------------------------------------------------------------
[2005-04-05 17:47:04] php at richardneill dot org
Sorry - I'm not thinking clearly today - need more coffee! Anyway, the
parts (ii) in my previous comment are complete nonsense, but the parts
(i) are true.
I still think that the documentation is wrong: it reads:
"Single AND double quotes are escaped by backslashes in substituted
backreferences"
whereas it should read:
"In single-quoted backreferences, single-quotes are escaped by
backslashes; double quotes are not escaped". The reverse applies for
double-quoted backreferences.
------------------
I also think that some sort of warning is important here (even if it's
just a link to another page). This is necessary because a double
escaped quote becomes an SQL injection issue. Eg:
User writes:
Here's a test.
After magic quoting:
Here\'s a test.
After preg_replace using ("\\1")
Here\\'s a test
SQL:
$sql="UPDATE table SET value='$input'";
Database query is:
UPDATE table SET value='Here\\'s a test'
which is parsed as literal \ followed by unescaped '
Which will fail.
Thus the user thinks that they are always safe because of magic-quotes,
but in fact they are NOT.
------------------------------------------------------------------------
[2005-04-05 16:59:43] [EMAIL PROTECTED]
Unescaped quotes doesn't cause parse error thanks to escaping provided
by /e.
<?php
echo preg_replace('~.*~e', '"\\0"', '"'); // ", no parse error
?>
I'm against messing this part with magic_qutes and SQL injection
issues.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30698
--
Edit this bug report at http://bugs.php.net/?id=30698&edit=1
