Re: [PHP-DB] Security question [was Searchable/Sortable Database Fields with MySQL/PHP]

2005-07-13 Thread Micah Stevens
Assuming they have access to the PHP files, all decoding keys would be 
available there, so while encrypting the database would definitely slow up 
the attacker, it would only do so until they discovered the decoding method. 

Any experienced hacker would find this in no time. If you pre-compile the PHP 
code so that the decoding keys are not as readily available, this would help 
greatly. 

Sounds like your major issue is server security here, and not data security? 
Shouldn't you concentrate on keeping them out of the server in the first 
place? If that's accomplished, and you don't have network ports open to the 
MySQL server, and your scripts use encoding/decoding keys that are defined in 
locations not available to HTTP, you should be in pretty good shape.

Just seems like you're trying to fight the wrong battle here. Although this 
should be considered too. If you're only responsible for this second line of 
defense, then I think this is about all you can do with the available 
technology that you mention. I haven't researched this much though, so 
perhaps someone else on the list can offer better suggestions.

-Micah 

On Wednesday 13 July 2005 2:50 am, Jeffrey wrote:
 This is an issue I've been thinking about for an application we are
 developing.

 Is it worth encrypting data on the database tables when anyone who can
 access the application itself - or better still the server - could
 readily access the encrypted data?  Assuming SSL connections, secure
 server, etc, would you also encrypt on the DB?

 Thanks,

 Jeffrey

 Micah Stevens wrote:
 Oh! Also, there's built in mysql functions for encryption, I forgot about
 that, so you can still search, like this:
 
 insert into table set name_field = AES_ENCRYPT('Some name', 'secret key');
 select * from table where AES_DECRYPT(name_field,'secret key') LIKE
  '%some';
 
 Make sense? You'll want an SSL connection to the database of course, and
 anyone that has any decent access to the server memory would be able to
  get the encryption key, but if you're careful it would work.
 
 -Micah
 
 On Tuesday 12 July 2005 2:53 pm, Micah Stevens wrote:
 Just do all your searching/sorting in PHP.. it would be slower, and if
  your dataset is very large (sounds like it might be the case) it would
  be impossible.. So that might be out of the question..
 
 A bit of system engineering might find a solution too, consider which
 fields you need to search/sort by, and by possibly limiting those
  somewhat to just what is absolutely necessary, you might be able to get
  by not encrypting those columns.
 
 Another idea would be to provide hinting columns, essentially providing
 just enough data in those columns to be able to sort with, but not enough
 to give away the data. i.e. just the first 2 characters of each name.
 
 This would allow you to search and get a smaller dataset from the
  database, something you could decrypt in php, and then search further,
  possibly making it manageable.
 
 Hope that helps,
 -Micah
 
 On Tuesday 12 July 2005 2:36 pm, Matt McNeil wrote:
 Greetings,
 I need to securely store lots of sensitive contact information and
 notes in a (MySQL or other freely available) database that will be
 stored on a database server which I do not have direct access to.
 This database will be accessed by a PHP application that I am
 developing.  However, I also need to be able to search/sort these data
 with the database functions (SELECT, ORDER BY, etc) so simple PASSWORD
 style encryption of specific fields would not work.  (For example, I
 need to encrypt
 contacts' names, but need to be able to sort results by name). (I
 realize I could load the entire table into memory with PHP and
 process/search/sort it there, but
 that's obviously not a very good solution).  Ideally I would like to
 encrypt entire tables.  An encrypted file system is not really an
 option, because the goal is to prevent loss if the database server is
 hacked (in addition, I wouldn't be able to install an encrypted file
 system on the database server).
 
 My sense is that this is a difficult problem.  However, I made the
 mistake of promising this functionality,
 so I'm scrambling to figure out some kind of solution.  Any
 suggestions?
 
 Thanks so much!
 
 Matt

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Security and MYSQL databases

2005-06-16 Thread Paul R. Strong

Here's a few payment processors.
Some of them are located in United States and others in United Kingdom.
Haven't tried all of them personally, but many professionals have 
recommended them.

PayPal is still the best way to go because of its low cost.
VeriSign is probably the most secure of all but it's also one of the most 
expensive.


Datacash has a very usefull test service for testing out your transactions.
You can perform test transactions using so-called magic credit card 
munbers supplied by DataCash, which will accept or decline transactions 
without performing any actual financial transactions. This is fantastic for 
development purposes, because you don't want to use your own credit cards 
for testing.


Hope they are of use

Gateway Services:

United States  URLUnited Kingdom 
URL


CyberCash http://www.cybercash.com/  Arcot 
http://www.arcot.com


First Data   http://www.firstdata.com/ WorldPay 
http://www.worldpay.com/


Cardservicehttp://www.cardservice.com/DataCash 
http://www.datacash.com/

International

VeriSign http://www.verisign.com/   ICVerify 
http://www.icverify.com/

Payflow Pro   products/payflow/pro

CyberCash
- Original Message - 
From: I. Gray [EMAIL PROTECTED]

To: php-db@lists.php.net; Bastien Koert [EMAIL PROTECTED]
Sent: Tuesday, June 14, 2005 9:36 AM
Subject: Re: [PHP-DB] Security and MYSQL databases



Thanks,

I kind of suspected this, but it's good to be told.  I wouldn't want to 
like to think my CC details were held on some database somewhere where it 
can get hacked into.  Apart from paypal are there any other 3rd party 
payment processors that anyone recommends?  I think we're perhaps going a 
little off topic here, so sorry.


Bastien Koert wrote:
You should never [almost never ever] store cc details from your users. 
Integrate a 3rd party payment processor into your site and process the 
payments immediately. It will cut down on fraud and chargebacks by the 
users. Its also more secure since the cc details are not stored on your 
machine. What you get back is a payment confirmation number which you can 
store in your systemto reord that payment was approved...and if you don't 
get one, you know immediately its been disallowed so you can stop the 
process at that point.


The issues against it are:
1. its not completely secure. You don't have direct control of the server 
and therefore can't assure yourself that the system is locked down tight 
and kept updated.

2. Your db may not be secure enough
3. Your code may allow for holes that allow hackers to gain access to the 
data.
4. The liability for your business, should your data become compromised. 
Don't say it can't happen. Ask Playboy.com. Hackers access 8million 
accounts and had all the details.


If you can't use a 3rd party processor, then you still shouldn't store 
the data on the server, but send an encrypted email (using pgp) to 
yourself with the account / order  details for processing. But I strongly 
recommend using a 3rd party processor.


Bastien


From: I. Gray [EMAIL PROTECTED]
To: php-db@lists.php.net
Subject: [PHP-DB] Security and MYSQL databases
Date: Tue, 14 Jun 2005 14:36:50 +0100

Hello.

Simple question. An SSL server and a standard a shared MYSQL server that 
I have with my hosts.  If I am to set up a shopping cart system, is this 
a secure way of handling credit card details.  What is the best way of 
receiving the details? I assume an email is not a good way as these can 
be intercepted. Is MYSQL secure enough in this way?


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DB] Security and MYSQL databases

