php-general Digest 23 Jan 2012 20:19:01 -0000 Issue 7662
php-general Digest 23 Jan 2012 20:19:01 - 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 -- ---BeginMessage--- 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--- ---BeginMessage--- 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--- ---BeginMessage--- 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--- ---BeginMessage--- 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
[PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] php.net problems?
Hi, is anyone else having problems with PHP.net today? Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: sql injection protection
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 10 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
Re: [PHP] php.net problems?
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
Re: [PHP] php.net problems?
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
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
Re: [PHP] php.net problems?
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Status from secur...@php.net
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
Re: [PHP] Status from secur...@php.net
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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: sql injection protection
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.
[PHP] Update mailing list docs - How to unsubscribe?
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
[PHP] ArrayInterator always true
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
--
筆使文富，卻使人窮。
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Update mailing list docs - How to unsubscribe?
On Mon, 23 Jan 2012, Matty Sarro wrote: 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). list-unsubscribe: mailto:php-general-unsubscr...@lists.php.net Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
Daniel Brown wrote: 2012/1/23 Alex Nikitinniks...@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 Good!, thought I went insane there for a moment and couldn't remember any of the PHP functions... (as nothing was coming up in the search) ;-) Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
On Mon, Jan 23, 2012 at 15:59, Donovan Brooke li...@euca.us wrote: Good!, thought I went insane there for a moment and couldn't remember any of the PHP functions... (as nothing was coming up in the search) ;-) Can't it be both? ;-P -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
Daniel Brown wrote: On Mon, Jan 23, 2012 at 15:59, Donovan Brookeli...@euca.us wrote: Good!, thought I went insane there for a moment and couldn't remember any of the PHP functions... (as nothing was coming up in the search) ;-) Can't it be both? ;-P Purple cucumbers are automobile.. Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: sql injection protection
Start off with the fact that that article is from 2006, and its written by a programmer... 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. Escaping can work with a very specific set of circumstances, and it can be secure, however it fails as a security practice, and thus fails as a security solution. 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. I can't tell you for sure, however any project that uses it as their sole mean of sql injection protection can be exploited, yes. Just because OWASP says that it is a solution, doesn't mean that it's a good solution. Sometimes it's the only solution, yes, but it should not be the only security practice. 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. Any script that uses escaping as the sole means of protection, or doesn't do good checking, which is a lot of scripts. But i mean i hope it's no surprise, a lot of the web is vulnerable... 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! Sure, i have already mentioned it... The glorious base 64 hack... 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? A lot are... likewise UTF16, and even UTF8 can often be an issue. The issue with escaping is knowing what characters are bad, if you think you can escape a ' - tick and be safe, think again, in utf there are dozens if not hundreds of characters that can represent a tick in various circumstances. Again escaping fails as a security practice. Yes it can work and make your code uninjectable, but it still fails as a solution, even if secure... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php.net problems?
On Mon, Jan 23, 2012 at 16:30, Donovan Brooke li...@euca.us wrote: Purple cucumbers are automobile.. Mmm. *nods* Giggity. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Continued Problems Accessing *.php.net?
ALL: As you may have noticed, early this morning we got bored and decided to delete php.net from the Internet. After getting an estimated sixteen-point-four trillion complaints, we became overwhelmed and aggravated by your incessant need to RTFM that we pressed CTRL+Z and brought it back. You're welcome. In earnest, a catastrophic failure on one of our systems coincided with a migration effort being headed by some very talented folks. This led to a domino effect of issues that resulted in a temporary - but widespread - impact on the online version of the documentation and downloads. Things are nearly back to normal now across the network --- or so it seems. If you come across any issues on your favorite *.php.net mirror, please let us know at https://bugs.php.net/ or via a reply to this thread and we'll check it out. As a result, a list of the top ten reasons PHP had an outage today: 10.) We installed an experimental PECL module named Invisible Ink. 9.) We learned our indoor solar panels don't work when the lights get turned off. 8.) We had our mobile bandwidth slowed to a crawl because we exceeded 2GB for the month. 7.) A Groupon swarm for two free downloads for the price of one killed our network. 6.) We whited out this time to protest another Patriots/Giants Superbowl, while the BC Lions never even got a phone call. 5.) Our build of mod_expires runs on the Mayan calendar, and attempting to do a 60-day expire segfaulted. 4.) The $25.90 check we wrote to cover the server's AOL dial-up bounced. 3.) It's Chinese New Year, but it was too cold to set off the fireworks outside today, so sorry. 2.) As it turned out, all our base truly were belong to them. 1.) We needed 7,500,001 signatures on the petition against SOPA/PIPA. Thanks to all for your patience and such. And, of course, apologies to all. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
On 12-01-23 01:32 PM, Alex Nikitin wrote: 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 Hi Alex, If you're processing a large number of files, the bottleneck could just as likely be the hard drive read/write and not so much PHP. And what's a large number of files? 50? 100? 1000? 100? Remember, PHP internal functions are usually wrappers around compiled C code... the shuffling around in the PHP engine itself can be quite tiny. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Continued Problems Accessing *.php.net?
I don't know what all the fuss was about. What's wrong with you people. That document has been there for so many years... you should have memorized it by now! -- Ghodmode http://www.ghodmode.com On Tue, Jan 24, 2012 at 7:22 AM, Daniel Brown danbr...@php.net wrote: ALL: As you may have noticed, early this morning we got bored and decided to delete php.net from the Internet. After getting an estimated sixteen-point-four trillion complaints, we became overwhelmed and aggravated by your incessant need to RTFM that we pressed CTRL+Z and brought it back. You're welcome. In earnest, a catastrophic failure on one of our systems coincided with a migration effort being headed by some very talented folks. This led to a domino effect of issues that resulted in a temporary - but widespread - impact on the online version of the documentation and downloads. Things are nearly back to normal now across the network --- or so it seems. If you come across any issues on your favorite *.php.net mirror, please let us know at https://bugs.php.net/ or via a reply to this thread and we'll check it out. As a result, a list of the top ten reasons PHP had an outage today: 10.) We installed an experimental PECL module named Invisible Ink. 9.) We learned our indoor solar panels don't work when the lights get turned off. 8.) We had our mobile bandwidth slowed to a crawl because we exceeded 2GB for the month. 7.) A Groupon swarm for two free downloads for the price of one killed our network. 6.) We whited out this time to protest another Patriots/Giants Superbowl, while the BC Lions never even got a phone call. 5.) Our build of mod_expires runs on the Mayan calendar, and attempting to do a 60-day expire segfaulted. 4.) The $25.90 check we wrote to cover the server's AOL dial-up bounced. 3.) It's Chinese New Year, but it was too cold to set off the fireworks outside today, so sorry. 2.) As it turned out, all our base truly were belong to them. 1.) We needed 7,500,001 signatures on the petition against SOPA/PIPA. Thanks to all for your patience and such. And, of course, apologies to all. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
Have you done image processing? In my experience, with image generation, photography and processing, typically you are bound by resources when processing large amount of files than your connection, or sometimes even disk io. -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Mon, Jan 23, 2012 at 7:51 PM, Robert Cummings rob...@interjinn.com wrote: On 12-01-23 01:32 PM, Alex Nikitin wrote: 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 Hi Alex, If you're processing a large number of files, the bottleneck could just as likely be the hard drive read/write and not so much PHP. And what's a large number of files? 50? 100? 1000? 100? Remember, PHP internal functions are usually wrappers around compiled C code... the shuffling around in the PHP engine itself can be quite tiny. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
On 12-01-23 09:29 PM, Alex Nikitin wrote: Have you done image processing? In my experience, with image generation, photography and processing, typically you are bound by resources when processing large amount of files than your connection, or sometimes even disk io. It really depends on what you're doing with images, if it's intensive processing that's already implemented in the gd or imagick library to which you can just punt, then how much overhead do you think PHP is really going to add since these are C implemented libraries? Sure, if you are manipulating pixels one by one within your PHP code you may be running into resource issues, but for scaling images, or cropping, or even clipping and overlaying... you're not usually doing a whole lot within PHP itself. The love is happening in the C code in these cases. This is why when working with these libs you get a resource handle and not a string. The resource handle almost certainly maps to a native GD or imagick structure. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Reading only RGB portion of an image, file_get_conents minus file headers etc
Absolutely agreed. A part of what i was asking deals with what he is actually doing... -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Mon, Jan 23, 2012 at 9:37 PM, Robert Cummings rob...@interjinn.com wrote: On 12-01-23 09:29 PM, Alex Nikitin wrote: Have you done image processing? In my experience, with image generation, photography and processing, typically you are bound by resources when processing large amount of files than your connection, or sometimes even disk io. It really depends on what you're doing with images, if it's intensive processing that's already implemented in the gd or imagick library to which you can just punt, then how much overhead do you think PHP is really going to add since these are C implemented libraries? Sure, if you are manipulating pixels one by one within your PHP code you may be running into resource issues, but for scaling images, or cropping, or even clipping and overlaying... you're not usually doing a whole lot within PHP itself. The love is happening in the C code in these cases. This is why when working with these libs you get a resource handle and not a string. The resource handle almost certainly maps to a native GD or imagick structure. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
