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

[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

[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: ; "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

[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 and MYSQL databases

[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 Question

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DB] security

[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
> 
>  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

[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:



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 Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DB] security

[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:



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 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)

[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)

[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

[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]

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

[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

[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]