2005-06-14 Thread Bastien Koert
You should never [almost never ever] store cc details from your users. 
Integrate a 3rd party payment processor into your site and process the 
payments immediately. It will cut down on fraud and chargebacks by the 
users. Its also more secure since the cc details are not stored on your 
machine. What you get back is a payment confirmation number which you can 
store in your systemto reord that payment was approved...and if you don't 
get one, you know immediately its been disallowed so you can stop the 
process at that point.


The issues against it are:
1. its not completely secure. You don't have direct control of the server 
and therefore can't assure yourself that the system is locked down tight and 
kept updated.

2. Your db may not be secure enough
3. Your code may allow for holes that allow hackers to gain access to the 
data.
4. The liability for your business, should your data become compromised. 
Don't say it can't happen. Ask Playboy.com. Hackers access 8million accounts 
and had all the details.


If you can't use a 3rd party processor, then you still shouldn't store the 
data on the server, but send an encrypted email (using pgp) to yourself with 
the account / order  details for processing. But I strongly recommend using 
a 3rd party processor.


Bastien


From: I. Gray [EMAIL PROTECTED]
To: php-db@lists.php.net
Subject: [PHP-DB] Security and MYSQL databases
Date: Tue, 14 Jun 2005 14:36:50 +0100

Hello.

Simple question. An SSL server and a standard a shared MYSQL server that I 
have with my hosts.  If I am to set up a shopping cart system, is this a 
secure way of handling credit card details.  What is the best way of 
receiving the details? I assume an email is not a good way as these can be 
intercepted. Is MYSQL secure enough in this way?


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Security and MYSQL databases

