php-general Digest 24 Jan 2010 17:05:28 -0000 Issue 6555
Topics (messages 301389 through 301393):
Re: Cookies & sessions
301389 by: clancy_1.cybec.com.au
301390 by: clancy_1.cybec.com.au
301392 by: Michael A. Peters
Users, groups, and permissions
301391 by: clancy_1.cybec.com.au
301393 by: Nathan Rixham
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Sat, 23 Jan 2010 09:32:37 -0500, [email protected] (tedd) wrote:
>At 1:13 PM +1100 1/23/10, [email protected] wrote:
>> but I would be grateful for any suggestions how I
>>could make this procedure more secure.
>
>We have given you advice that you should NOT use Cookies in any
>fashion to secure your site, but you remain steadfast that you know
>better -- so, what else can we say other than good luck.
BUT you have told me to use sessions, and sessions use a Cookie!
If the Cookie I use contains random data, the only difference in security is in
the time
that it remains valid. Neither contains any useful information, but while they
are valid
both will enable you to bypass security.
--- End Message ---
--- Begin Message ---
On Sat, 23 Jan 2010 15:10:11 +0000, [email protected] (Nathan Rixham) wrote:
................................
>
>To answer your specific questions though - what can be done to make this
>process more secure - no matter what approach you take, when working via
>http and needing logged in / secure functionality; you need the client
>to identify themselves with a key of some sort - no matter how you make
>the key it's always going to be passed via http (GET/POST/COOKIE) - if
>some "hacker" passes the same key then your system is going to think
>it's the original user and give them access.
>
>To make it trickier you can store information such as the users IP
>address, user agent string etc in session and compare it on each
>request; if it changes log the user out and destroy the session data -
>however your never going to protect against the most common form of
>"hacking", a nosy co-worker / person in the same house having a nosey
>while the user is at the toilet / making a brew. This is why many sites
>re-request password confirmation for potentially sensitive actions like
>transferring money, changing personal details and so forth (and send
>email confirmations to tell the user what changed - just in case).
>
>It must be pointed out though that non of this is worth even considering
>if you have sensitive ports (like ftp/ssh/mysql) open to the outside
>world as it's these back doors people will use to hack the whole server,
>not just one users personal account on a single site. Also protect
>against SQL injection attacks by sanitizing your data and so forth.
Thank you for your thoughtful suggestions. I totally agree. If someone goes
sniffing, or
the like, they might be able to get somewhat limited access to the domain. On
the other
hand if they can crack the FTP, and get into the master server, they can
download the
whole site.
>Finally, view it as your responsibility to never store anything personal
>or identifying (or in fact anything) on the client side in a cookie -
>one simple key (session_id) in the cookie and everything on the safe
>secure server is the way to go.
I have thought of storing customising information for a particular user in a
cookie, but
it would simply consist of a set of parameter values. As they would be
processed in
exactly the same way as if they had been entered as parameters they would
presumably
represent no more, or less, threat than the parameters which are essential to
the
operation of the site (and which can readily be read, or bookmarked -- or, on
reflection,
experimented with).
--- End Message ---
--- Begin Message ---
[email protected] wrote:
On Sat, 23 Jan 2010 09:32:37 -0500, [email protected] (tedd) wrote:
At 1:13 PM +1100 1/23/10, [email protected] wrote:
but I would be grateful for any suggestions how I
could make this procedure more secure.
We have given you advice that you should NOT use Cookies in any
fashion to secure your site, but you remain steadfast that you know
better -- so, what else can we say other than good luck.
BUT you have told me to use sessions, and sessions use a Cookie!
If the Cookie I use contains random data, the only difference in security is in
the time
that it remains valid. Neither contains any useful information, but while they
are valid
both will enable you to bypass security.
Using only sessions means you have the tried and true php session
handling to manage the cookie, rather than re-inventing the wheel
yourself by using your own random string to do the same thing that a
session cookie already does.
--- End Message ---
--- Begin Message ---
I am using a Quadra Hosting Multi Domain (http://www.quadrahosting.com.au/) to
host five
different domains. As site owner I have FTP access to the root directory, and to
everything underneath it. There is no domain directly attached to the root.
Each domain
has its own directory tree under the root directory, and I have a separate
directory
Engine containing the PHP code for all the sites. Each domain directory has a
series of
data files defining the various pages, optionally some configuration files, and
a very
short program index.php, which sets up a few user variables, and then passes
control to
the main program in Engine (by including it). The Engine processes a set of
parameters,
and from these generates the actual page which is passed to the user. The data
files are
almost entirely simple text files, and I do not use a database.
The permissions are currently as they were set up by the provider. All
directories in the
system have permissions drwxr-xr-x, and all other files rw-r--r-- (when I read
them as
site owner -- I don't know if they are somehow changed when I access the site by
downloading a page from one of the domains). I can load and run any of the
files in Engine
by including them into Index.php, and I can include images anywhere in the
domain in the
current page. I can also download them directly by quoting their full path. I
can also
show pages defined by data files in Engine, but I can neither show nor download
images in
Engine. I haven't tried accessing pages in other domains.
As the permissions for group and others are the same for all directories, and
all files, I
don't understand how I can download images in the current domain, but not in
Engine. Is it
possible to reset the permissions so that different values are seen from
different
domains, and how can I tell which group I am actually in when I access a
particular
domain? Also is it possible to temporarily include a user in group, if they are
not
already there?
Clancy.
(The PHP manual has been down all day, and Google is not particularly helpful
for this
type of thing unless you already know the terminology, so I have largely been
floundering
in the dark. And when you look up 'user permissions' most books immediately
assume
database.)
--- End Message ---
--- Begin Message ---
[email protected] wrote:
> I am using a Quadra Hosting Multi Domain (http://www.quadrahosting.com.au/)
> to host five
> different domains. As site owner I have FTP access to the root directory, and
> to
> everything underneath it. There is no domain directly attached to the root.
> Each domain
> has its own directory tree under the root directory, and I have a separate
> directory
> Engine containing the PHP code for all the sites. Each domain directory has a
> series of
> data files defining the various pages, optionally some configuration files,
> and a very
> short program index.php, which sets up a few user variables, and then passes
> control to
> the main program in Engine (by including it). The Engine processes a set of
> parameters,
> and from these generates the actual page which is passed to the user. The
> data files are
> almost entirely simple text files, and I do not use a database.
>
> The permissions are currently as they were set up by the provider. All
> directories in the
> system have permissions drwxr-xr-x, and all other files rw-r--r-- (when I
> read them as
> site owner -- I don't know if they are somehow changed when I access the site
> by
> downloading a page from one of the domains). I can load and run any of the
> files in Engine
> by including them into Index.php, and I can include images anywhere in the
> domain in the
> current page. I can also download them directly by quoting their full path. I
> can also
> show pages defined by data files in Engine, but I can neither show nor
> download images in
> Engine. I haven't tried accessing pages in other domains.
>
> As the permissions for group and others are the same for all directories, and
> all files, I
> don't understand how I can download images in the current domain, but not in
> Engine. Is it
> possible to reset the permissions so that different values are seen from
> different
> domains, and how can I tell which group I am actually in when I access a
> particular
> domain? Also is it possible to temporarily include a user in group, if they
> are not
> already there?
>
> Clancy.
>
> (The PHP manual has been down all day, and Google is not particularly helpful
> for this
> type of thing unless you already know the terminology, so I have largely been
> floundering
> in the dark. And when you look up 'user permissions' most books immediately
> assume
> database.)
>
Hi Clancy,
If I read what you are saying correctly you have the following directory
tree
/SiteA/ <-- domain files
/SiteB/ <-- domain files
/SiteC/ <-- domain files
/Engine <-- private files
if this is correct then:
www.somesite.com is mapped to /SiteA/
so if you have the file /SiteA/test.jpg you can access it via
www.somesite.com/test.jpg
if I'm still correct.. then the problem is that /Engine/ *is not* mapped
to any domain - thus you can't access it via http.
Any request to www.somesite.com/Engine/test.jpg will map to
/SiteA/Engine/test.jpg and not /Engine/test.jpg as you'd want.
If I'm wrong the you need to explain some more :)
Regards,
Nathan
--- End Message ---
