| Author |
PHP/MySQL security
|
|
| Mike Easter 2004-11-20, 3:55 pm |
| I have one set of tables that are read-only. I have a user ID and password
set up that I use to query against these tables, and the user ID has only
read (select) permissions. Now I'm planning on adding a new set of tables,
these tables will need to have users capable of selecting AND inserting
data. My concern is I don't want to open the door for hackers to insert
into my read-only tables. What is the best way to handle this? The path I'm
going down is to set up a new a database to contain the tables that will be
for inserting data. Is that overkill? Will it be creating problems for
myself down the road? Am I making a mountain out of a molehill in terms of
security?
| |
| Michael Vilain 2004-11-20, 3:55 pm |
| In article <Xns95A7531E0343Foikoihotmailcom@216.196.97.136>,
Mike Easter <oikoi@hotmail.com> wrote:
> I have one set of tables that are read-only. I have a user ID and password
> set up that I use to query against these tables, and the user ID has only
> read (select) permissions. Now I'm planning on adding a new set of tables,
> these tables will need to have users capable of selecting AND inserting
> data. My concern is I don't want to open the door for hackers to insert
> into my read-only tables. What is the best way to handle this? The path I'm
> going down is to set up a new a database to contain the tables that will be
> for inserting data. Is that overkill? Will it be creating problems for
> myself down the road? Am I making a mountain out of a molehill in terms of
> security?
Depends. Is this machine shared or dedicated to just you? If it's
shared, how are you preventing other users from reading the files and
seeing your passwords to the database? There aren't a lot of ways to
prevent this. Originally, I did all database access in perl scripts
which I could protect and run as a specific user using CGIwrap. But I
found an easier way in
http://shiflett.org/articles/security-corner-mar2004
Read his other articles as well. They have lots of great information.
As to your level of paranoia--that's good. But I'd be more concerned
about an 'injection attack' where someone inserts stuff into the
database like a Javascript or html code. Be sure to use strip_tags to
remove such stuff before you insert it into a table column.
You don't need to do multiple databases, just a single database and two
users, one with R/O access and one with full access.
Just as a matter of course, I did a similar design on a site--most
functions opened the database using a R/O user while the management
functions or certain specific user functions allowed write/update on
specific tables. I further separated data into two categories and split
a table into a privileged and non-privileged part. Not really needed,
but logically consistant.
Most of this isn't relevant to php but more to database design. There
are lots of books on that from simple table construction to full
discussions of 5th-normal form. Browse you local tech book store for
something that you can relate to and buy it there or on-line.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Mike Easter 2004-11-20, 3:55 pm |
| "Michael Vilain <vilain@spamcop.net>" wrote in
news:vilain-14B057.10310020112004@news.giganews.com:
> Depends. Is this machine shared or dedicated to just you?
The machine is dedicated, so it sounds like I'm better off there. Maybe I'm
just thick, but the reason I was thinking I needed two databases was due to
an imagined risk of hackers intercepting the database passwords from the
php page. Is this possible? Say for example the following is in my page:
$db = mysql_pconnect('mysql.domain.com','inserter','password');
Can the php file be read directly from the server? Can the password be
intercepted somehow from the web server to the database server? Or are
passwords kept in a php page safe?
Thanks much for the strip_tags pointer; I'll add that to my form
validation. And thanks for the pointer. It's a little over my head for my
current level, but looks like there's a lot of really good info in the
site.
| |
| Michael Vilain 2004-11-20, 8:55 pm |
| In article <Xns95A7859FC53C9oikoihotmailcom@216.196.97.136>,
Mike Easter <oikoi@hotmail.com> wrote:
> "Michael Vilain <vilain@spamcop.net>" wrote in
> news:vilain-14B057.10310020112004@news.giganews.com:
>
>
> The machine is dedicated, so it sounds like I'm better off there. Maybe I'm
> just thick, but the reason I was thinking I needed two databases was due to
> an imagined risk of hackers intercepting the database passwords from the
> php page. Is this possible? Say for example the following is in my page:
>
> $db = mysql_pconnect('mysql.domain.com','inserter','password');
>
> Can the php file be read directly from the server? Can the password be
> intercepted somehow from the web server to the database server? Or are
> passwords kept in a php page safe?
>
> Thanks much for the strip_tags pointer; I'll add that to my form
> validation. And thanks for the pointer. It's a little over my head for my
> current level, but looks like there's a lot of really good info in the
> site.
If you restrict access to the database to the localhost only, then you
won't have this problem. There's no network connection and no traffic
to snoop.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
|
| Mike Easter wrote:
> I have one set of tables that are read-only. I have a user ID and password
> set up that I use to query against these tables, and the user ID has only
> read (select) permissions. Now I'm planning on adding a new set of tables,
> these tables will need to have users capable of selecting AND inserting
> data. My concern is I don't want to open the door for hackers to insert
> into my read-only tables. What is the best way to handle this? The path I'm
> going down is to set up a new a database to contain the tables that will be
> for inserting data. Is that overkill? Will it be creating problems for
> myself down the road? Am I making a mountain out of a molehill in terms of
> security?
If the user only has read access on the read only tables they wont be
able to insert data using it. Its a role thing only and I cant see how
it could be worked around by a hacker unless MySQL has major issues.
Just grant the appropriate grants the the appropriate tables and you
will not have any issues.
JAS
| |
| Keith R 2004-11-21, 3:57 pm |
|
<Michael Vilain <vilain@spamcop.net>> wrote in message
news:vilain-671C79.13585120112004@news.giganews.com...
> In article <Xns95A7859FC53C9oikoihotmailcom@216.196.97.136>,
> Mike Easter <oikoi@hotmail.com> wrote:
>
<snip>[color=darkred]
> an imagined risk of hackers intercepting the database passwords from the
Yes it is possible.
Have you considered implementing an SSL or some other asynchronous key-based
system? I'd suggest both from web server to client & on the LANside
webserver to RDMS if the webserver & RDMS are on different machines. Packets
will be in clear between nodes unless you implement something.
Authentication from clients on the wider Internet will be sending their
authentication parameters in clear which can be easily read WiFi nodes
using anything less than WPA are similarly vulnerable. If you want to check
take a look at Ethereal or Packetyser or some other packet analysis tool &
pop it on the machine running the dBase.
IMO SSL between webserver & client & a kerberos-based system on the LANside
is the easiest solution to implement.
Regards,
Keith
| |
| Mike Easter 2004-11-22, 8:56 pm |
| JAS <dubyadubyadubya@gmail.com> wrote in
news:41a04ad7_2@newspeer2.tds.net:
> If the user only has read access on the read only tables they wont be
> able to insert data using it. Its a role thing only and I cant see
> how it could be worked around by a hacker unless MySQL has major
> issues. Just grant the appropriate grants the the appropriate tables
> and you will not have any issues.
>
> JAS
Thanks for your response. I'm very new at all this, but I think I get why
my site's not at risk.
| |
| Mike Easter 2004-11-22, 8:56 pm |
| "Keith R" <keith@nospam> wrote in news:b5Cdnf0vevipMj3cRVnyiw@pipex.net:
> Yes it is possible.
>
> Have you considered implementing an SSL or some other asynchronous
> key-based system? I'd suggest both from web server to client & on
> the LANside webserver to RDMS if the webserver & RDMS are on different
> machines. Packets will be in clear between nodes unless you implement
> something. Authentication from clients on the wider Internet will be
> sending their authentication parameters in clear which can be easily
> read WiFi nodes using anything less than WPA are similarly
> vulnerable. If you want to check take a look at Ethereal or Packetyser
> or some other packet analysis tool & pop it on the machine running the
> dBase.
>
> IMO SSL between webserver & client & a kerberos-based system on the
> LANside is the easiest solution to implement.
>
> Regards,
> Keith
I know you're speaking English, but whatever you're saying is WAY over
my head. Thanks much for taking the time to respond. I'm hoping that
hackers as brilliant as you appear to be won't be interested in my
piddly little site.
| |
| Virgil Green 2004-11-23, 8:55 pm |
|
"Keith R" <keith@nospam> wrote in message
news:b5Cdnf0vevipMj3cRVnyiw@pipex.net...
>
> <Michael Vilain <vilain@spamcop.net>> wrote in message
> news:vilain-671C79.13585120112004@news.giganews.com...
> <snip>
>
> Yes it is possible.
Not as the OP described his situation. The question was whether the userID
and password hardcoded (as I read it) in a script can be intercepted by a
user. This information is never transmitted between client and server in the
OP's situation.
If someone gained access to the raw PHP file rather than having it processed
through the webserver and properly interpreted, then they would gain the
info. However, any access of that sort would be outside the protective scope
of the suggestions you've made below.
- Virgil
> Have you considered implementing an SSL or some other asynchronous
key-based
> system? I'd suggest both from web server to client & on the LANside
> webserver to RDMS if the webserver & RDMS are on different machines.
Packets
> will be in clear between nodes unless you implement something.
> Authentication from clients on the wider Internet will be sending their
> authentication parameters in clear which can be easily read WiFi nodes
> using anything less than WPA are similarly vulnerable. If you want to
check
> take a look at Ethereal or Packetyser or some other packet analysis tool &
> pop it on the machine running the dBase.
>
> IMO SSL between webserver & client & a kerberos-based system on the
LANside
> is the easiest solution to implement.
>
> Regards,
> Keith
>
>
| |
| Keith R 2004-11-24, 3:55 am |
|
<Michael Vilain <vilain@spamcop.net>> wrote in message
news:vilain-671C79.13585120112004@news.giganews.com...
> In article <Xns95A7859FC53C9oikoihotmailcom@216.196.97.136>,
> Mike Easter <oikoi@hotmail.com> wrote:
>
<snip>[color=darkred]
> an imagined risk of hackers intercepting the database passwords from the
Yes it is possible.
Have you considered implementing an SSL or some other asynchronous key-based
system? I'd suggest both from web server to client & on the LANside
webserver to RDMS if the webserver & RDMS are on different machines. Packets
will be in clear between nodes unless you implement something.
Authentication from clients on the wider Internet will be sending their
authentication parameters in clear which can be easily read WiFi nodes
using anything less than WPA are similarly vulnerable. If you want to check
take a look at Ethereal or Packetyser or some other packet analysis tool &
pop it on the machine running the dBase.
IMO SSL between webserver & client & a kerberos-based system on the LANside
is the easiest solution to implement.
Regards,
Keith
| |
|
| Mike Easter wrote:
> I have one set of tables that are read-only. I have a user ID and password
> set up that I use to query against these tables, and the user ID has only
> read (select) permissions. Now I'm planning on adding a new set of tables,
> these tables will need to have users capable of selecting AND inserting
> data. My concern is I don't want to open the door for hackers to insert
> into my read-only tables. What is the best way to handle this? The path I'm
> going down is to set up a new a database to contain the tables that will be
> for inserting data. Is that overkill? Will it be creating problems for
> myself down the road? Am I making a mountain out of a molehill in terms of
> security?
If the user only has read access on the read only tables they wont be
able to insert data using it. Its a role thing only and I cant see how
it could be worked around by a hacker unless MySQL has major issues.
Just grant the appropriate grants the the appropriate tables and you
will not have any issues.
JAS
| |
| Keith R 2004-11-29, 3:59 pm |
|
<Michael Vilain <vilain@spamcop.net>> wrote in message
news:vilain-671C79.13585120112004@news.giganews.com...
> In article <Xns95A7859FC53C9oikoihotmailcom@216.196.97.136>,
> Mike Easter <oikoi@hotmail.com> wrote:
>
<snip>[color=darkred]
> an imagined risk of hackers intercepting the database passwords from the
Yes it is possible.
Have you considered implementing an SSL or some other asynchronous key-based
system? I'd suggest both from web server to client & on the LANside
webserver to RDMS if the webserver & RDMS are on different machines. Packets
will be in clear between nodes unless you implement something.
Authentication from clients on the wider Internet will be sending their
authentication parameters in clear which can be easily read WiFi nodes
using anything less than WPA are similarly vulnerable. If you want to check
take a look at Ethereal or Packetyser or some other packet analysis tool &
pop it on the machine running the dBase.
IMO SSL between webserver & client & a kerberos-based system on the LANside
is the easiest solution to implement.
Regards,
Keith
| |
| Mike Easter 2004-11-29, 3:59 pm |
| JAS <dubyadubyadubya@gmail.com> wrote in
news:41a04ad7_2@newspeer2.tds.net:
> If the user only has read access on the read only tables they wont be
> able to insert data using it. Its a role thing only and I cant see
> how it could be worked around by a hacker unless MySQL has major
> issues. Just grant the appropriate grants the the appropriate tables
> and you will not have any issues.
>
> JAS
Thanks for your response. I'm very new at all this, but I think I get why
my site's not at risk.
| |
| Mike Easter 2004-11-29, 3:59 pm |
| "Michael Vilain <vilain@spamcop.net>" wrote in
news:vilain-671C79.13585120112004@news.giganews.com:
> If you restrict access to the database to the localhost only, then you
> won't have this problem. There's no network connection and no traffic
> to snoop.
Access is restricted to local host for all of my user IDs, so I think I'm
OK. Thanks for taking the time to teach a newbie so much about basic
security!
| |
| Mike Easter 2004-11-29, 3:59 pm |
| "Keith R" <keith@nospam> wrote in news:b5Cdnf0vevipMj3cRVnyiw@pipex.net:
> Yes it is possible.
>
> Have you considered implementing an SSL or some other asynchronous
> key-based system? I'd suggest both from web server to client & on
> the LANside webserver to RDMS if the webserver & RDMS are on different
> machines. Packets will be in clear between nodes unless you implement
> something. Authentication from clients on the wider Internet will be
> sending their authentication parameters in clear which can be easily
> read WiFi nodes using anything less than WPA are similarly
> vulnerable. If you want to check take a look at Ethereal or Packetyser
> or some other packet analysis tool & pop it on the machine running the
> dBase.
>
> IMO SSL between webserver & client & a kerberos-based system on the
> LANside is the easiest solution to implement.
>
> Regards,
> Keith
I know you're speaking English, but whatever you're saying is WAY over
my head. Thanks much for taking the time to respond. I'm hoping that
hackers as brilliant as you appear to be won't be interested in my
piddly little site.
| |
| Virgil Green 2004-11-29, 3:59 pm |
|
"Keith R" <keith@nospam> wrote in message
news:b5Cdnf0vevipMj3cRVnyiw@pipex.net...
>
> <Michael Vilain <vilain@spamcop.net>> wrote in message
> news:vilain-671C79.13585120112004@news.giganews.com...
> <snip>
>
> Yes it is possible.
Not as the OP described his situation. The question was whether the userID
and password hardcoded (as I read it) in a script can be intercepted by a
user. This information is never transmitted between client and server in the
OP's situation.
If someone gained access to the raw PHP file rather than having it processed
through the webserver and properly interpreted, then they would gain the
info. However, any access of that sort would be outside the protective scope
of the suggestions you've made below.
- Virgil
> Have you considered implementing an SSL or some other asynchronous
key-based
> system? I'd suggest both from web server to client & on the LANside
> webserver to RDMS if the webserver & RDMS are on different machines.
Packets
> will be in clear between nodes unless you implement something.
> Authentication from clients on the wider Internet will be sending their
> authentication parameters in clear which can be easily read WiFi nodes
> using anything less than WPA are similarly vulnerable. If you want to
check
> take a look at Ethereal or Packetyser or some other packet analysis tool &
> pop it on the machine running the dBase.
>
> IMO SSL between webserver & client & a kerberos-based system on the
LANside
> is the easiest solution to implement.
>
> Regards,
> Keith
>
>
|
|
|
|