2005-06-14 Thread I. Gray

Thanks,

I kind of suspected this, but it's good to be told.  I wouldn't want to 
like to think my CC details were held on some database somewhere where 
it can get hacked into.  Apart from paypal are there any other 3rd party 
payment processors that anyone recommends?  I think we're perhaps going 
a little off topic here, so sorry.


Bastien Koert wrote:
You should never [almost never ever] store cc details from your users. 
Integrate a 3rd party payment processor into your site and process the 
payments immediately. It will cut down on fraud and chargebacks by the 
users. Its also more secure since the cc details are not stored on your 
machine. What you get back is a payment confirmation number which you 
can store in your systemto reord that payment was approved...and if you 
don't get one, you know immediately its been disallowed so you can stop 
the process at that point.


The issues against it are:
1. its not completely secure. You don't have direct control of the 
server and therefore can't assure yourself that the system is locked 
down tight and kept updated.

2. Your db may not be secure enough
3. Your code may allow for holes that allow hackers to gain access to 
the data.
4. The liability for your business, should your data become compromised. 
Don't say it can't happen. Ask Playboy.com. Hackers access 8million 
accounts and had all the details.


If you can't use a 3rd party processor, then you still shouldn't store 
the data on the server, but send an encrypted email (using pgp) to 
yourself with the account / order  details for processing. But I 
strongly recommend using a 3rd party processor.


Bastien


From: I. Gray [EMAIL PROTECTED]
To: php-db@lists.php.net
Subject: [PHP-DB] Security and MYSQL databases
Date: Tue, 14 Jun 2005 14:36:50 +0100

Hello.

Simple question. An SSL server and a standard a shared MYSQL server 
that I have with my hosts.  If I am to set up a shopping cart system, 
is this a secure way of handling credit card details.  What is the 
best way of receiving the details? I assume an email is not a good way 
as these can be intercepted. Is MYSQL secure enough in this way?


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DB] Security Question

2005-01-17 Thread Peter Lovatt
Hi

The page/form will be requested over a non secure connection. When the form is 
submitted the browser establishes a secure connection to the server and then 
sends the data, so the data is sent securely.

