php-general Digest 23 Jan 2012 20:19:01 -0000 Issue 7662
Topics (messages 316355 through 316374):
Reading only RGB portion of an image, file_get_conents minus file headers etc
316355 by: Nicholas Cooper
316356 by: Matijn Woudt
316357 by: Nicholas Cooper
316358 by: Matijn Woudt
316359 by: Nicholas Cooper
316365 by: Alex Nikitin
php.net problems?
316360 by: Donovan Brooke
316361 by: Xavier Del Castillo
316363 by: Curtis Maurand
316364 by: Alex Nikitin
316366 by: Dpto Ingeniería y Desarrollo
316367 by: TR Shaw
316368 by: Alex Nikitin
316371 by: Daniel Brown
Re: sql injection protection
316362 by: Alex Nikitin
316372 by: Haluk Karamete
Status from secur...@php.net
316369 by: TR Shaw
316370 by: Daniel Brown
Update mailing list docs - How to unsubscribe?
316373 by: Matty Sarro
ArrayInterator always true
316374 by: TCP
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 ---
Hi everyone,
I've created an image in RGB from ImageMagick, it's 4 by 4 so I'm
expecting 48 numbers (4*4*3). [width*height*(R,G,B)]
When I read the file with PHP and unpack it I get between 330 and 333,
I guess this difference is down to headers and end of file data. Is
there anyway to access only the useful image bits, those 48 numbers?
Thank you,
Nicholas Cooper
--- End Message ---
--- Begin Message ---
On Mon, Jan 23, 2012 at 1:51 PM, Nicholas Cooper <nicho...@twpagency.com> wrote:
> Hi everyone,
>
> I've created an image in RGB from ImageMagick, it's 4 by 4 so I'm
> expecting 48 numbers (4*4*3). [width*height*(R,G,B)]
>
> When I read the file with PHP and unpack it I get between 330 and 333,
> I guess this difference is down to headers and end of file data. Is
> there anyway to access only the useful image bits, those 48 numbers?
>
> Thank you,
>
> Nicholas Cooper
>
Hi,
The easiest way is probably using imagecolorat[1]. Just do a nested
for loop over x and y values, and call imagecolorat for each pixel.
Matijn
[1] www.php.net/imagecolorat
--- End Message ---
--- Begin Message ---
On 23 January 2012 13:26, Matijn Woudt <tijn...@gmail.com> wrote:
> On Mon, Jan 23, 2012 at 1:51 PM, Nicholas Cooper <nicho...@twpagency.com>
> wrote:
>> Hi everyone,
>>
>> I've created an image in RGB from ImageMagick, it's 4 by 4 so I'm
>> expecting 48 numbers (4*4*3). [width*height*(R,G,B)]
>>
>> When I read the file with PHP and unpack it I get between 330 and 333,
>> I guess this difference is down to headers and end of file data. Is
>> there anyway to access only the useful image bits, those 48 numbers?
>>
>> Thank you,
>>
>> Nicholas Cooper
>>
>
> Hi,
>
> The easiest way is probably using imagecolorat[1]. Just do a nested
> for loop over x and y values, and call imagecolorat for each pixel.
>
> Matijn
>
> [1] www.php.net/imagecolorat
Thank you that does the trick and gives the expected output. I plan
to be processing a large number of images and have always been wary of
using the built in image functions for performance reasons. So if
there is any other solutions I'm welcome to them, or even if someone
just wants to say that performance is not such an issue any more.
--- End Message ---
--- Begin Message ---
On Mon, Jan 23, 2012 at 3:26 PM, Nicholas Cooper <nicho...@twpagency.com> wrote:
> On 23 January 2012 13:26, Matijn Woudt <tijn...@gmail.com> wrote:
>> On Mon, Jan 23, 2012 at 1:51 PM, Nicholas Cooper <nicho...@twpagency.com>
>> wrote:
>>> Hi everyone,
>>>
>>> I've created an image in RGB from ImageMagick, it's 4 by 4 so I'm
>>> expecting 48 numbers (4*4*3). [width*height*(R,G,B)]
>>>
>>> When I read the file with PHP and unpack it I get between 330 and 333,
>>> I guess this difference is down to headers and end of file data. Is
>>> there anyway to access only the useful image bits, those 48 numbers?
>>>
>>> Thank you,
>>>
>>> Nicholas Cooper
>>>
>>
>> Hi,
>>
>> The easiest way is probably using imagecolorat[1]. Just do a nested
>> for loop over x and y values, and call imagecolorat for each pixel.
>>
>> Matijn
>>
>> [1] www.php.net/imagecolorat
>
> Thank you that does the trick and gives the expected output. I plan
> to be processing a large number of images and have always been wary of
> using the built in image functions for performance reasons. So if
> there is any other solutions I'm welcome to them, or even if someone
> just wants to say that performance is not such an issue any more.
If the image you want to process is a simple bitmap (.bmp) file, then
you can easily parse it yourself. Wikipedia has a page on the file
format [1].
In short, fopen your file, fseek to 0x000A, read 4 bytes, and parse
them as little-endian (with unpack or so). fseek to that value, and
then you can read 4*4*3 bytes with fseek. That is your RGB data, if it
is in that format ofcourse. If you're not sure which format they are
you might need to parse more of the BMP header, but that's up to you.
Matijn
[1] http://en.wikipedia.org/wiki/BMP_file_format
--- End Message ---
--- Begin Message ---
On 23 January 2012 14:34, Matijn Woudt <tijn...@gmail.com> wrote:
> On Mon, Jan 23, 2012 at 3:26 PM, Nicholas Cooper <nicho...@twpagency.com>
> wrote:
>> On 23 January 2012 13:26, Matijn Woudt <tijn...@gmail.com> wrote:
>>> On Mon, Jan 23, 2012 at 1:51 PM, Nicholas Cooper <nicho...@twpagency.com>
>>> wrote:
>>>> Hi everyone,
>>>>
>>>> I've created an image in RGB from ImageMagick, it's 4 by 4 so I'm
>>>> expecting 48 numbers (4*4*3). [width*height*(R,G,B)]
>>>>
>>>> When I read the file with PHP and unpack it I get between 330 and 333,
>>>> I guess this difference is down to headers and end of file data. Is
>>>> there anyway to access only the useful image bits, those 48 numbers?
>>>>
>>>> Thank you,
>>>>
>>>> Nicholas Cooper
>>>>
>>>
>>> Hi,
>>>
>>> The easiest way is probably using imagecolorat[1]. Just do a nested
>>> for loop over x and y values, and call imagecolorat for each pixel.
>>>
>>> Matijn
>>>
>>> [1] www.php.net/imagecolorat
>>
>> Thank you that does the trick and gives the expected output. I plan
>> to be processing a large number of images and have always been wary of
>> using the built in image functions for performance reasons. So if
>> there is any other solutions I'm welcome to them, or even if someone
>> just wants to say that performance is not such an issue any more.
>
>
> If the image you want to process is a simple bitmap (.bmp) file, then
> you can easily parse it yourself. Wikipedia has a page on the file
> format [1].
>
> In short, fopen your file, fseek to 0x000A, read 4 bytes, and parse
> them as little-endian (with unpack or so). fseek to that value, and
> then you can read 4*4*3 bytes with fseek. That is your RGB data, if it
> is in that format ofcourse. If you're not sure which format they are
> you might need to parse more of the BMP header, but that's up to you.
>
> Matijn
>
> [1] http://en.wikipedia.org/wiki/BMP_file_format
Thank you, I haven't quite managed to find the start of my 16 bytes,
but I get the idea, so I should be able to get this working after
reading more about the format.
--- End Message ---
--- Begin Message ---
If you don't mind me asking, if you want performance, which is kind of
essential if you are processing a large number of files, why are you
doing it in PHP?
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
--- End Message ---
--- Begin Message ---
Hi, is anyone else having problems with PHP.net today?
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
On 01/23/2012 10:28 AM, Donovan Brooke wrote:
Hi, is anyone else having problems with PHP.net today?
Donovan
Working fine from here. Do a traceroute to the site, it might an ISP
related problem.
Xavier
--- End Message ---
--- Begin Message ---
Xavier Del Castillo wrote:
> On 01/23/2012 10:28 AM, Donovan
Brooke wrote:
>> Hi, is anyone else having problems with
PHP.net today?
>>
>> Donovan
>>
>>
> Working fine from here. Do a traceroute to the site,
it might an ISP
> related problem.
>
>
It
came right up for me.
--Curtis
--- End Message ---
--- Begin Message ---
Can't get to doc at all here...
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
--- End Message ---
--- Begin Message ---
I can access to php.net, but in the 'Documentation', it doesn't show the
View online formats
Also, I can't search a function in "Search for '' in the function list"
form.
And if i try access to a url from google result, as
php.net/manual/es/function.in-array.php
i get the following answer:
not found
edit: right now, in the Documentation - View Oline Formats, it shows
only the "English" option
I can access to
php.net/manual/en/function.in-array.php
but not
php.net/manual/es/function.in-array.php
El 23/01/12 19:27, Curtis Maurand escribió:
Xavier Del Castillo wrote:
On 01/23/2012 10:28 AM, Donovan
Brooke wrote:
Hi, is anyone else having problems with
PHP.net today?
Donovan
Working fine from here. Do a traceroute to the site,
it might an ISP
related problem.
It
came right up for me.
--Curtis
--
Dpto. Ingeniería y Desarrollo
ingenie...@ort-telecomunicaciones.es
ORT Telecomunicaciones
Tlfno: (+34) 951 221 005
--- End Message ---
--- Begin Message ---
From here is US everthing is hosed. Also hosed in CA mirrors. Additionally
site says last updated today at 15:20:19 MST bit it is 11:40 MST!
On Jan 23, 2012, at 1:36 PM, Dpto Ingeniería y Desarrollo wrote:
> I can access to php.net, but in the 'Documentation', it doesn't show the View
> online formats
>
> Also, I can't search a function in "Search for '' in the function list" form.
>
> And if i try access to a url from google result, as
> php.net/manual/es/function.in-array.php
>
> i get the following answer:
> not found
>
> edit: right now, in the Documentation - View Oline Formats, it shows only the
> "English" option
> I can access to
> php.net/manual/en/function.in-array.php
>
> but not
> php.net/manual/es/function.in-array.php
>
>
> El 23/01/12 19:27, Curtis Maurand escribió:
>>
>> Xavier Del Castillo wrote:
>>> On 01/23/2012 10:28 AM, Donovan
>> Brooke wrote:
>>>> Hi, is anyone else having problems with
>> PHP.net today?
>>>> Donovan
>>>>
>>>>
>>> Working fine from here. Do a traceroute to the site,
>> it might an ISP
>>> related problem.
>>>
>>>
>> It
>> came right up for me.
>>
>> --Curtis
>>
>
> --
> Dpto. Ingeniería y Desarrollo
> ingenie...@ort-telecomunicaciones.es
> ORT Telecomunicaciones
> Tlfno: (+34) 951 221 005
>
>
--- End Message ---
--- Begin Message ---
Rasmus confirmed that they are having issues with php.net:
You can use the sk.php.net mirror while they fix their problems, as
well as docs.php.net.
--- End Message ---
--- Begin Message ---
2012/1/23 Alex Nikitin <niks...@gmail.com>:
> Rasmus confirmed that they are having issues with php.net:
>
> You can use the sk.php.net mirror while they fix their problems, as
> well as docs.php.net.
We had a primary system failure at the same time as a migration
was underway, which led to complications and subsequent failures of
the mirroring network. The issues are being resolved and mirrors are
coming back online. In the meantime, you may use one of the following
mirrors:
http://ca2.php.net/
http://sk.php.net/
http://docs.php.net/
And, until the matter is completely resolved, you can temporarily
change your mirror preference at the bottom of this page:
http://php.net/my.php
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
There is so much no, answers are in line.
> At the top of each php page which interacts with a database, just have
> this one liner
This has already been mentioned, but again, no, no connection if you
are not actually interacting with the database.
> $DBH = safe_connection("database_name_here"); //$DBH stands for
> database handle
Another no, obfuscating away the user/pass doesn't make it a "safe"
function. Not saying there is no benefit to it, but where i would say
you would benefit is from making this into a singleton object for
example...
> obviously the safe_connection is not a built-in PHP function so we
> have to come up with it...
>
> The idea behind this "safe_connection" function is this;
>
> It takes the dbname, uses it in looking up to retrieve the database
> username, the password, the host name and the hostname, and the host
> type ( whether the host is mysql or mssql etc) - for the specified
> database.
Shouldn't it also accept access type, for example i don't want to use
a user with input privileges if i am just looking stuff up in the
database... Also what year are we in? You do this, at least make it an
object so i dont need to remember what prefix i need to call...
> Then it uses all this data to establish a db connection and thus get
> the $DBHandle.
Yeah with an unknown type...
> Once the $DBHandle is obtained, then mysql_real_escape_string ( or the
> mysqli_real_escape_string version ) can be used....
> (However, the mentioned mysql_real_escape_string function here would
> be the right choice **only if** the hosttype is mysql! ) So, that;s
> where we use the hosttype. Microsoft SQL may require a different
> escaping mechanism.
Did you not read anything i wrote above? Escape=fail... use a PDO
prepare and exec methods...
> Now, the question is where do we use this mysql_real_escape_string function?
You DON'T!
> Well, on the usual suspects! the dirty 5 arrays; namely _GET, _POST,
> _COOKIE, _REQUEST and the _SERVER. Yes, the _SERVER too. ( that's due
> to the http_referer, remote_addr etc spoofing ).
>
> Here is a basic example handling the _GET array!
>
> foreach ($_GET as $k => $v)
> {
> $_GET[$k] = mysql_real_escape_string($v); // this is good if
> host type is mysql...
> }
>
> So, the basic idea is to clean up the entire GET array and be safe and
> thorough. And do this across all global arrays where a user input can
> possible come from.
No, no, owies, no... you don't want to escape everything, for one
thing, i can pass you anything i want to in get or post, including
100, or 100000 8 meg files. You only use what you need out of the
arrays, ignore everything else
> So, with this one liner function, called right at the beginning of
> your script, you not only get a DBHandle to do your queries but also
> get the assurance that the userinput is safe so you can get into
> busines instantly as follows;
>
> $safe_firstname = $_GET['firstname'];
>
> How easy is that!
tail -n 1 | sed -i "s/easy/horribly\sinefficient/"
> (To keep the basic idea short, I did not get into the magic_quotes_gpc
> and stripslashes() matter. But I assume people reading this message
> know whey are and how they get used.
>
> So, if you just focus on the basic idea, what do you say? ARE WE STILL NOT OK?
Yes, All Your Base still Are Belong To Pen-testers!
> Do we still need PDO?
If you haven't gotten it yet from my last 2 replies, YES!!!!
> My answer to this question is ABSOLUTELY NO. But this NO is as far as
> the SQLInjection woes. PDO may offer other advantages warranting its
> use but as far as the SQLInjection is concerned and when we know that
> the data has been thoroughly escaped like this, using PDO will not
> make it any safer. Absolutely NOT.
Did you not read my last 2 replies, yes PDO will make it safer,
because escaping still FAILS! Another failure of your pseudo-code is
that it fails to go through a data-validation cycle
> Do we all agree on that? It's a plain YES or NO question right here.
NO
> As far as the C. Shifflet's article and Ilia's follow up post (
> http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
> ) is concerned, the only thing we need to worry about is whether we
> are working with GBK character code, Chinese character set that is. If
> we got nothing to do with GBK char set, then the technique I covered
> above will suffice and cover us safely, conveniently and effortlessly.
> But if you do work with GBK and you do that in your script by actually
> running this ( mysql_query("SET CHARACTER SET 'gbk'", $c); ), then the
> above technique will doom you. Then PDO is your only bet, but
> otherwise, we are OK.
no, no you are not...
> As far as the escaping, I know you were against that. Here is what
> you said about the escaping.
Oh hey, look, after many countless hours of researching the topic and
testing, and talking to other people who have done similar research,
and testing, and attending security conferences and writing papers for
developers of ISP-grade solutions, writing frameworks and secure code,
and breaking all that; I summarized and articulated the problems with
interoperability of languages and failures of poor solutions to those
problem... Of course you know better.
> Correct me if I'm wrong,
>
> IF WE ARE NOT CHANGING THE CHAR SET WITHIN THE SCRIPT USING SOMETHING
> LIKE "SET CHARACTER SET", THEN WHAT"S WRONG WITH ESCAPING WITH THE
> RECOMMENDED UTILITY FOR THE SQL HOST AT HAND? From Ilia's post, I
> understand that even if the character set was to be GBK at server's
> config level, we would be fine. Here is the excerpt from that very
> section.
Facepalm.
Don't scream.
You have no choice in the matter. When i send you something in UTF7,
it will go through the escape as utf7, since apache will push whatever
i send into your vars, web servers don't care about the char set, and
PHP doesnt care what's in the var either, especially in terms of a
char set, so, it will hit your database as utf7, which will change it
to UTF8 for example or whatever its default charset is... And wait,
what just happened?
Also you make it seem like this is the recommended solution, fact is,
it is not recommended by either the PHP or the MySQL developers who
wrote those very functions.
I have outlined why escaping fails, i have outlined how it fails, and
i have outlined how to go around it, i have outlined how it fails as a
security principle, i have outlined how to fix it. If you think you
have a more secure implementation than the one that just prohibits the
code injection possibility by eliminating the execution user-input
data, feel free to get owned... I am getting tired of repeating
myself, so if i have to say "escaping fails" one more time, i will
just start ignoring this thread
--- End Message ---
--- Begin Message ---
I was simply asking expert opinion with the intention to learn.
There is so much docs out there (I mean not just out there but at top
security sites like owasp ) that recommends database specific escape
solution as one of the viable alternatives.
You make it seem like anyone who does not use PDO ( for one reason or
another ), and rely on the mysql_real_escape_string can be by passed
and SQL injected.
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_3:_Escaping_All_User_Supplied_Input
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
<quote from
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html>
So you're saying the mysql_real_escape_string() isn't 100% secure either?
Crikey, if that's true, then I'm willing to bet A LOT of scripts are
"vulnerable" to this problem.
Is there a fix that doesn't involve perpared statements? Perhaps a
function that checks for this problem, and filters it? My
charset/encoding knowledge is a bit limited, so I'd very much
appreciate an answer. Thanks!
#1 Dennis Pallett (Homepage) on 2006-01-22 14:08 (Reply)
As Ilia points out, it only applies to situations where the script
actually modifies the charset, for instance using SET CHARACTER SET.
Personally, I've never used this functionality and if you haven't
either you're fine.
#1.1 jome on 2006-01-22 14:48 (Reply)
That is precisely what the example demonstrates. 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.
#1.2 Ilia Alshanetsky (Homepage) on 2006-01-22 15:15 (Reply)
</quote>
I don't understand from what you say here...
When i send you something in UTF7, it will go through the escape as
utf7, since apache will push whatever i send into your vars, web
servers don't care about the char set, and PHP doesnt care what's in
the var either, especially in terms of a char set, so, it will hit
your database as utf7, which will change it to UTF8 for example or
whatever its default charset is...
Is it really that simple? It's hard to believe that all these
implementations out there that honors the recommended filter &
database specific escape mechanisms would *easily* be vulnerable by
simply someone sending ut7, is that what you are saying?
On Mon, Jan 23, 2012 at 10:26 AM, Alex Nikitin <niks...@gmail.com> wrote:
> There is so much no, answers are in line.
>
>> At the top of each php page which interacts with a database, just have
>> this one liner
>
> This has already been mentioned, but again, no, no connection if you
> are not actually interacting with the database.
>
>> $DBH = safe_connection("database_name_here"); //$DBH stands for
>> database handle
>
> Another no, obfuscating away the user/pass doesn't make it a "safe"
> function. Not saying there is no benefit to it, but where i would say
> you would benefit is from making this into a singleton object for
> example...
>
>> obviously the safe_connection is not a built-in PHP function so we
>> have to come up with it...
>>
>> The idea behind this "safe_connection" function is this;
>>
>> It takes the dbname, uses it in looking up to retrieve the database
>> username, the password, the host name and the hostname, and the host
>> type ( whether the host is mysql or mssql etc) - for the specified
>> database.
>
> Shouldn't it also accept access type, for example i don't want to use
> a user with input privileges if i am just looking stuff up in the
> database... Also what year are we in? You do this, at least make it an
> object so i dont need to remember what prefix i need to call...
>
>> Then it uses all this data to establish a db connection and thus get
>> the $DBHandle.
>
> Yeah with an unknown type...
>
>> Once the $DBHandle is obtained, then mysql_real_escape_string ( or the
>> mysqli_real_escape_string version ) can be used....
>> (However, the mentioned mysql_real_escape_string function here would
>> be the right choice **only if** the hosttype is mysql! ) So, that;s
>> where we use the hosttype. Microsoft SQL may require a different
>> escaping mechanism.
>
> Did you not read anything i wrote above? Escape=fail... use a PDO
> prepare and exec methods...
>
>> Now, the question is where do we use this mysql_real_escape_string function?
>
> You DON'T!
>
>> Well, on the usual suspects! the dirty 5 arrays; namely _GET, _POST,
>> _COOKIE, _REQUEST and the _SERVER. Yes, the _SERVER too. ( that's due
>> to the http_referer, remote_addr etc spoofing ).
>>
>> Here is a basic example handling the _GET array!
>>
>> foreach ($_GET as $k => $v)
>> {
>> $_GET[$k] = mysql_real_escape_string($v); // this is good if
>> host type is mysql...
>> }
>>
>> So, the basic idea is to clean up the entire GET array and be safe and
>> thorough. And do this across all global arrays where a user input can
>> possible come from.
>
> No, no, owies, no... you don't want to escape everything, for one
> thing, i can pass you anything i want to in get or post, including
> 100, or 100000 8 meg files. You only use what you need out of the
> arrays, ignore everything else
>
>> So, with this one liner function, called right at the beginning of
>> your script, you not only get a DBHandle to do your queries but also
>> get the assurance that the userinput is safe so you can get into
>> busines instantly as follows;
>>
>> $safe_firstname = $_GET['firstname'];
>>
>> How easy is that!
>
> tail -n 1 | sed -i "s/easy/horribly\sinefficient/"
>
>> (To keep the basic idea short, I did not get into the magic_quotes_gpc
>> and stripslashes() matter. But I assume people reading this message
>> know whey are and how they get used.
>>
>> So, if you just focus on the basic idea, what do you say? ARE WE STILL NOT
>> OK?
>
> Yes, All Your Base still Are Belong To Pen-testers!
>
>> Do we still need PDO?
>
> If you haven't gotten it yet from my last 2 replies, YES!!!!
>
>> My answer to this question is ABSOLUTELY NO. But this NO is as far as
>> the SQLInjection woes. PDO may offer other advantages warranting its
>> use but as far as the SQLInjection is concerned and when we know that
>> the data has been thoroughly escaped like this, using PDO will not
>> make it any safer. Absolutely NOT.
>
> Did you not read my last 2 replies, yes PDO will make it safer,
> because escaping still FAILS! Another failure of your pseudo-code is
> that it fails to go through a data-validation cycle
>
>> Do we all agree on that? It's a plain YES or NO question right here.
>
> NO
>
>> As far as the C. Shifflet's article and Ilia's follow up post (
>> http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
>> ) is concerned, the only thing we need to worry about is whether we
>> are working with GBK character code, Chinese character set that is. If
>> we got nothing to do with GBK char set, then the technique I covered
>> above will suffice and cover us safely, conveniently and effortlessly.
>> But if you do work with GBK and you do that in your script by actually
>> running this ( mysql_query("SET CHARACTER SET 'gbk'", $c); ), then the
>> above technique will doom you. Then PDO is your only bet, but
>> otherwise, we are OK.
>
> no, no you are not...
>
>> As far as the escaping, I know you were against that. Here is what
>> you said about the escaping.
>
> Oh hey, look, after many countless hours of researching the topic and
> testing, and talking to other people who have done similar research,
> and testing, and attending security conferences and writing papers for
> developers of ISP-grade solutions, writing frameworks and secure code,
> and breaking all that; I summarized and articulated the problems with
> interoperability of languages and failures of poor solutions to those
> problem... Of course you know better.
>
>> Correct me if I'm wrong,
>>
>> IF WE ARE NOT CHANGING THE CHAR SET WITHIN THE SCRIPT USING SOMETHING
>> LIKE "SET CHARACTER SET", THEN WHAT"S WRONG WITH ESCAPING WITH THE
>> RECOMMENDED UTILITY FOR THE SQL HOST AT HAND? From Ilia's post, I
>> understand that even if the character set was to be GBK at server's
>> config level, we would be fine. Here is the excerpt from that very
>> section.
>
> Facepalm.
>
> Don't scream.
>
> You have no choice in the matter. When i send you something in UTF7,
> it will go through the escape as utf7, since apache will push whatever
> i send into your vars, web servers don't care about the char set, and
> PHP doesnt care what's in the var either, especially in terms of a
> char set, so, it will hit your database as utf7, which will change it
> to UTF8 for example or whatever its default charset is... And wait,
> what just happened?
>
>
> Also you make it seem like this is the recommended solution, fact is,
> it is not recommended by either the PHP or the MySQL developers who
> wrote those very functions.
>
> I have outlined why escaping fails, i have outlined how it fails, and
> i have outlined how to go around it, i have outlined how it fails as a
> security principle, i have outlined how to fix it. If you think you
> have a more secure implementation than the one that just prohibits the
> code injection possibility by eliminating the execution user-input
> data, feel free to get owned... I am getting tired of repeating
> myself, so if i have to say "escaping fails" one more time, i will
> just start ignoring this thread
--- End Message ---
--- Begin Message ---
Begin forwarded message:
> Subject: Re: None of the US and CA sites work anymore
>
> Hi,
>
> thanks for the notice. We're already aware of it and working on fixing
> this within short time.
>
> https://twitter.com/#!/rasmus/status/161493308416335872
>
> johannes
>
> On Mon, 2012-01-23 at 13:37 -0500, TR Shaw wrote:
>>
>> None of the US and CA sites work anymore Some pages even generate
>> errors on main page others give semi blank pages when searching for a
>> function.
>>
>> Running dual stack from OSX. (I reverted to IPv4 only with no change)
>>
>> Please advise
>>
>> Tom
>>
>>
>
--- End Message ---
--- Begin Message ---
On Mon, Jan 23, 2012 at 13:52, TR Shaw <ts...@oitc.com> wrote:
>>
>> On Mon, 2012-01-23 at 13:37 -0500, TR Shaw wrote:
>>>
>>> None of the US and CA sites work anymore Some pages even generate
>>> errors on main page others give semi blank pages when searching for a
>>> function.
CA2 does indeed work:
http://ca2.php.net/
The rest are coming up with time.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
Hey everyone,
I have been trying to unsubscribe from this list. I've gone through the
directions at http://www.ezmlm.org/ezman/ezman1.html as suggested by
http://us.php.net/mailing-lists.php. They don't seem to apply for these
lists as written (the method listed for unsubscribing involves sending an
email to mailinglist-unsubscr...@example.org, which in this case would be
mailinglist-unsubscr...@lists.php.net which sends back a lovely "invalid
email address" response).
A little guidance would be fantastic, thank you!
-Matty
--- End Message ---
--- Begin Message ---
I'm trying to parse an $agrv array that contain options (without
square brackets): [-a "abc" -b "bbc" "bcc" -d "dbc" -e -f]
I use ArrayIterator to iterate through the line:
- whenever it reach /-\w/, it read through the following qoutes
until it reach another /-\w/.
The problem is it seems the $iterator->valid() always return TRUE and
cause infinte loop.
function parseOptions ( $argStream, $handler ) {
//Chop first useless argument -- argv[0]
array_shift ( $argStream ) ;
//Initiate ArrayObject for iterator
$arrayobject = new ArrayObject ( $argStream ) ;
//Initiate iterator for iteration
$iterator = $arrayobject->getIterator();
//If options is set first
if( $iterator->valid() && preg_match ( '/^-\w$/', $iterator->current()
) ) {
//iterate through whole argument stream
for ( ; $iterator->valid(); $iterator->next() ) {
//Check if reached next option
if( preg_match ( '/^-\w$/', $opts =
$iterator->current() ) ) {
//Get current options
$currOpt = $opts;
//echo "$currOpt\n";
//Test if next stream is an option
for ($iterator->next(); $iterator->valid();
$iterator->next() ) {
if ( preg_match ( '/^-\w$/', $opts =
$iterator->current() ) ) {
//echo "$currOpt $opts\n";
//$handler($currOpt, $opts);
$currOpt = $opts;
}
var_dump($iterator->valid());
}
}//End if
//echo "$currOpt $opts\n";
//$handler($currOpt, $opts);
}// End for
//If option is not set first.
} else {
//Try other approach.
}// End if
}
I've no idea what is going on.
Please help.
Regards,
Panguin
--
筆使文富，卻使人窮。
--- End Message ---
