[PHP] Re: Oauth consumer and provider gives signature_invalid error
hi again. it look likes my code is ugly so no one wants to play with it :D. rewrote the consumer and provider code using only the php provided classes/methods. I have borrowed code from http://www.lornajane.net/posts/2011/php-oauth-provider-request-tokens and http://toys.lerdorf.com/archives/55-Writing-an-OAuth-Provider-Service.html. still it's same invalid signature exception. This time it's in localhost,consumer on port 3000 and provider on port 5000. new consumer code http://pastebin.com/ndEhP8Rv and provider code http://pastebin.com/SfdKu3nQ . it's my second week struggling with this code. any help would be really appreciate. ~Chamila Gayan On Mon, Oct 3, 2011 at 12:34 PM, chamila gayan cgcham...@gmail.com wrote: hi All, I'm trying develop Oauth consumer and provider as very same way of twitter. I followed the below tutorials. Here is my consumer code http://pastebin.com/39sxKbuz and here is my provider code http://pastebin.com/xtEsrTGf when I run the client it gives error as follow Array ( [oauth_problem] = signature_invalid [debug_sbs] = GET [http%253A%252F%252Fwww.abc.loc%252Foauth%252Frequesttoken] = [oauth_consumer_key%253D1d7259a770e0732d191bb566b5cf9e%2526oauth_nonce%253Db4168962db5559eb55859f1699622d07%2526oauth_signature_method%253DHMAC-SHA1%2526oauth_timestamp%253D1317621581%2526oauth_version%253D1.0%2526route%253Doauth%25252Frequesttoken] = ) may be I'm doing this in a wrong way or not understood properly so your suggestions are welcome. And I really appreciate if someone can explain what are the wrong codes here and how I correct them. thanks a bunch . ~Chamila Gayan
[PHP] php on my pc, no go, FUBAR, thank you Bill Gates?
I installed it in a Windows XP PC with a cgi capable server in it. No dice, nothing happens. I also installed python in the same computer. Works perfect. NEITHER language modified the http server. So, what do I have to do to get php to play well with others in a XP environment? Cute remarks about install Linux shall be ignored as line-noise. -- end Very Truly yours, - Kirk Bailey, Largo Florida kniht +-+ | BOX | +-+ think -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php on my pc, no go, FUBAR, thank you Bill Gates?
On Tue, Oct 4, 2011 at 09:47, Kirk Bailey kbai...@howlermonkey.net wrote: I installed it in a Windows XP PC with a cgi capable server in it. No dice, nothing happens. I also installed python in the same computer. Works perfect. NEITHER language modified the http server. So, what do I have to do to get php to play well with others in a XP environment? Cute remarks about install Linux shall be ignored as line-noise. To just get up and go, consider using a Windows package such as XAMPP. It'll automatically install and configure the basics. -- /Daniel P. Brown Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting (866-) 725-4321 http://www.parasane.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php on my pc, no go, FUBAR, thank you Bill Gates?
On Tue, Oct 4, 2011 at 9:47 AM, Kirk Bailey kbai...@howlermonkey.net wrote: I installed it in a Windows XP PC with a cgi capable server in it. No dice, nothing happens. I also installed python in the same computer. Works perfect. NEITHER language modified the http server. So, what do I have to do to get php to play well with others in a XP environment? Cute remarks about install Linux shall be ignored as line-noise. -- end Very Truly yours, - Kirk Bailey, Largo Florida kniht +-+ | BOX | +-+ think -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Kirk, Are you running this via IIS or Apache? If IIS, download and install the MS Web Platform app. Use that to install drupal or wordpress and it will install PHP and mysql for you running under IIS -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php on my pc, no go, FUBAR, thank you Bill Gates?
On 4 October 2011 14:47, Kirk Bailey kbai...@howlermonkey.net wrote: I installed it in a Windows XP PC with a cgi capable server in it. No dice, nothing happens. I also installed python in the same computer. Works perfect. NEITHER language modified the http server. So, what do I have to do to get php to play well with others in a XP environment? Cute remarks about install Linux shall be ignored as line-noise. If install Linux is going to be ignored as line-noise, what about RTFM? Starting at http://docs.php.net/manual/en/install.windows.php and choosing your particular web server. I would also pay attention to manual installation (http://docs.php.net/manual/en/install.windows.manual.php) and command line working (http://docs.php.net/manual/en/install.windows.commandline.php). -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] detect file upload time
hi everybody, is any method available for detect file upload time in a php script ? or detect network connections upload speed. i'm using php 5.3.5(xampp 1.7.4) and my os is windows 7. thank you regards kanishka
Re: [PHP] detect file upload time
On Tue 04 Oct 2011 09:05:30 PM IST, Kanishka wrote: hi everybody, is any method available for detect file upload time in a php script ? or detect network connections upload speed. i'm using php 5.3.5(xampp 1.7.4) and my os is windows 7. thank you regards kanishka It's not possible with just php, you need javascript (ajax). The reason is, when a php script is executed, the data from GET, POST is already made available by the server. You need to send the system time with the file when the upload button was clicked and then compute the difference after you've saved the file on the server. Or, the php script echoes something out. -- Nilesh Govindarajan http://nileshgr.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Secure data management
I thought I knew how to do this. I have a form that collects some data fields. My script checks if magic quotes are off and (since they are) executes addslashes on each input field. Then I run a query to INSERT these 'slashed' vars into the database. But when I go to phpadmin on my site the table does not contain any slashes. Where are they going? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure data management
On 4 Oct 2011, at 20:23, Jim Giner wrote: I thought I knew how to do this. I have a form that collects some data fields. My script checks if magic quotes are off and (since they are) executes addslashes on each input field. Then I run a query to INSERT these 'slashed' vars into the database. But when I go to phpadmin on my site the table does not contain any slashes. Where are they going? 1. Why are you using addslashes? 2. MySQL will strip one level of backslashes. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Secure data management
On 10/04/2011 02:23 PM, Jim Giner wrote: I thought I knew how to do this. I have a form that collects some data fields. My script checks if magic quotes are off and (since they are) executes addslashes on each input field. Then I run a query to INSERT these 'slashed' vars into the database. But when I go to phpadmin on my site the table does not contain any slashes. Where are they going? The slashes escape data just to tell the database that those characters are data. The database doesn't insert the slash, that would be unwanted. Not all databases use the slash as an escape character and for the ones that do you should use the X_real_escape_string(), like mysql_real_escape_string() instead of addslashes() -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure data management
Stuart Dallas stu...@3ft9.com wrote in message news:da8b3499-4d11-4053-9834-68b34d030...@3ft9.com... 1. Why are you using addslashes? 2. MySQL will strip one level of backslashes. * I thought you were supposed to do an addslashes to protect your appl from malicious d/e. Did not know that mysql drops the slashes. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure data management
On Tue, Oct 4, 2011 at 2:44 PM, Jim Giner jim.gi...@albanyhandball.com wrote: I thought you were supposed to do an addslashes to protect your appl from malicious d/e. To protect your app from malicious stuff going to SQL queries, you should be using prepared statements, see http://php.net/manual/en/pdo.prepared-statements.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On 4 Oct 2011, at 20:30, Shawn McKenzie wrote: On 10/04/2011 02:23 PM, Jim Giner wrote: I thought I knew how to do this. I have a form that collects some data fields. My script checks if magic quotes are off and (since they are) executes addslashes on each input field. Then I run a query to INSERT these 'slashed' vars into the database. But when I go to phpadmin on my site the table does not contain any slashes. Where are they going? The slashes escape data just to tell the database that those characters are data. The database doesn't insert the slash, that would be unwanted. Not all databases use the slash as an escape character and for the ones that do you should use the X_real_escape_string(), like mysql_real_escape_string() instead of addslashes() http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Secure data management
On 4 Oct 2011, at 20:44, Jim Giner wrote: Stuart Dallas stu...@3ft9.com wrote in message news:da8b3499-4d11-4053-9834-68b34d030...@3ft9.com... 1. Why are you using addslashes? 2. MySQL will strip one level of backslashes. * I thought you were supposed to do an addslashes to protect your appl from malicious d/e. Adding slashes to the data is nowhere near enough protection. Jeremiah is right in saying that prepared statements are the best option available at the moment. Did not know that mysql drops the slashes. I recommend that you look further into why you are doing things like that, especially when it's security-related. The more you know about what is happening and why the better your software will be. In this particular case, the slashes are designed to mark quotes as part of the data and not the end of the data. For example... this is an unescaped string containing a quotation mark The MySQL parser will see the in the middle and decide that that's the end of the data. However... this is an escaped string containing \ a quotation mark The parser will see the \ before the and that tells it the quote is part of the data. Because the \ is only there to tell it that it doesn't get left in the data when it's pushed into the database. But escaping quotes (i.e. addslashes) is not enough to protect against SQL injection, and neither is mysql_real_escape_string as Shawn suggested. Prepared statements are the best option. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
Hi. On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote: http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ Thanks. I followed this link through and read the full message (having missed it the first time round), and while I find the idea of using base64 to sanitise text interesting I can also forsee a few difficulties: It would prevent anyone from accessing the database directly and getting meaningful results unless the en/decode is in triggers, or maybe stored procedures. No more one-off command-line queries. How would you search an encoded column for matching text? I'd be interested in any ideas folk have about these issues, or any others they can envisage with this proposal. Cheers, Mark -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On 5 Oct 2011, at 00:04, Mark Kelly wrote: Hi. On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote: http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ Thanks. I followed this link through and read the full message (having missed it the first time round), and while I find the idea of using base64 to sanitise text interesting I can also forsee a few difficulties: It would prevent anyone from accessing the database directly and getting meaningful results unless the en/decode is in triggers, or maybe stored procedures. No more one-off command-line queries. How would you search an encoded column for matching text? I'd be interested in any ideas folk have about these issues, or any others they can envisage with this proposal. Base64 encoding will work when the native base64 functions are available in MySQL which will allow you to base64 encode the data into a statement like INSERT INTO table SET field = FROM_BASE64(?php echo base64_encode($data); ?) sorta thing. I'm still not a massive fan of that idea given that prepared statements are an option, but it would work. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote: On 5 Oct 2011, at 00:04, Mark Kelly wrote: Hi. On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote: http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ Thanks. I followed this link through and read the full message (having missed it the first time round), and while I find the idea of using base64 to sanitise text interesting I can also forsee a few difficulties: It would prevent anyone from accessing the database directly and getting meaningful results unless the en/decode is in triggers, or maybe stored procedures. No more one-off command-line queries. How would you search an encoded column for matching text? I'd be interested in any ideas folk have about these issues, or any others they can envisage with this proposal. Base64 encoding will work when the native base64 functions are available in MySQL which will allow you to base64 encode the data into a statement like INSERT INTO table SET field = FROM_BASE64(?php echo base64_encode($data); ?) sorta thing. I'm still not a massive fan of that idea given that prepared statements are an option, but it would work. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- Inserting and updating isn't the problem. I think Mark referring to is how would that be implemented in this simple type of query: SELECT * FROM my_table WHERE col_name LIKE '%key word%'; If there's no viable mean to filter the data, that storage method/medium is rather pointless, IMHO.
Re: [PHP] Re: Secure data management
On 5 Oct 2011, at 00:45, Tommy Pham wrote: On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote: On 5 Oct 2011, at 00:04, Mark Kelly wrote: Hi. On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote: http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ Thanks. I followed this link through and read the full message (having missed it the first time round), and while I find the idea of using base64 to sanitise text interesting I can also forsee a few difficulties: It would prevent anyone from accessing the database directly and getting meaningful results unless the en/decode is in triggers, or maybe stored procedures. No more one-off command-line queries. How would you search an encoded column for matching text? I'd be interested in any ideas folk have about these issues, or any others they can envisage with this proposal. Base64 encoding will work when the native base64 functions are available in MySQL which will allow you to base64 encode the data into a statement like INSERT INTO table SET field = FROM_BASE64(?php echo base64_encode($data); ?) sorta thing. I'm still not a massive fan of that idea given that prepared statements are an option, but it would work. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- Inserting and updating isn't the problem. I think Mark referring to is how would that be implemented in this simple type of query: SELECT * FROM my_table WHERE col_name LIKE '%key word%'; If there's no viable mean to filter the data, that storage method/medium is rather pointless, IMHO. Go back and read what I wrote again. Base64 is only being used to transmit the data to MySQL - it's being stored in the database in its decoded form. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 4:49 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:45, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:04, Mark Kelly wrote:
Hi.
On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote:
http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
Thanks. I followed this link through and read the full message (having
missed
it the first time round), and while I find the idea of using base64 to
sanitise text interesting I can also forsee a few difficulties:
It would prevent anyone from accessing the database directly and getting
meaningful results unless the en/decode is in triggers, or maybe stored
procedures. No more one-off command-line queries.
How would you search an encoded column for matching text?
I'd be interested in any ideas folk have about these issues, or any
others
they can envisage with this proposal.
Base64 encoding will work when the native base64 functions are available
in MySQL which will allow you to base64 encode the data into a statement
like INSERT INTO table SET field = FROM_BASE64(?php echo
base64_encode($data); ?) sorta thing. I'm still not a massive fan of that
idea given that prepared statements are an option, but it would work.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
Inserting and updating isn't the problem. I think Mark referring to is how
would that be implemented in this simple type of query:
SELECT * FROM my_table WHERE col_name LIKE '%key word%';
If there's no viable mean to filter the data, that storage method/medium is
rather pointless, IMHO.
Go back and read what I wrote again. Base64 is only being used to transmit
the data to MySQL - it's being stored in the database in its decoded form.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
The question still applies as how would you safeguard that 'key word'
transmission, especially against SQL injection. I suppose one could do it
this way:
SELECT * FROM my_table WHERE col_name LIKE CONCAT('%', FROM_BASE64(?php
echo base64_encode($data); ?), '%')
Is the overhead worth it to warrant that kind of safeguard? That's just a
simple query with a simple search criteria. What about in the case of
subselect and multi-table joins?
Re: [PHP] Re: Secure data management
On 5 Oct 2011, at 01:13, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:49 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:45, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:04, Mark Kelly wrote:
Hi.
On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote:
http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
Thanks. I followed this link through and read the full message (having
missed
it the first time round), and while I find the idea of using base64 to
sanitise text interesting I can also forsee a few difficulties:
It would prevent anyone from accessing the database directly and getting
meaningful results unless the en/decode is in triggers, or maybe stored
procedures. No more one-off command-line queries.
How would you search an encoded column for matching text?
I'd be interested in any ideas folk have about these issues, or any others
they can envisage with this proposal.
Base64 encoding will work when the native base64 functions are available in
MySQL which will allow you to base64 encode the data into a statement like
INSERT INTO table SET field = FROM_BASE64(?php echo base64_encode($data);
?) sorta thing. I'm still not a massive fan of that idea given that
prepared statements are an option, but it would work.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
Inserting and updating isn't the problem. I think Mark referring to is how
would that be implemented in this simple type of query:
SELECT * FROM my_table WHERE col_name LIKE '%key word%';
If there's no viable mean to filter the data, that storage method/medium is
rather pointless, IMHO.
Go back and read what I wrote again. Base64 is only being used to transmit
the data to MySQL - it's being stored in the database in its decoded form.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
The question still applies as how would you safeguard that 'key word'
transmission, especially against SQL injection. I suppose one could do it
this way:
SELECT * FROM my_table WHERE col_name LIKE CONCAT('%', FROM_BASE64(?php
echo base64_encode($data); ?), '%')
Is the overhead worth it to warrant that kind of safeguard? That's just a
simple query with a simple search criteria. What about in the case of
subselect and multi-table joins?
That would indeed be logical if base64 was your chosen method of protection,
but I think prepared statements are a far more elegant solution. As for the
overhead I very much doubt there's much difference between that and the
overhead of prepared statements.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 5:51 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 01:13, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:49 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:45, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:04, Mark Kelly wrote:
Hi.
On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote:
http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
Thanks. I followed this link through and read the full message (having
missed
it the first time round), and while I find the idea of using base64 to
sanitise text interesting I can also forsee a few difficulties:
It would prevent anyone from accessing the database directly and
getting
meaningful results unless the en/decode is in triggers, or maybe stored
procedures. No more one-off command-line queries.
How would you search an encoded column for matching text?
I'd be interested in any ideas folk have about these issues, or any
others
they can envisage with this proposal.
Base64 encoding will work when the native base64 functions are available
in MySQL which will allow you to base64 encode the data into a statement
like INSERT INTO table SET field = FROM_BASE64(?php echo
base64_encode($data); ?) sorta thing. I'm still not a massive fan of that
idea given that prepared statements are an option, but it would work.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
Inserting and updating isn't the problem. I think Mark referring to is
how would that be implemented in this simple type of query:
SELECT * FROM my_table WHERE col_name LIKE '%key word%';
If there's no viable mean to filter the data, that storage method/medium
is rather pointless, IMHO.
Go back and read what I wrote again. Base64 is only being used to transmit
the data to MySQL - it's being stored in the database in its decoded form.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
The question still applies as how would you safeguard that 'key word'
transmission, especially against SQL injection. I suppose one could do it
this way:
SELECT * FROM my_table WHERE col_name LIKE CONCAT('%', FROM_BASE64(?php
echo base64_encode($data); ?), '%')
Is the overhead worth it to warrant that kind of safeguard? That's just a
simple query with a simple search criteria. What about in the case of
subselect and multi-table joins?
That would indeed be logical if base64 was your chosen method of
protection, but I think prepared statements are a far more elegant solution.
As for the overhead I very much doubt there's much difference between that
and the overhead of prepared statements.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
IIRC, prepared statements doesn't incur any overhead. Instead, it's
supposed to enhance performance by telling SQL to 'prepare' via
compilation. So if you're comparing performance between the overhead of
base64 vs prepared statement, then the difference would be quite clear,
especially when the table(s) is/are more than a couple hundred thousand rows
and the queri(es) are complex. This is not mention the added complexity
into the application where managing and expanding it would incur real
(developer time) overhead, IMO.
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 7:51 PM, Stuart Dallas stu...@3ft9.com wrote: As for the overhead I very much doubt there's much difference between that and the overhead of prepared statements. Probably not. As an aside, I'm really struggling to find a case where it'd be worth base64-encoding the queries like that unless you were both concerned about someone sniffing your queries over the wire and sure that they wouldn't think to base-64 decode them. Not to mention that if your grand idea to prevent eavesdropping is simple transforms, you've got a larger problem on your hands. It *will* work, as mysql's base64 decoder won't evaluate the decoded string as a statement, afaik, but it will also expand the size of stuff by around 30% while having a, imo, much better solution widely available. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On 5 Oct 2011, at 02:02, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 5:51 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 01:13, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:49 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:45, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:04, Mark Kelly wrote:
Hi.
On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote:
http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
Thanks. I followed this link through and read the full message (having
missed
it the first time round), and while I find the idea of using base64 to
sanitise text interesting I can also forsee a few difficulties:
It would prevent anyone from accessing the database directly and getting
meaningful results unless the en/decode is in triggers, or maybe stored
procedures. No more one-off command-line queries.
How would you search an encoded column for matching text?
I'd be interested in any ideas folk have about these issues, or any others
they can envisage with this proposal.
Base64 encoding will work when the native base64 functions are available in
MySQL which will allow you to base64 encode the data into a statement like
INSERT INTO table SET field = FROM_BASE64(?php echo base64_encode($data);
?) sorta thing. I'm still not a massive fan of that idea given that
prepared statements are an option, but it would work.
Inserting and updating isn't the problem. I think Mark referring to is how
would that be implemented in this simple type of query:
SELECT * FROM my_table WHERE col_name LIKE '%key word%';
If there's no viable mean to filter the data, that storage method/medium is
rather pointless, IMHO.
Go back and read what I wrote again. Base64 is only being used to transmit
the data to MySQL - it's being stored in the database in its decoded form.
The question still applies as how would you safeguard that 'key word'
transmission, especially against SQL injection. I suppose one could do it
this way:
SELECT * FROM my_table WHERE col_name LIKE CONCAT('%', FROM_BASE64(?php
echo base64_encode($data); ?), '%')
Is the overhead worth it to warrant that kind of safeguard? That's just a
simple query with a simple search criteria. What about in the case of
subselect and multi-table joins?
That would indeed be logical if base64 was your chosen method of protection,
but I think prepared statements are a far more elegant solution. As for the
overhead I very much doubt there's much difference between that and the
overhead of prepared statements.
IIRC, prepared statements doesn't incur any overhead. Instead, it's supposed
to enhance performance by telling SQL to 'prepare' via compilation. So if
you're comparing performance between the overhead of base64 vs prepared
statement, then the difference would be quite clear, especially when the
table(s) is/are more than a couple hundred thousand rows and the queri(es)
are complex. This is not mention the added complexity into the application
where managing and expanding it would incur real (developer time) overhead,
IMO.
Prepared statements incur an additional hit against the DB server to prepare
the statement.
The cost of using base64 in the manner suggested is minimal, regardless of the
size of the data. The MySQL query analyser is intelligent enough to know that
from_base64('xyz') is a constant expression and will therefore only evaluate it
once.
As for the added complexity, if you have SQL statements all over your code then
yes it will add a time overhead, but any codebase of a significant size should
be using a centralised API for database access such that changes like this have
a very limited scope.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 6:07 PM, Jeremiah Dodds jeremiah.do...@gmail.comwrote: On Tue, Oct 4, 2011 at 7:51 PM, Stuart Dallas stu...@3ft9.com wrote: As for the overhead I very much doubt there's much difference between that and the overhead of prepared statements. Probably not. As an aside, I'm really struggling to find a case where it'd be worth base64-encoding the queries like that unless you were both concerned about someone sniffing your queries over the wire and sure that they wouldn't think to base-64 decode them. Not to mention that if your grand idea to prevent eavesdropping is simple transforms, If that's the case, then SSL would be a better solution since it also protects the authentication process. In then end, I still don't see base64 as a viable solution. you've got a larger problem on your hands. It *will* work, as mysql's base64 decoder won't evaluate the decoded string as a statement, afaik, but it will also expand the size of stuff by around 30% while having a, imo, much better solution widely available.
Re: [PHP] Re: Secure data management
On 5 Oct 2011, at 02:07, Jeremiah Dodds wrote: On Tue, Oct 4, 2011 at 7:51 PM, Stuart Dallas stu...@3ft9.com wrote: As for the overhead I very much doubt there's much difference between that and the overhead of prepared statements. Probably not. As an aside, I'm really struggling to find a case where it'd be worth base64-encoding the queries like that unless you were both concerned about someone sniffing your queries over the wire and sure that they wouldn't think to base-64 decode them. Not to mention that if your grand idea to prevent eavesdropping is simple transforms, you've got a larger problem on your hands. I don't see a reason to use base64 to solve the SQL injection problem either, especially with prepared statements available, but that doesn't mean it won't work. As far as protecting data during transit, that's what SSL is for. Base64 is not an encryption mechanism. It *will* work, as mysql's base64 decoder won't evaluate the decoded string as a statement, afaik, but it will also expand the size of stuff by around 30% while having a, imo, much better solution widely available. It will indeed increase the size of the queries, but unless you're running Facebook, LAN capacity is very rarely a bottleneck. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 8:15 PM, Tommy Pham tommy...@gmail.com wrote: On Tue, Oct 4, 2011 at 6:07 PM, Jeremiah Dodds jeremiah.do...@gmail.com wrote: On Tue, Oct 4, 2011 at 7:51 PM, Stuart Dallas stu...@3ft9.com wrote: As for the overhead I very much doubt there's much difference between that and the overhead of prepared statements. Probably not. As an aside, I'm really struggling to find a case where it'd be worth base64-encoding the queries like that unless you were both concerned about someone sniffing your queries over the wire and sure that they wouldn't think to base-64 decode them. Not to mention that if your grand idea to prevent eavesdropping is simple transforms, If that's the case, then SSL would be a better solution since it also protects the authentication process. In then end, I still don't see base64 as a viable solution. *nods*. I didn't mention encryption because I figured it was the obvious solution there. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On 5 Oct 2011, at 02:16, Jeremiah Dodds wrote: On Tue, Oct 4, 2011 at 8:10 PM, Stuart Dallas stu...@3ft9.com wrote: Prepared statements incur an additional hit against the DB server to prepare the statement. But only once, right? This could, of course, still be a downside depending the nature of your app. Once per statement per request, yes. Most web apps execute one-off statements during each request, so the ability to reuse a prepared statement is not a helpful feature for that environment. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 6:10 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 02:02, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 5:51 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 01:13, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:49 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:45, Tommy Pham wrote:
On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas stu...@3ft9.com wrote:
On 5 Oct 2011, at 00:04, Mark Kelly wrote:
Hi.
On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote:
http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/
Thanks. I followed this link through and read the full message (having
missed
it the first time round), and while I find the idea of using base64 to
sanitise text interesting I can also forsee a few difficulties:
It would prevent anyone from accessing the database directly and
getting
meaningful results unless the en/decode is in triggers, or maybe
stored
procedures. No more one-off command-line queries.
How would you search an encoded column for matching text?
I'd be interested in any ideas folk have about these issues, or any
others
they can envisage with this proposal.
Base64 encoding will work when the native base64 functions are available
in MySQL which will allow you to base64 encode the data into a statement
like INSERT INTO table SET field = FROM_BASE64(?php echo
base64_encode($data); ?) sorta thing. I'm still not a massive fan of that
idea given that prepared statements are an option, but it would work.
Inserting and updating isn't the problem. I think Mark referring to is
how would that be implemented in this simple type of query:
SELECT * FROM my_table WHERE col_name LIKE '%key word%';
If there's no viable mean to filter the data, that storage method/medium
is rather pointless, IMHO.
Go back and read what I wrote again. Base64 is only being used to
transmit the data to MySQL - it's being stored in the database in its
decoded form.
The question still applies as how would you safeguard that 'key word'
transmission, especially against SQL injection. I suppose one could do it
this way:
SELECT * FROM my_table WHERE col_name LIKE CONCAT('%', FROM_BASE64(?php
echo base64_encode($data); ?), '%')
Is the overhead worth it to warrant that kind of safeguard? That's just a
simple query with a simple search criteria. What about in the case of
subselect and multi-table joins?
That would indeed be logical if base64 was your chosen method of
protection, but I think prepared statements are a far more elegant solution.
As for the overhead I very much doubt there's much difference between that
and the overhead of prepared statements.
IIRC, prepared statements doesn't incur any overhead. Instead, it's
supposed to enhance performance by telling SQL to 'prepare' via
compilation. So if you're comparing performance between the overhead of
base64 vs prepared statement, then the difference would be quite clear,
especially when the table(s) is/are more than a couple hundred thousand rows
and the queri(es) are complex. This is not mention the added complexity
into the application where managing and expanding it would incur real
(developer time) overhead, IMO.
Prepared statements incur an additional hit against the DB server to
prepare the statement.
The cost of using base64 in the manner suggested is minimal, regardless of
the size of the data. The MySQL query analyser is intelligent enough to know
that from_base64('xyz') is a constant expression and will therefore only
evaluate it once.
Yes, as in your example, if you're inserting 1 row. What if:
$hobbies = array('bicycling', 'hiking', 'reading', 'skiing', 'swimming');
* base64 method pseudo code:
loop the $hobbies foreach ($hobbies as $hobby)
INSERT INTO hobbies SET `name` = FROM_BASE64(?php echo
base64_encode($hobby); ?)
end loop
* prepared statement pseudo code
prepare statement INSERT INTO hobbies SET `name` = ?
bind param $hobby
loop the $hobbies for ($i = 0; $i count($hobbies); $i++)
$hobby = $hobbies[i];
execute statement
end loop
There would be a difference in performance since the the expression has to
be reevaluated, including the function FROM_BASE, every time versus one time
evaluation of prepared statement.
As for the added complexity, if you have SQL statements all over your code
then yes it will add a time overhead, but any codebase of a significant size
should be using a centralised API for database access such that changes like
this have a very limited scope.
Isn't that one of the major points of OOP? Still, what about new
developers, having to remember that additional (and most likely unneeded)
complexity, to the project which they would like to build additional
modules/plugins for?
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
Re: [PHP] Re: Secure data management
On Tue, Oct 4, 2011 at 9:25 PM, Tommy Pham tommy...@gmail.com wrote: There would be a difference in performance since the the expression has to be reevaluated, including the function FROM_BASE, every time versus one time evaluation of prepared statement. This is true, but it should be pointed out that for a large majority of web applications the performance hit given by either prepared statements or base64 encoding is going to be miniscule compared to the bottlenecks already present at the db-access and network-latency layers. Sites that approach needing to actively worry about the performance hit from either method are rare, and it's doubtful that the solution used would be to remove the tactic, assuming the reasons for the approach being used are sound and still present. As for the added complexity, if you have SQL statements all over your code then yes it will add a time overhead, but any codebase of a significant size should be using a centralised API for database access such that changes like this have a very limited scope. Isn't that one of the major points of OOP? Still, what about new developers, having to remember that additional (and most likely unneeded) complexity, to the project which they would like to build additional modules/plugins for? The paragraph you're replying to is saying that this shouldn't be a pain if your code is well organized. If your codebase is sane, these details should be transparent to new developers. If they can't be, then new developers get a chance to learn things :P -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