Peter




 -Original Message-
 From: Micah Stevens [mailto:[EMAIL PROTECTED]
 Sent: 17 January 2005 03:47
 To: php-db@lists.php.net
 Subject: Re: [PHP-DB] Security Question
 
 
 But what I'm saying is that if you're submitting a form from an unsecured 
 page, to a script on a secure server, the data will still be encrypted. 
 Anyone know this for sure to be correct? It sure makes sense this way. 
 
 
 On Sunday 16 January 2005 07:27 pm, Peter Lovatt wrote:
  Hi
 
  It is better from a security point of view to have a secure login. The
  secure server encrypts the data between the browser and the 
 server, making
  it impossible to read on its journey from you to the server.
 
  However whether it is a major security  problem is another question. To
  view the traffic somebody must have access to the servers that 
 route your
  request, which isn't easy. They then have to spot your traffic 
 amongst all
  the other web traffic.
 
  If it is the login for your Swiss bank account where you hid the million
  you made without declaring tax then it should be secure - no 
 question. On
  the other hand if it is just to login to see when your books will be
  delivered, with no sensitive financial information then the 
 risk is smaller
  and it is unlikely that anyone is trying too hard to get your 
 login, so an
  insecure login carries less risk.
 
  You could always host the login page on a non secure server but post the
  form to a secure server.
 
  Peter
 
   -Original Message-
   From: Micah Stevens [mailto:[EMAIL PROTECTED]
   Sent: 17 January 2005 02:46
   To: php-db@lists.php.net
   Subject: Re: [PHP-DB] Security Question
  
  
  
   If it submits to a secure server the form data will be 
 encrypted before
   transmission I believe. At least that's my understanding, and
   that seems to
   be how ebay does it for example. Once you log-in, it submits 
 to a secure
   page.
  
   -Micah
  
   On Sunday 16 January 2005 06:38 pm, Chris Payne wrote:
Hi everyone,
   
   
   
I have a security question, I want to see if I am right or
  
   wrong.  I have
  
programmed a system with PHP and MySQL, the main system resides
  
   on a secure
  
server, but the client wants the login page on a NON-Secure 
 server for
marketing purposes.  Am I the only one who thinks this is a
  
   major security
  
concern?
   
   
   
Chris
  
   --
   PHP Database Mailing List (http://www.php.net/)
   To unsubscribe, visit: http://www.php.net/unsub.php
 
 -- 
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php
 

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Security Question

2005-01-16 Thread Micah Stevens

If it submits to a secure server the form data will be encrypted before 
transmission I believe. At least that's my understanding, and that seems to 
be how ebay does it for example. Once you log-in, it submits to a secure 
page. 

-Micah 


On Sunday 16 January 2005 06:38 pm, Chris Payne wrote:
 Hi everyone,



 I have a security question, I want to see if I am right or wrong.  I have
 programmed a system with PHP and MySQL, the main system resides on a secure
 server, but the client wants the login page on a NON-Secure server for
 marketing purposes.  Am I the only one who thinks this is a major security
 concern?



 Chris

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DB] Security Question

2005-01-16 Thread Peter Lovatt
Hi

It is better from a security point of view to have a secure login. The secure 
server encrypts the data between the browser and the server, making it 
impossible to read on its journey from you to the server.

However whether it is a major security  problem is another question. To view 
the traffic somebody must have access to the servers that route your request, 
which isn't easy. They then have to spot your traffic amongst all the other web 
traffic.

If it is the login for your Swiss bank account where you hid the million you 
made without declaring tax then it should be secure - no question. On the other 
hand if it is just to login to see when your books will be delivered, with no 
sensitive financial information then the risk is smaller and it is unlikely 
that anyone is trying too hard to get your login, so an insecure login carries 
less risk. 

You could always host the login page on a non secure server but post the form 
to a secure server.

Peter








 -Original Message-
 From: Micah Stevens [mailto:[EMAIL PROTECTED]
 Sent: 17 January 2005 02:46
 To: php-db@lists.php.net
 Subject: Re: [PHP-DB] Security Question
 
 
 
 If it submits to a secure server the form data will be encrypted before 
 transmission I believe. At least that's my understanding, and 
 that seems to 
 be how ebay does it for example. Once you log-in, it submits to a secure 
 page. 
 
 -Micah 
 
 
 On Sunday 16 January 2005 06:38 pm, Chris Payne wrote:
  Hi everyone,
 
 
 
  I have a security question, I want to see if I am right or 
 wrong.  I have
  programmed a system with PHP and MySQL, the main system resides 
 on a secure
  server, but the client wants the login page on a NON-Secure server for
  marketing purposes.  Am I the only one who thinks this is a 
 major security
  concern?
 
 
 
  Chris
 
 -- 
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php
 

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Security Question

2005-01-16 Thread Micah Stevens
But what I'm saying is that if you're submitting a form from an unsecured 
page, to a script on a secure server, the data will still be encrypted. 
Anyone know this for sure to be correct? It sure makes sense this way. 


On Sunday 16 January 2005 07:27 pm, Peter Lovatt wrote:
 Hi

 It is better from a security point of view to have a secure login. The
 secure server encrypts the data between the browser and the server, making
 it impossible to read on its journey from you to the server.

 However whether it is a major security  problem is another question. To
 view the traffic somebody must have access to the servers that route your
 request, which isn't easy. They then have to spot your traffic amongst all
 the other web traffic.

 If it is the login for your Swiss bank account where you hid the million
 you made without declaring tax then it should be secure - no question. On
 the other hand if it is just to login to see when your books will be
 delivered, with no sensitive financial information then the risk is smaller
 and it is unlikely that anyone is trying too hard to get your login, so an
 insecure login carries less risk.

 You could always host the login page on a non secure server but post the
 form to a secure server.

 Peter

  -Original Message-
  From: Micah Stevens [mailto:[EMAIL PROTECTED]
  Sent: 17 January 2005 02:46
  To: php-db@lists.php.net
  Subject: Re: [PHP-DB] Security Question
 
 
 
  If it submits to a secure server the form data will be encrypted before
  transmission I believe. At least that's my understanding, and
  that seems to
  be how ebay does it for example. Once you log-in, it submits to a secure
  page.
 
  -Micah
 
  On Sunday 16 January 2005 06:38 pm, Chris Payne wrote:
   Hi everyone,
  
  
  
   I have a security question, I want to see if I am right or
 
  wrong.  I have
 
   programmed a system with PHP and MySQL, the main system resides
 
  on a secure
 
   server, but the client wants the login page on a NON-Secure server for
   marketing purposes.  Am I the only one who thinks this is a
 
  major security
 
   concern?
  
  
  
   Chris
 
  --
  PHP Database Mailing List (http://www.php.net/)
  To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Security Question

2004-08-27 Thread John Holmes
From: Dylan Barber [EMAIL PROTECTED]
I am accessing a database on my site from another site - I am
not the only developer on the other site and there is the potential
for someone to access the database for nefarious purposes from
the other site.  Can I somehow protect the password and still have it 
work?
What database? I assume you mean your PHP script is logging into a remote 
database and you're concerned about the password being in the script? Not 
much you can do about it, really. You can log in over SSL (depending upon 
your database), which will protect the password in transit, but it's still 
sitting in the file. If you can't trust users on the server that you're on, 
find a better server. :)

Or I had thought of this but I didn't know if it wuld or should work -
include all my database routines in an include file and do something
like include once http://domain.com/include.php; would that even work?
It will work, but not like you're thinking. You'll get the _result_ of the 
PHP file and not the actual code.

---John Holmes... 

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DB] Security Issues

2004-07-13 Thread John W. Holmes
Jonathan Haddad wrote:
so I've been doing a little thinking about web server security..
#1. Since all files on the web are 644, what is to stop someone on the 
same server from copying your files to their own directory?  
(specifically your database connection info)
#2. if a folder if 777, what's to stop someone from writing to that folder?
Answer to both questions is a combination of SAFE_MODE and open_basedir 
restrictions among other things discussed on the manual pages for those 
functions / features.

If those restrictions are not in place, then nothing is stopping someone 
 on the same server to read/write in your filespace with PHP.

--
---John Holmes...
Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/
php|architect: The Magazine for PHP Professionals  www.phparch.com
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


RE: [PHP-DB] Security Issues

2004-07-13 Thread Ed Lazor
 so I've been doing a little thinking about web server security..
 
 #1. Since all files on the web are 644, what is to stop someone on the
 same server from copying your files to their own directory?
 (specifically your database connection info)
 #2. if a folder if 777, what's to stop someone from writing to that
 folder?

Virtual Servers
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci213304,00.html
People can only see their own directories and files.

PHP Safe Mode
http://us2.php.net/features.safe-mode
Check the section titled Safe Mode in the php.ini file.  It has settings
that help lock things down.

Apache open_basedir
Also detailed in the PHP Safe Mode documentation.

There are a few other things that can be done to limit the scope of access,
but all of it really depends on how the server is setup.  I've seen many
situations where hosting providers set accounts up with basic Virtual
Hosting without doing any sort of lock down.  If you're not careful and
chose one of those providers, then you're definitely open to the sort of
security breach that you've described.

-Ed

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Security Issues

2004-05-10 Thread John W. Holmes
From: Galbreath, Mark A [EMAIL PROTECTED]

 Does anybody know if the security issues outlined in

 http://www.securereality.com.au/archives/studyinscarlet.txt

 are still salient or not?  My boss wants a technical document outlining
the
 security risks of using PHP in an attempt to get it approved for general
use
 by Security.  I just bought Mohammed Kabir's Secure PHP Development
(Wiley
 2003) but would like some background white papers before delving into it.
 To that end, I'm using Google, but would appreciate references to any
recent
 documents covering the subject.

Yes, they are still relevant for the most part. There have been actions
taken to reduce some of them, though, like having register_globals OFF by
default, the move_uploaded_file() function, etc.

I would contend that these security issues are the fault of bad
programming, though, not the language. Some could argue that the langauge
should do more to get rid of these issues by default, though. I can't say
that I'd disagree with that, but I'd still hold the programmers responsible
instead of the language.

Bottom line, if you've actually read that page and implement what it says,
then you'll be fine. You can write completely safe programs without taking
any of the protective measures outlined on the site, though. You just have
to know what you're doing.

---John Holmes...

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DB] Security

2002-10-23 Thread Peter Lovatt
check

http://www.mysql.com/doc/en/Miscellaneous_functions.html

it covers a number of options 

Peter

---
Excellence in internet and open source software
---
Sunmaia
www.sunmaia.net
tel. 0121-242-1473
---  

-Original Message-
From: Doaldo Navai Junior [mailto:doaldo;triunfo-bsb.com.br]
Sent: 22 October 2002 05:46
To: [EMAIL PROTECTED]
Subject: [PHP-DB] Security


I need RSA cryptography (or another assymetric method) to crypt the data in
my db. How can I do it?

Doaldo
[EMAIL PROTECTED]



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DB] security

2002-03-05 Thread jas

how can you find out what the php.ini is looking like?  is there a way to
use php to get that info.  i have used phpinfo() but i cannot see whether or
not file_uploads is disabled
Jas
Paul Burney [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED];
on 3/3/02 7:39 PM, Ric Mañalac at [EMAIL PROTECTED] appended
the following bits to my mbox:

 i personally think that the developer still has
 the control in making his php code secure. but how do you
 think will this news affect php as one of the most popular
 choice for web developers?

Probably doesn't belong so much on the PHP-DB list, since databases not
involved, but since some of you on the list may not be aware

In most cases, PHP security can be controlled by the developer, but *not* in
this case.

Basically, most php security problems stem from someone not properly
checking input and being sloppy when connecting to databases, etc.

This case, however, is an actual problem in the PHP server code, not
anything you would write.  To summarize, if you have file_uploads enabled on
the server, php parses multipart/form-data data that is sent to the
script.

It does this for *any* file, not just the ones that have file uploads in
them.  The bug is in that code and can be used by malicious parties to do
evil things on your server.  It can be used against you even if you only
have one page on your server parsed by PHP and the hacker can find it.

The original report is here:

http://security.e-matters.de/advisories/012002.html

Basically you have three options:

1) Disable file_uploads, if you're not using them, in the php.ini file.
This works for PHP 4.0.3 or greater.

2) Apply the source patch to your source tree and rebuild.  Works for PHP
3.0.18, 4.06, 4.1.0 and 4.1.1.

3) Upgrade to PHP 4.1.2

You should really do this as soon as possible.  I'm sure someone will make a
Code Red type of infestation soon to exploit this bug soon.  Evidently,
there is a crude exploit circulating.

Hope that helps.

Paul

?php
while ($self != asleep) {
$sheep_count++;
}
?




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DB] security

2002-03-05 Thread Shrock, Court

Look for file_uploads in the PHP Core section of output from phpinfo().
A 1 means that it is enabled.  A 0 means that it is disabled.

Also, to address:
  i personally think that the developer still has
  the control in making his php code secure. but how do you
  think will this news affect php as one of the most popular
  choice for web developers?

When you ponder this question, also go to google and search for IIS and
security.  If you think the grass is greener on the other-side, simply
compare the number of deathly exploits--I hope you realize that your grass
is way more green than the paid PR employees would have you believe.  Might
I remind everyone that the patch was released WITH the announcement which
was authored by a PHP developer himself.  When has that ever happened on the
other side?  Usually, it takes several days just for MS to admit there's a
problem.  Personally, the security announcement strengthens my trust in the
PHP developers because they were so open about it and they fixed it
immediately--it isn't hard to apply a patch; Windows versions of PHP don't
suffer from the bug.  No big deal--go on with life!

Court

 -Original Message-
 From: jas [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 04, 2002 8:35 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [PHP-DB] security
 
 
 how can you find out what the php.ini is looking like?  is 
 there a way to
 use php to get that info.  i have used phpinfo() but i cannot 
 see whether or
 not file_uploads is disabled
 Jas
 Paul Burney [EMAIL PROTECTED] wrote in message
 [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
 on 3/3/02 7:39 PM, Ric Mañalac at 
 [EMAIL PROTECTED] appended
 the following bits to my mbox:
 
  i personally think that the developer still has
  the control in making his php code secure. but how do you
  think will this news affect php as one of the most popular
  choice for web developers?
 
 Probably doesn't belong so much on the PHP-DB list, since 
 databases not
 involved, but since some of you on the list may not be aware
 
 In most cases, PHP security can be controlled by the 
 developer, but *not* in
 this case.
 
 Basically, most php security problems stem from someone not properly
 checking input and being sloppy when connecting to databases, etc.
 
 This case, however, is an actual problem in the PHP server code, not
 anything you would write.  To summarize, if you have 
 file_uploads enabled on
 the server, php parses multipart/form-data data that is sent to the
 script.
 
 It does this for *any* file, not just the ones that have file 
 uploads in
 them.  The bug is in that code and can be used by malicious 
 parties to do
 evil things on your server.  It can be used against you even 
 if you only
 have one page on your server parsed by PHP and the hacker can find it.
 
 The original report is here:
 
 http://security.e-matters.de/advisories/012002.html
 
 Basically you have three options:
 
 1) Disable file_uploads, if you're not using them, in the 
 php.ini file.
 This works for PHP 4.0.3 or greater.
 
 2) Apply the source patch to your source tree and rebuild.  
 Works for PHP
 3.0.18, 4.06, 4.1.0 and 4.1.1.
 
 3) Upgrade to PHP 4.1.2
 
 You should really do this as soon as possible.  I'm sure 
 someone will make a
 Code Red type of infestation soon to exploit this bug soon.  
 Evidently,
 there is a crude exploit circulating.
 
 Hope that helps.
 
 Paul
 
 ?php
 while ($self != asleep) {
 $sheep_count++;
 }
 ?
 
 
 
 
 -- 
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php
 

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DB] security

2002-03-05 Thread Paul Burney

on 3/4/02 11:34 PM, jas at [EMAIL PROTECTED] appended the following bits
to my mbox:

 how can you find out what the php.ini is looking like?  is there a way to
 use php to get that info.  i have used phpinfo() but i cannot see whether or
 not file_uploads is disabled

It will only show up in PHP 4.0.3 or greater.   Under the PHP Core section,
look in the Directive list for file_uploads.

The Local Value is the one for the current script.  The Master Value is the
one in the php.ini file.

If you aren't using PHP 4.0.3 or greater, you *cannot* disable file_uploads
and must upgrade to fix the problem.

HTH

Paul

?php
while ($self != asleep) {
$sheep_count++;
}
?




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DB] security

2002-03-03 Thread Paul Burney

on 3/3/02 7:39 PM, Ric Mañalac at [EMAIL PROTECTED] appended
the following bits to my mbox:

 i personally think that the developer still has
 the control in making his php code secure. but how do you
 think will this news affect php as one of the most popular
 choice for web developers?

Probably doesn't belong so much on the PHP-DB list, since databases not
involved, but since some of you on the list may not be aware

In most cases, PHP security can be controlled by the developer, but *not* in
this case.

Basically, most php security problems stem from someone not properly
checking input and being sloppy when connecting to databases, etc.

This case, however, is an actual problem in the PHP server code, not
anything you would write.  To summarize, if you have file_uploads enabled on
the server, php parses multipart/form-data data that is sent to the
script.

It does this for *any* file, not just the ones that have file uploads in
them.  The bug is in that code and can be used by malicious parties to do
evil things on your server.  It can be used against you even if you only
have one page on your server parsed by PHP and the hacker can find it.

The original report is here:

http://security.e-matters.de/advisories/012002.html

Basically you have three options:

1) Disable file_uploads, if you're not using them, in the php.ini file.
This works for PHP 4.0.3 or greater.

2) Apply the source patch to your source tree and rebuild.  Works for PHP
3.0.18, 4.06, 4.1.0 and 4.1.1.

3) Upgrade to PHP 4.1.2

You should really do this as soon as possible.  I'm sure someone will make a
Code Red type of infestation soon to exploit this bug soon.  Evidently,
there is a crude exploit circulating.

Hope that helps.

Paul

?php
while ($self != asleep) {
$sheep_count++;
}
?


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DB] Security concern with web forms (update of MySQL data base)

2002-03-02 Thread Boaz Yahav

1st, you should limit the permissions that you have for the user doing
the update.
This user should not be able to do things like ALTER / DROP / CREATE
etc...

If you don't have a need for the DELETE command you can remove the
permissions for it to, however this does not solve all of your problems
since UPDATE can do as much harm as DELETE.

You should use ' ' around all of your variables (even integers) so that
if anyone tries some funny business with ; it will fail. You should
also do as much data validation as you can. Make sure that you are
actually getting integers where you expect them etc...

For someone to be able to mess your DB, he needs to know your db scheme
so try to keep away from obvious field names and make it harder for that
someone to guess your table / field names.

Sincerely

  berber

Visit http://www.weberdev.com Today!!! 
To see where PHP might take you tomorrow.





-Original Message-
From: Ronald Wiplinger [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 02, 2002 4:00 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DB] Security concern with web forms (update of MySQL data
base)



A php page, which includes an update statement for a MySQL data base:

I am trying to figure out, how I can make sure that an update form on
the 
web cannot include codes, that would update other parts of the database
(or 
worse destroy a database).

bye

Ronald




Ronald Wiplinger (ÃQ¤¯¯Ç), CEO, ELMIT - The Solution Provider
Tel. +886 2 8809-7680, Fax. +886 2 2809-0183, Mobile: +886 915 653-452
Net2Phone:8869550066, ICQ: 111651169
http://www.elmit.comhttp://www.wiplinger.org

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DB] Security concern with web forms (update of MySQL data base)

2002-03-01 Thread Shrock, Court

A quick suggestion would be to build your query normally and then don't run
the query if it has a semicolon that isn't inside quotes.  Also, use single
quotes in the update to make your checks easier:

UPDATE table_name SET field1='value1'

-Original Message-
From: Ronald Wiplinger
To: [EMAIL PROTECTED]
Sent: 3/1/02 6:00 PM
Subject: [PHP-DB] Security concern with web forms (update of MySQL data
base)


A php page, which includes an update statement for a MySQL data base:

I am trying to figure out, how I can make sure that an update form on
the 
web cannot include codes, that would update other parts of the database
(or 
worse destroy a database).

bye

Ronald




Ronald Wiplinger (ÃQ¤¯¯Ç), CEO, ELMIT - The Solution Provider
Tel. +886 2 8809-7680, Fax. +886 2 2809-0183, Mobile: +886 915 653-452
Net2Phone:8869550066, ICQ: 111651169
http://www.elmit.comhttp://www.wiplinger.org

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DB] security in PHP under Apache

2001-05-23 Thread Jonathan Hilgeman

PHP runs via Apache, so it adopts the user that Apache uses, essentially.
You can use a program like sudo to allow them to run certain commands on the
server. 

Jonathan

-Original Message-
From: Simon R Jones [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 23, 2001 10:31 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DB] security in PHP under Apache


hi there
does anyone know how to make PHP run as a different user than the default
one (nobody i believe). I have many users with websites and would like
them to be able to run PHP under their usernames so as to ensure security.
Though I'm not sure this is possible unless I install PHP as a CGI binary
and use something like suExec (I currently have it as an Apache module, and
would like to leave it that way).

best wishes,
simon

 ---
 Studio 24 Ltd   |   tel. 01223 501 892
 PO Box 88   |   fax. 0870 063 1216
 Cambridge   |   mob. 07974 074 547
   CB4 1XH   |   www.studio24.net


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DB] security in PHP under Apache

2001-05-23 Thread Terry Romine

But how do you set it so a webuser would run sudo? That sounds pretty 
dangerous, to me.

I have a similar situation where I want PHP to create a subdirectory and 
set privileges to it based on the login user. I end up having to create 
the directory by hand via SSH and then run the php script.

Terry

On Wednesday, May 23, 2001, at 12:36 PM, Jonathan Hilgeman wrote:

 PHP runs via Apache, so it adopts the user that Apache uses, 
 essentially.
 You can use a program like sudo to allow them to run certain commands 
 on the
 server.

 Jonathan

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DB] security in PHP under Apache

2001-05-23 Thread Zak Greant

Check out suExec on the Apache website. Also, Apache 2 allows each virtual
host to run as a different user - this alleviates some security issues.

--zak

- Original Message -
From: Terry Romine [EMAIL PROTECTED]
To: Jonathan Hilgeman [EMAIL PROTECTED]
Cc: 'Simon R Jones' [EMAIL PROTECTED]; PHP-DB (E-mail)
[EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 1:12 PM
Subject: Re: [PHP-DB] security in PHP under Apache


 But how do you set it so a webuser would run sudo? That sounds pretty
 dangerous, to me.

 I have a similar situation where I want PHP to create a subdirectory and
 set privileges to it based on the login user. I end up having to create
 the directory by hand via SSH and then run the php script.

 Terry

 On Wednesday, May 23, 2001, at 12:36 PM, Jonathan Hilgeman wrote:

  PHP runs via Apache, so it adopts the user that Apache uses,
  essentially.
  You can use a program like sudo to allow them to run certain commands
  on the
  server.
 
  Jonathan

 --
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]