|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Tue May 29 2007 - 15:29:46 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 29 May 2007 20:29:46 -0000 Issue 4818
Topics (messages 255741 through 255769):
Re: a question on session ID and security
255741 by: Stut
255743 by: Zoltán Németh
255744 by: Stut
255750 by: Jared Farrish
255753 by: Stut
255754 by: Jared Farrish
255756 by: Stut
255757 by: Jared Farrish
255758 by: Stut
255760 by: Jared Farrish
255762 by: Jared Farrish
255764 by: Stut
255766 by: Jared Farrish
255768 by: Stut
Re: Web Application Design Literature
255742 by: info.globalissa.com
tinymce, php and mysql problem
255745 by: blueboy
255746 by: Zoltán Németh
255747 by: Darren Whitlen
stack violation. after last line has been executed succesfully
255748 by: Marc Weber
Re: Streaming download to IE doesn't work
255749 by: Jochem Maas
Re: Tipos about which CMS use
255751 by: robert mena
255752 by: Dave Goodchild
Re: Upload a ppt file
255755 by: tedd
ini_set() security question
255759 by: Samuel Vogel
exec dont work for svn
255761 by: Manolet Gmail
255767 by: Peter Lauri
255769 by: Manolet Gmail
Re: Too many records to display in one web page
255763 by: Steve
imap_headerinfo->date
255765 by: Umar
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
Jared Farrish wrote:
>> 1. script for login process is located on a SSL-enabled server, so
>> usernames and passwords are encrypted.
> https:// is an envelope encryption, so POST data, which is a part of the
> packet data, not packet headers, is encrypted. As long as you POST or
> COOKIE
> data that needs encryption, you're fine. GET is not secure.
What utter crud. An SSL connection encrypts the whole HTTP conversation,
including headers and even the URL you are requesting. The response is
also encrypted. It doesn't matter whether you're doing a POST or a GET
request, it's all encrypted.
>> 2. upon successful login, user is relocated to a non-SSL-enabled server
>> which hosts the scripts that contain the authenticated-user-only
>> features.
> If this is what you're doing (header() or a meta-refresh html tag).
>
>> So, while usernames and passwords are protected by SSL, the PHPSESSID is
>> not. In other words, anyone who captures that HTTP GET packet can get
>> the session ID. Is that true?
> There are a few different attack vectors with SESSION data. Needless to
> say,
> never store or authenticate by a PHP SESSION id only; use cookies or
> encrypt
> a page with script and include() the content per page, and force users to
> login every page change.
Cookies are no more secure than the session ID. The general conclusion
from many years of discussion in the web community is that the user
experience is diminished so much by not trusting a session ID that the
security improvements are not justified.
If you're really concerned then your best bet is to reduce the session
lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
store the user agent in the session and expire it if a request tries to
use an existing session with a different user agent. Unfortunately you
cannot rely on the IP address remaining the same throughout a session,
so don't build that into your session validation.
>> Another question is while that session ID is valid only before an
>> unset() and a session_destroy(). So the attacker who has the session ID
>> must fake the session before the real user logout. Is that true?
> Before the session is destroyed and the temp file where it is stored is
> deleted from the harddrive. Do not store sensitive information or use a
> SESSION id to authenticate a user.
The session ID should be used for exactly what it says on the tin -
identifying a session. PHP takes care of this for you by looking at the
sessions it is maintaining for one matching the ID it's given. You can
and should authenticate the continuation of a session based on the
session ID (otherwise there's not much point having the session because
the user will need to login for each page request), but you should not
be storing the session ID anywhere because it's not a permanent value.
To invalidate a session ID you just need to call session_destroy. There
are people who do the following just to be sure that the data in a
session is destroyed, but AFAIK it's not necessary...
foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);
-Stut
attached mail follows:
2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt Ãrta:
> Jared Farrish wrote:
> >> 1. script for login process is located on a SSL-enabled server, so
> >> usernames and passwords are encrypted.
> > https:// is an envelope encryption, so POST data, which is a part of the
> > packet data, not packet headers, is encrypted. As long as you POST or
> > COOKIE
> > data that needs encryption, you're fine. GET is not secure.
>
> What utter crud. An SSL connection encrypts the whole HTTP conversation,
> including headers and even the URL you are requesting. The response is
> also encrypted. It doesn't matter whether you're doing a POST or a GET
> request, it's all encrypted.
>
> >> 2. upon successful login, user is relocated to a non-SSL-enabled server
> >> which hosts the scripts that contain the authenticated-user-only
> >> features.
> > If this is what you're doing (header() or a meta-refresh html tag).
> >
> >> So, while usernames and passwords are protected by SSL, the PHPSESSID is
> >> not. In other words, anyone who captures that HTTP GET packet can get
> >> the session ID. Is that true?
> > There are a few different attack vectors with SESSION data. Needless to
> > say,
> > never store or authenticate by a PHP SESSION id only; use cookies or
> > encrypt
> > a page with script and include() the content per page, and force users to
> > login every page change.
>
> Cookies are no more secure than the session ID. The general conclusion
> from many years of discussion in the web community is that the user
> experience is diminished so much by not trusting a session ID that the
> security improvements are not justified.
>
> If you're really concerned then your best bet is to reduce the session
> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
> store the user agent in the session and expire it if a request tries to
> use an existing session with a different user agent. Unfortunately you
> cannot rely on the IP address remaining the same throughout a session,
> so don't build that into your session validation.
>
> >> Another question is while that session ID is valid only before an
> >> unset() and a session_destroy(). So the attacker who has the session ID
> >> must fake the session before the real user logout. Is that true?
> > Before the session is destroyed and the temp file where it is stored is
> > deleted from the harddrive. Do not store sensitive information or use a
> > SESSION id to authenticate a user.
>
> The session ID should be used for exactly what it says on the tin -
> identifying a session. PHP takes care of this for you by looking at the
> sessions it is maintaining for one matching the ID it's given. You can
> and should authenticate the continuation of a session based on the
> session ID (otherwise there's not much point having the session because
> the user will need to login for each page request), but you should not
> be storing the session ID anywhere because it's not a permanent value.
>
> To invalidate a session ID you just need to call session_destroy. There
> are people who do the following just to be sure that the data in a
> session is destroyed, but AFAIK it's not necessary...
>
> foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);
or just simply
$_SESSION = array();
greets
Zoltán Németh
>
> -Stut
>
attached mail follows:
Zoltán Németh wrote:
> 2007. 05. 29, kedd keltezéssel 10.09-kor Stut ezt Ãrta:
>> Jared Farrish wrote:
>>>> 1. script for login process is located on a SSL-enabled server, so
>>>> usernames and passwords are encrypted.
>>> https:// is an envelope encryption, so POST data, which is a part of the
>>> packet data, not packet headers, is encrypted. As long as you POST or
>>> COOKIE
>>> data that needs encryption, you're fine. GET is not secure.
>> What utter crud. An SSL connection encrypts the whole HTTP conversation,
>> including headers and even the URL you are requesting. The response is
>> also encrypted. It doesn't matter whether you're doing a POST or a GET
>> request, it's all encrypted.
>>
>>>> 2. upon successful login, user is relocated to a non-SSL-enabled server
>>>> which hosts the scripts that contain the authenticated-user-only
>>>> features.
>>> If this is what you're doing (header() or a meta-refresh html tag).
>>>
>>>> So, while usernames and passwords are protected by SSL, the PHPSESSID is
>>>> not. In other words, anyone who captures that HTTP GET packet can get
>>>> the session ID. Is that true?
>>> There are a few different attack vectors with SESSION data. Needless to
>>> say,
>>> never store or authenticate by a PHP SESSION id only; use cookies or
>>> encrypt
>>> a page with script and include() the content per page, and force users to
>>> login every page change.
>> Cookies are no more secure than the session ID. The general conclusion
>> from many years of discussion in the web community is that the user
>> experience is diminished so much by not trusting a session ID that the
>> security improvements are not justified.
>>
>> If you're really concerned then your best bet is to reduce the session
>> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
>> store the user agent in the session and expire it if a request tries to
>> use an existing session with a different user agent. Unfortunately you
>> cannot rely on the IP address remaining the same throughout a session,
>> so don't build that into your session validation.
>>
>>>> Another question is while that session ID is valid only before an
>>>> unset() and a session_destroy(). So the attacker who has the session ID
>>>> must fake the session before the real user logout. Is that true?
>>> Before the session is destroyed and the temp file where it is stored is
>>> deleted from the harddrive. Do not store sensitive information or use a
>>> SESSION id to authenticate a user.
>> The session ID should be used for exactly what it says on the tin -
>> identifying a session. PHP takes care of this for you by looking at the
>> sessions it is maintaining for one matching the ID it's given. You can
>> and should authenticate the continuation of a session based on the
>> session ID (otherwise there's not much point having the session because
>> the user will need to login for each page request), but you should not
>> be storing the session ID anywhere because it's not a permanent value.
>>
>> To invalidate a session ID you just need to call session_destroy. There
>> are people who do the following just to be sure that the data in a
>> session is destroyed, but AFAIK it's not necessary...
>>
>> foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);
>
> or just simply
> $_SESSION = array();
I consider this is very bad practice, but I've just checked the manual
page for session_destory and it recommends the following to completely
destroy a session...
<?php
// Initialize the session.
// If you are using session_name("something"), don't forget it now!
session_start();
// Unset all of the session variables.
$_SESSION = array();
// If it's desired to kill the session, also delete the session cookie.
// Note: This will destroy the session, and not just the session data!
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
// Finally, destroy the session.
session_destroy();
?>
-Stut
attached mail follows:
On 5/29/07, Stut <stuttlegmail.com> wrote:
>
> What utter crud. An SSL connection encrypts the whole HTTP conversation,
> including headers and even the URL you are requesting. The response is
> also encrypted. It doesn't matter whether you're doing a POST or a GET
> request, it's all encrypted.
The URL string is encrypted in HTTPS? Well, I was certainly under a
different impression (same with headers). Since I can't say I know any
better beyond a shadow of a doubt, I'll take your word for it. : )
Cookies are no more secure than the session ID. The general conclusion
> from many years of discussion in the web community is that the user
> experience is diminished so much by not trusting a session ID that the
> security improvements are not justified.
So by storing sensitive information in a SESSION, you're safer? Only if the
session doesn't get read... I don't know, I guess in the security sense, it
should be seen as a part of the "conversation" as you put it, so if you
can't trust SESSION, you probably shouldn't use it at all for secure
applications. I still don't see the sense in storing sensitive information
in a session, at least one that persists; if it is passed to a temp table in
a database and destroyed across calls, I can see that as a better solution,
as long as you have a strong database security configuration.
If you're really concerned then your best bet is to reduce the session
> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
> store the user agent in the session and expire it if a request tries to
> use an existing session with a different user agent. Unfortunately you
> cannot rely on the IP address remaining the same throughout a session,
> so don't build that into your session validation.
Well, if you use COOKIES, you can pass a secondary hash key that can be used
to validate the actual key against a footprint for a visitor (from
$_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like
that's a pretty good way to check against a visitor. I just think it feels
flimsy to validate a user on a SESSION key only.
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
attached mail follows:
Jared Farrish wrote:
> On 5/29/07, Stut <stuttlegmail.com> wrote:
>>
>> What utter crud. An SSL connection encrypts the whole HTTP conversation,
>> including headers and even the URL you are requesting. The response is
>> also encrypted. It doesn't matter whether you're doing a POST or a GET
>> request, it's all encrypted.
>
> The URL string is encrypted in HTTPS? Well, I was certainly under a
> different impression (same with headers). Since I can't say I know any
> better beyond a shadow of a doubt, I'll take your word for it. : )
The only part of an SSL connection that's not encrypted is the
handshaking that goes on to set it up in the first place. Everything
after that, the GET/POST line, headers and the body as well as the
entire response is encrypted.
>> Cookies are no more secure than the session ID. The general conclusion
>> from many years of discussion in the web community is that the user
>> experience is diminished so much by not trusting a session ID that the
>> security improvements are not justified.
>
> So by storing sensitive information in a SESSION, you're safer? Only if the
> session doesn't get read... I don't know, I guess in the security sense, it
> should be seen as a part of the "conversation" as you put it, so if you
> can't trust SESSION, you probably shouldn't use it at all for secure
> applications. I still don't see the sense in storing sensitive information
> in a session, at least one that persists; if it is passed to a temp
> table in
> a database and destroyed across calls, I can see that as a better solution,
> as long as you have a strong database security configuration.
I never said it was safer to store sensitive information in a session -
stop adding words! All I said was that the whole discussion of session
security has been done to death and the conclusion is that you put the
minimum possible on the client (the session ID) and store everything
else on the server. If security is a big enough issue that you worry
about data in the session being read then you need a dedicated server.
If on the other hand you mean credit card information when you say
sensitive data, there is no reason on earth why that should ever be
*stored* anywhere on your server(s), even a "temp" table.
As far as the relative security of cookies against sessions, they are
basically as insecure as each other in most cases, but your cookies are
at the mercy of the users setup which is something I'm just not willing
to trust.
The bottom line is that anything sent to or received from the user is
insecure, and any security that can be added beyond SSL is easily worked
around.
> If you're really concerned then your best bet is to reduce the session
>> lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
>> store the user agent in the session and expire it if a request tries to
>> use an existing session with a different user agent. Unfortunately you
>> cannot rely on the IP address remaining the same throughout a session,
>> so don't build that into your session validation.
>
> Well, if you use COOKIES, you can pass a secondary hash key that can be
> used
> to validate the actual key against a footprint for a visitor (from
> $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like
> that's a pretty good way to check against a visitor. I just think it feels
> flimsy to validate a user on a SESSION key only.
Indeed, you can validate a session by using certain information from the
$_SERVER array, but bear in mind that none of it is necessarily
persistant. I don't know of any examples, but I'm sure somewhere there
is a crappy browser that changes its user agent for every request.
However, of all the options I think the user agent is your best bet if
you really feel you need to worry about it.
In your comment above you seem to be suggesting passing that "secondary
hash key" between requests via a cookie. Why not just store that in the
session? Then it doesn't go outside your app. And as mentioned
previously you have a lot more control over the session data than you do
over cookie data.
Here one final thought... if there was a reliable way to add security to
sessions don't you think that one of the multitude of web development
languages out there would have done it, including PHP?
-Stut
attached mail follows:
On 5/29/07, Stut <stuttlegmail.com> wrote:
>
> The only part of an SSL connection that's not encrypted is the
> handshaking that goes on to set it up in the first place. Everything
> after that, the GET/POST line, headers and the body as well as the
> entire response is encrypted.
One of these days I'm actually going to run some tests so I can see what is
actually happening. I would sound completely ignorant speaking of packets
as if I knew them that well, so I won't!
I never said it was safer to store sensitive information in a session -
> stop adding words! All I said was that the whole discussion of session
> security has been done to death and the conclusion is that you put the
> minimum possible on the client (the session ID) and store everything
> else on the server. If security is a big enough issue that you worry
> about data in the session being read then you need a dedicated server.
>
> If on the other hand you mean credit card information when you say
> sensitive data, there is no reason on earth why that should ever be
> *stored* anywhere on your server(s), even a "temp" table.
I find the best way to advice people on SESSIONS is not to trust them, and
thus not store any kind of sensitive information within them (SSN, credit
card, even phone numbers and whatnot). Since I don't happen to use sessions
or cookies that often (for this reason), maybe my advice is a little biased.
I store user data in cookies...
One thing that makes this all completely irrevelent is that, for someone
with physical access to authenticated browser session (such as an
co-worker), no amount of security will prevent misuse of a session.
As far as the relative security of cookies against sessions, they are
> basically as insecure as each other in most cases, but your cookies are
> at the mercy of the users setup which is something I'm just not willing
> to trust.
True. I should have a fallback to use SESSION if cookies are not available,
but if I'm doing that, why not go whole-hog?
The bottom line is that anything sent to or received from the user is
> insecure, and any security that can be added beyond SSL is easily worked
> around.
And SSL is rendered moot for users who gain browser access to an
authenticated session. Security, I believe, is a matter of pushing
vulnerabilities into a corner. You can't ever make any system completely
secure, as such a system would be virtually useless.
> Well, if you use COOKIES, you can pass a secondary hash key that can be
> > used
> > to validate the actual key against a footprint for a visitor (from
> > $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like
> > that's a pretty good way to check against a visitor. I just think it
> feels
> > flimsy to validate a user on a SESSION key only.
>
> Indeed, you can validate a session by using certain information from the
> $_SERVER array, but bear in mind that none of it is necessarily
> persistant. I don't know of any examples, but I'm sure somewhere there
> is a crappy browser that changes its user agent for every request.
> However, of all the options I think the user agent is your best bet if
> you really feel you need to worry about it.
What happens if someone is behind a proxy? Never tested that, but if someone
were to make a proxy sanitizer that purposefully skewed what it reports in
the headers, that approach could be difficult to troubleshoot.
In your comment above you seem to be suggesting passing that "secondary
> hash key" between requests via a cookie. Why not just store that in the
> session? Then it doesn't go outside your app. And as mentioned
> previously you have a lot more control over the session data than you do
> over cookie data.
The whole point of using a shared hash is to provide notional benefit by
providing a secondary key, that is stored on the browser, which is used to
build the authenticated token, which is then matched to the server token.
This is a type of security hash similar to the one you suggested above
(using $_SERVER variables), only stored in a cookie.
Different approach for different folks... : )
Here one final thought... if there was a reliable way to add security to
> sessions don't you think that one of the multitude of web development
> languages out there would have done it, including PHP?
I certainly don't think you're implying I thought I had given some new,
"better" way of doing sessions that nobody had given before? Curious
statement.
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
attached mail follows:
Jared Farrish wrote:
> On 5/29/07, Stut <stuttlegmail.com> wrote:
>>
>> The only part of an SSL connection that's not encrypted is the
>> handshaking that goes on to set it up in the first place. Everything
>> after that, the GET/POST line, headers and the body as well as the
>> entire response is encrypted.
>
> One of these days I'm actually going to run some tests so I can see what is
> actually happening. I would sound completely ignorant speaking of packets
> as if I knew them that well, so I won't!
Sniff an SSL connection and you'll see it. Most of the traffic is gibberish!
> I never said it was safer to store sensitive information in a session -
>> stop adding words! All I said was that the whole discussion of session
>> security has been done to death and the conclusion is that you put the
>> minimum possible on the client (the session ID) and store everything
>> else on the server. If security is a big enough issue that you worry
>> about data in the session being read then you need a dedicated server.
>>
>> If on the other hand you mean credit card information when you say
>> sensitive data, there is no reason on earth why that should ever be
>> *stored* anywhere on your server(s), even a "temp" table.
>
> I find the best way to advice people on SESSIONS is not to trust them, and
> thus not store any kind of sensitive information within them (SSN, credit
> card, even phone numbers and whatnot). Since I don't happen to use sessions
> or cookies that often (for this reason), maybe my advice is a little
> biased.
> I store user data in cookies...
You do? What sort of data? Nothing sensitive I hope.
> One thing that makes this all completely irrevelent is that, for someone
> with physical access to authenticated browser session (such as an
> co-worker), no amount of security will prevent misuse of a session.
The best you can hope to provide is end-to-end security and security on
the server end. Anything beyond the connection at the client is out of
your control and not worth worrying about.
> As far as the relative security of cookies against sessions, they are
>> basically as insecure as each other in most cases, but your cookies are
>> at the mercy of the users setup which is something I'm just not willing
>> to trust.
>
> True. I should have a fallback to use SESSION if cookies are not available,
> but if I'm doing that, why not go whole-hog?
Fallback to sessions? That makes no sense to me. Aside from the fact
that you are storing application data on the client machine (which could
be in a library for all you know), you are also transferring all that
data for every page request. I really do think you should reconsider
this approach.
>> The bottom line is that anything sent to or received from the user is
>> insecure, and any security that can be added beyond SSL is easily worked
>> around.
>
> And SSL is rendered moot for users who gain browser access to an
> authenticated session. Security, I believe, is a matter of pushing
> vulnerabilities into a corner. You can't ever make any system completely
> secure, as such a system would be virtually useless.
"The only secure computer is one that's never switched on."
Can't remember who said that, but it's completely true. However, the
essence of a secure web application, for me, lies in not sending
anything to the client that the client doesn't need to know about.
>> Well, if you use COOKIES, you can pass a secondary hash key that can be
>> > used
>> > to validate the actual key against a footprint for a visitor (from
>> > $_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like
>> > that's a pretty good way to check against a visitor. I just think it
>> feels
>> > flimsy to validate a user on a SESSION key only.
>>
>> Indeed, you can validate a session by using certain information from the
>> $_SERVER array, but bear in mind that none of it is necessarily
>> persistant. I don't know of any examples, but I'm sure somewhere there
>> is a crappy browser that changes its user agent for every request.
>> However, of all the options I think the user agent is your best bet if
>> you really feel you need to worry about it.
>
> What happens if someone is behind a proxy? Never tested that, but if
> someone
> were to make a proxy sanitizer that purposefully skewed what it reports in
> the headers, that approach could be difficult to troubleshoot.
This is precisely my point. At some point you have to ask yourself
whether it's worth worrying about? If you're dealing with high-value
transactions then you probably need something more akin to a
client-server solution than a web-based solution. That way you can
control the client-side a lot better than you can in a web-based
application.
>> In your comment above you seem to be suggesting passing that "secondary
>> hash key" between requests via a cookie. Why not just store that in the
>> session? Then it doesn't go outside your app. And as mentioned
>> previously you have a lot more control over the session data than you do
>> over cookie data.
>
> The whole point of using a shared hash is to provide notional benefit by
> providing a secondary key, that is stored on the browser, which is used to
> build the authenticated token, which is then matched to the server token.
> This is a type of security hash similar to the one you suggested above
> (using $_SERVER variables), only stored in a cookie.
>
> Different approach for different folks... : )
It's your choice indeed, but if you built such an application for me I
wouldn't accept it because it sends a validation key to the client when
the client has absolutely no reason to see that information. Remember
that anything that gets transferred between the client and the server is
easily modified and cannot be trusted.
>> Here one final thought... if there was a reliable way to add security to
>> sessions don't you think that one of the multitude of web development
>> languages out there would have done it, including PHP?
>
> I certainly don't think you're implying I thought I had given some new,
> "better" way of doing sessions that nobody had given before? Curious
> statement.
No, all I'm saying is that because sessions are a fundamental part of
any web development platform, any ideas for securing them that have been
made over the years (and there have been many) would have been
integrated into the platform-supplied implementation if they were any good.
Don't get me wrong, I don't want to discourage anyone from thinking
about ways to improve it, but personally I consider this issue done to
death.
-Stut
attached mail follows:
On 5/29/07, Stut <stuttlegmail.com> wrote:
>
> Don't get me wrong, I don't want to discourage anyone from thinking
> about ways to improve it, but personally I consider this issue done to
> death.
>
Well, I think the difference is that you send one key (a session identifier)
and hash on user agent report, while I send an authentication key and a
secondary hash key stored in cookies. I'm sending only nominally more
information than you are, so I don't think there's THAT much difference
between what we're saying here. As a lot of users would store session id's
as cookies, and fall back to a query string id, like I said, I don't see
much of a difference in our approaches, except you don't seem to think mine
is acceptable since it's not a "session" id.
If you supply the salt (instead of relying on it being provided, vis a vis,
user agent report), and store that in a cookie on the client, and then that
client can't reproduce an accurate, unchanged version of that cookie, what
change in either the salt and/or the auth id would make this approach
unacceptable (and not break the authentication)? I see major web firms use
cookies all the time, so I'm not sure why there is a bias against cookies,
besides a user that doesn't support cookies in the first place (which is a
real concern, I admit).
I remember a poster on a wall of a tech dept my friend worked for that had a
faux-advert for a "security dongle" for a computer. Essentially, it was a
rubber stopper that was put on a power cable that provided a "100% secure
air gap."
Whether it's been settled or not, I'm not nearly as played out on discussing
it (especially if I'm not getting aspects correct) as I am about browser
bickering, OS wars, and all the other "dispassionate" discourse currently
"enlightening" the internet. At least with security, there's some known
benefit to discussing it!
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
attached mail follows:
Jared Farrish wrote:
> On 5/29/07, Stut <stuttlegmail.com> wrote:
>>
>> Don't get me wrong, I don't want to discourage anyone from thinking
>> about ways to improve it, but personally I consider this issue done to
>> death.
>
> Well, I think the difference is that you send one key (a session
> identifier)
> and hash on user agent report, while I send an authentication key and a
> secondary hash key stored in cookies. I'm sending only nominally more
> information than you are, so I don't think there's THAT much difference
> between what we're saying here. As a lot of users would store session id's
> as cookies, and fall back to a query string id, like I said, I don't see
> much of a difference in our approaches, except you don't seem to think mine
> is acceptable since it's not a "session" id.
That's not what I'm saying. My basic question is why send the "secondary
hash key" to the client when it doesn't need it? Use the authentication
key to identify the users data, then get the "secondary hash key" from
that data. The browser never needs to see the hash, and from a purist
security point of view it could potentially reveal more about your
security methods than you need to.
> If you supply the salt (instead of relying on it being provided, vis a vis,
> user agent report), and store that in a cookie on the client, and then that
> client can't reproduce an accurate, unchanged version of that cookie, what
> change in either the salt and/or the auth id would make this approach
> unacceptable (and not break the authentication)? I see major web firms use
But the point here is that both pieces of information required to
authenticate that client are stored on the client. If someone can get
one of them they can get the other, so it's no more secure than just
accepting the one cookie without bothering to authenticate it in any way.
> cookies all the time, so I'm not sure why there is a bias against cookies,
> besides a user that doesn't support cookies in the first place (which is a
> real concern, I admit).
I have nothing against cookies at all, but I think the line between
cookies and session data is pretty clear.
Cookies should be used to...
a) remember a user between sessions (but not authenticate them)
b) remember a session ID during a session
c) remember user preferences for anonymous users, or where there is no
such concept as users on the site
Sessions should be used for everything else. If you're finding that
you're storing huge amounts of data in cookies, switch to using
sessions. If you find that you're storing so-called "sensitive"
information in cookies, switch to sessions.
> I remember a poster on a wall of a tech dept my friend worked for that
> had a
> faux-advert for a "security dongle" for a computer. Essentially, it was a
> rubber stopper that was put on a power cable that provided a "100% secure
> air gap."
>
> Whether it's been settled or not, I'm not nearly as played out on
> discussing
> it (especially if I'm not getting aspects correct) as I am about browser
> bickering, OS wars, and all the other "dispassionate" discourse currently
> "enlightening" the internet. At least with security, there's some known
> benefit to discussing it!
I'm more than happy to discuss it, but please tell me you got the point
about whatever extra security is possible is likely to have been added
by the majority of web application platforms, including PHP.
I'm all for talking about it and seeing if there is a better way, but I
also know that people far smarter than me have been talking about it for
over 20 years, and what we have is what they've come up with. Ignoring
the other possibilities like client certificates there's not really
anything more you can do without introducing the possibility or even
likelihood that the user experience will be shafted.
-Stut
attached mail follows:
> That's not what I'm saying. My basic question is why send the "secondary
> hash key" to the client when it doesn't need it? Use the authentication
> key to identify the users data, then get the "secondary hash key" from
> that data. The browser never needs to see the hash, and from a purist
> security point of view it could potentially reveal more about your
> security methods than you need to.
The idea is that the secondary hash key replaces the user agent sniff.
> But the point here is that both pieces of information required to
> authenticate that client are stored on the client. If someone can get
> one of them they can get the other, so it's no more secure than just
> accepting the one cookie without bothering to authenticate it in any way.
The token isn't any more secure than tokenizing a user agent and salting it
into a digest. The client still knows what their user agent string says, and
this string can also be guessed (how random can they be?), but at least you
can manipulate a secondary hash key per day/hour, week, whatever.
> I have nothing against cookies at all, but I think the line between
> cookies and session data is pretty clear.
I would just ask where? (No, really.) If it was clear, then a link to a
tutorial on PHP session security is helpful.
> Cookies should be used to...
>
> a) remember a user between sessions (but not authenticate them)
> b) remember a session ID during a session
> c) remember user preferences for anonymous users, or where there is no
> such concept as users on the site
I agree 100% on everything except the logic on authentication. How would you
finish the following:
Sessions should be use to...
a) ?
b) ?
c) ?
> Sessions should be used for everything else. If you're finding that
> you're storing huge amounts of data in cookies, switch to using
> sessions. If you find that you're storing so-called "sensitive"
> information in cookies, switch to sessions.
I don't store anything in cookies that are meant to be useful on the
server-side, save an auth string and a corresponding generated salt. This
will probably change on my next big project, but for the moment, I'm not
much of a fan of SESSIONS that persist. This is based on limited experience
and anecdotal evidence, so opinions may very.
> I'm more than happy to discuss it, but please tell me you got the point
> about whatever extra security is possible is likely to have been added
> by the majority of web application platforms, including PHP.
Of course. We're talking methodology (implementation of what is available),
so I'm not sure why you feel the above is necessary.
> I'm all for talking about it and seeing if there is a better way, but I
> also know that people far smarter than me have been talking about it for
> over 20 years, and what we have is what they've come up with. Ignoring
> the other possibilities like client certificates there's not really
> anything more you can do without introducing the possibility or even
> likelihood that the user experience will be shafted.
If it's an accepted methodology, please describe the entire methodology. If
you think it's obvious, it should be easy, and a link is beneficial.
I do think the stated best practice of SESSIONS, at this point, probably
does need to be described to be further useful as a topic of discussion.
I've been a little unclear in some things, so I get the feeling we've got
the same point of view, with one slight deviation (I think it's slight...).
attached mail follows:
On 5/29/07, Jared Farrish <farrishjgmail.com> wrote:
> I do think the stated best practice of SESSIONS, at this point, probably
> does need to be described to be further useful as a topic of discussion.
> I've been a little unclear in some things, so I get the feeling we've got
> the same point of view, with one slight deviation (I think it's slight...).
>
Just thought I'd post this:
Primer on PHP session security:
http://www.php-mag.net/itr/online_artikel/psecom,id,513,nodeid,114.html
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
attached mail follows:
Jared Farrish wrote:
>> That's not what I'm saying. My basic question is why send the "secondary
>> hash key" to the client when it doesn't need it? Use the authentication
>> key to identify the users data, then get the "secondary hash key" from
>> that data. The browser never needs to see the hash, and from a purist
>> security point of view it could potentially reveal more about your
>> security methods than you need to.
>
> The idea is that the secondary hash key replaces the user agent sniff.
But by doing that you're exposing how your app validates the
authentication key, leaving it open to being transferred to another machine.
>> But the point here is that both pieces of information required to
>> authenticate that client are stored on the client. If someone can get
>> one of them they can get the other, so it's no more secure than just
>> accepting the one cookie without bothering to authenticate it in any way.
>
> The token isn't any more secure than tokenizing a user agent and salting it
> into a digest. The client still knows what their user agent string says,
> and
> this string can also be guessed (how random can they be?), but at least you
> can manipulate a secondary hash key per day/hour, week, whatever.
It's actually less secure than using the user agent because someone
looking at the cookies on the client gets no indication that you're
using the user agent to verify that it's the same client making the request.
>> I have nothing against cookies at all, but I think the line between
>> cookies and session data is pretty clear.
>
> I would just ask where? (No, really.) If it was clear, then a link to a
> tutorial on PHP session security is helpful.
I've asked the internals list why PHP doesn't natively validate the
session ID by using the user agent or other variables because I actually
don't know the reasoning behind it. I'll let you know what they say.
>> Cookies should be used to...
>>
>> a) remember a user between sessions (but not authenticate them)
>> b) remember a session ID during a session
>> c) remember user preferences for anonymous users, or where there is no
>> such concept as users on the site
>
> I agree 100% on everything except the logic on authentication. How would
> you
> finish the following:
>
> Sessions should be use to...
>
> a) ?
> b) ?
> c) ?
a) Store data between requests
b) There is no B
That's the definition of a session. It's a server-side store of data
related to a single user of a web application.
>> Sessions should be used for everything else. If you're finding that
>> you're storing huge amounts of data in cookies, switch to using
>> sessions. If you find that you're storing so-called "sensitive"
>> information in cookies, switch to sessions.
>
> I don't store anything in cookies that are meant to be useful on the
> server-side, save an auth string and a corresponding generated salt. This
> will probably change on my next big project, but for the moment, I'm not
> much of a fan of SESSIONS that persist. This is based on limited experience
> and anecdotal evidence, so opinions may very.
By "sessions that persist" do you mean sessions that live on between
visits by a user? If so then that's a totally different kettle of fish
and IMHO should be avoided at all costs.
>> I'm more than happy to discuss it, but please tell me you got the point
>> about whatever extra security is possible is likely to have been added
>> by the majority of web application platforms, including PHP.
>
> Of course. We're talking methodology (implementation of what is available),
> so I'm not sure why you feel the above is necessary.
Look at the session facilities provided by any web development platform.
They all work the same was as PHP sessions, that is to say storing a
session ID in a cookie or passing it in URLs. I'm not aware of any
system that uses extra validation, and the reason for that is that there
is no guaranteed method.
But you're right, the everybody-else-does-it-that-way argument is never
very strong, but I think it's worth noting. As mentioned earlier, I have
asked the internals list to give a reason why the session extension does
no additional validation.
>> I'm all for talking about it and seeing if there is a better way, but I
>> also know that people far smarter than me have been talking about it for
>> over 20 years, and what we have is what they've come up with. Ignoring
>> the other possibilities like client certificates there's not really
>> anything more you can do without introducing the possibility or even
>> likelihood that the user experience will be shafted.
>
> If it's an accepted methodology, please describe the entire methodology. If
> you think it's obvious, it should be easy, and a link is beneficial.
20 years was an exaggeration given the age of the web, but the need to
persist data related to any given user of a website between requests has
been an issue for well over 10 years.
The first "solution" was cookies. The problem with cookies is that
they're very inefficient and insecure. Inefficient because they get
transferred with every request, and insecure because they get
transferred in the HTTP headers and get stored on the client over which
the web developer has no control.
The natural progression of this was to store the minimum required in a
cookie, and tie that cookie value to a chunk of data on the server. This
is what we now understand as a session.
Client certificates were created to allow a client to prove its identity
to a server in the same way that an SSL certificate can prove the
identity of a server. Unfortunately the management of client
certificates makes them uneconomical for most applications. I know of a
few banks that use them, but not many at all. In fact, the only place
I've used them lately was in a forex trading system where each terminal
cost over $12k which included the hardware and the software license. In
effect the client was as much in our control as the servers were.
Anyhoo, I digress. Sessions are the answer to storing data related to a
users visit to a website / web application between page requests in an
efficient and relatively secure manner. Through the use of SSL you can
add to the security my making it very very hard (but not impossible) to
read the session ID at any point during its transmission. However, you
are still left wide open at the client end, and this I think is where we
differ.
> I do think the stated best practice of SESSIONS, at this point,
> probably does need to be described to be further useful as a topic of
> discussion. I've been a little unclear in some things, so I get the
> feeling we've got the same point of view, with one slight deviation (I
> think it's slight...).
You want to store 2 pieces of information in the browser which, when put
together, will allow a user to continue their visit in an authenticated
state.
I want to put 1 piece of information in the browser, and store the other
in the session. The bit stored in the browser will identify a particular
session on the server from which I will get the second bit.
It doesn't really matter whether that second bit comes from the user
agent, or is randomly generated on login. Storing the validation key in
the same place as the key is like writing your PIN code on the back of
your credit card.
Do you now see why my way is more secure than yours?
-Stut
attached mail follows:
> But by doing that you're exposing how your app validates the
> authentication key, leaving it open to being transferred to another
machine.
True. Although I'm only exposing a part of the auth chain, not *how* that is
constructed to produce the actual authentication token.
It does not, however, tie the session to a specific browser instance on a
remote machine; this is a problem. Of course, if the hash token uses the
reported UA when created... :P
> It's actually less secure than using the user agent because someone
> looking at the cookies on the client gets no indication that you're
> using the user agent to verify that it's the same client making the
request.
But as you said, it's a reasonable thing to guess that it's being used as a
salt or verifier, and may be spoofed using semi-random UA strings if you are
testing for remote session hijacking weaknesses. If my salt changes
according to a time/date/other, or is produced at random (somehow), even if
it is transferred, it should still expire and be invalid by my own control.
> I've asked the internals list why PHP doesn't natively validate the
> session ID by using the user agent or other variables because I actually
> don't know the reasoning behind it. I'll let you know what they say.
I would think it's because browsers are flaky and you can't really rely on
them, and that means you can't build it into the system check.
> That's the definition of a session. It's a server-side store of data
> related to a single user of a web application.
I think this is another reason why the internals don't support
authentication of sessions. Is it up to a session to authenticate itself?
Should it be? What if you wanted to override that behavior?
> By "sessions that persist" do you mean sessions that live on between
> visits by a user? If so then that's a totally different kettle of fish
> and IMHO should be avoided at all costs.
I agree. :D
> Look at the session facilities provided by any web development platform.
> They all work the same was as PHP sessions, that is to say storing a
> session ID in a cookie or passing it in URLs. I'm not aware of any
> system that uses extra validation, and the reason for that is that there
> is no guaranteed method.
Ah, so. You are right...
> But you're right, the everybody-else-does-it-that-way argument is never
> very strong, but I think it's worth noting.
I don't mind "this is standard practice," but EXPLAIN what you mean. What
standard practice?
This is an area that I want my knowledge to overlap others... Bruce
Schneier, in all his glory, makes this point about roll-your-own security
solutions:
Bruce Scheier, http://www.schneier.com/essay-031-ft.txt
> The submission document for the algorithm I submitted with my
> colleagues at Counterpane was the length of a book.
>
> This [make hashing algorithms] is hard to do.
> But even normally rational people tend to be
> blinded by a bright shiny new algorithm. It seems so easy. The
> unfortunate truth is anybody can design an algorithm that he himself
> cannot break. It's actually profound. Anyone out there, from the
> best cryptographer to the random person on the street, can sit down
> with a pencil and paper, design an algorithm and say, "I can't break
> it." And then here's the fallacy—because you can't break it, you
> make the following assumption: "Therefore, it must be secure." So we
> end up with lots of proprietary algorithms. We have a lot of amateur
> cryptanalysts who will design the algorithms, do some work and then
> say, "Look I can't break it, therefore it's secure." My feeling is
> that if the designers haven't proven themselves by breaking several
> published algorithms, why should I look at their designs? The odds
> of them being secure are pretty negligible. Indeed, the top five AES
> candidates—this is top five based on a formal poll of
> cryptographers—were actually designed by teams that have
> cryptanalysts on them. They seem to be the fastest, the most
> elegant, the best performing, the ones that seem to be the most
> secure. Still, nobody trusts them—give us a couple of years to stare
> at them. Eventually, we're going to have a new standard.
>
> There's no reason that I can think of ever to use a new and
> unanalyzed algorithm. There's never any benefit. There might be the
> personal pride of the designer. Other than that, you might as well
> use a known algorithm. So the moral there is "never, ever trust a
> proprietary algorithm."
I have to admit that some of this back-and-forth comes from my desire to get
what I want out of your responses, which I know is probably a little
frustrating. How do people who know little about PHP know what session best
practices are, spelled out? I'm not a noob, but I've still learned a good
deal from your responses that I didn't know before. What about the OP?
> 20 years was an exaggeration given the age of the web, but the need to
> persist data related to any given user of a website between requests has
> been an issue for well over 10 years.
Sure, but referring to how long they've been around is a sore replacement
for referring directly to what they say (the best practices, that is...).
> The first "solution" was cookies. The problem with cookies is that
> they're very inefficient and insecure. Inefficient because they get
> transferred with every request, and insecure because they get
> transferred in the HTTP headers and get stored on the client over which
> the web developer has no control.
>
> The natural progression of this was to store the minimum required in a
> cookie, and tie that cookie value to a chunk of data on the server. This
> is what we now understand as a session.
>
> Client certificates were created to allow a client to prove its identity
> to a server in the same way that an SSL certificate can prove the
> identity of a server. Unfortunately the management of client
> certificates makes them uneconomical for most applications. I know of a
> few banks that use them, but not many at all. In fact, the only place
> I've used them lately was in a forex trading system where each terminal
> cost over $12k which included the hardware and the software license. In
> effect the client was as much in our control as the servers were.
>
> Anyhoo, I digress. Sessions are the answer to storing data related to a
> users visit to a website / web application between page requests in an
> efficient and relatively secure manner. Through the use of SSL you can
> add to the security my making it very very hard (but not impossible) to
> read the session ID at any point during its transmission. However, you
> are still left wide open at the client end, and this I think is where we
> differ.
In all reality, I actually agree with you about sessions in my
heart-of-hearts (maybe a little more now after this thread), as they are the
simplest to implement, and the checks performed on authentication are as
robust as any involving cookies (which can become hopelessly bogged down in
checks, digests, and rechecks), although I posit the SAME thing can be
achieved with instances of cookies. However, simplicity should be the
operative word, and the complexity of the approach I have described is more
than a little troublesome.
> You want to store 2 pieces of information in the browser which, when put
> together, will allow a user to continue their visit in an authenticated
> state.
When put together *with other data* unknown to the browser... This is a
small difference. The auth key is not generated exactly from the hash digest
(sha1($clienthash) !== $authkey).
> I want to put 1 piece of information in the browser, and store the other
> in the session. The bit stored in the browser will identify a particular
> session on the server from which I will get the second bit.
>
> It doesn't really matter whether that second bit comes from the user
> agent, or is randomly generated on login. Storing the validation key in
> the same place as the key is like writing your PIN code on the back of
> your credit card.
Or is it like have the three numbers on the back that are "supposed" to
prove you have it physically in-hand? I think this is more accurately what I
am describing.
> Do you now see why my way is more secure than yours?
Of course not. Mind telling me again?! :D
I appreciate that you posted the historical information on sessions and
cookies. Whether it's accurate to reality, I don't know, but it makes sense,
not lemons, so for now, it's good enough for me!
p.s. Maybe everyone wasn't around when that history occurred...
--
Jared Farrish
Intermediate Web Developer
Denton, Tx
Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$
attached mail follows:
Jared Farrish wrote:
>> I've asked the internals list why PHP doesn't natively validate the
>> session ID by using the user agent or other variables because I actually
>> don't know the reasoning behind it. I'll let you know what they say.
>
> I would think it's because browsers are flaky and you can't really rely on
> them, and that means you can't build it into the system check.
I'm not sure how much closer to the horses mouth I can get...
http://marc.info/?l=php-dev&m=118046750523448&w=2
>> That's the definition of a session. It's a server-side store of data
>> related to a single user of a web application.
>
> I think this is another reason why the internals don't support
> authentication of sessions. Is it up to a session to authenticate itself?
> Should it be? What if you wanted to override that behavior?
Seeing as how the session functionality is provided through an
extension, overriding it is simplicity itself. Plus there is already a
way to implement a session handler in user space.
> I don't mind "this is standard practice," but EXPLAIN what you mean. What
> standard practice?
I'm sorry, I had assumed you knew how PHP sessions work. When a session
is created it is assigned a unique ID. That ID is transported between
the client and the server on each request. The server uses that ID to
identify which session it is, get the data and make it available to the
scripts.
> I have to admit that some of this back-and-forth comes from my desire to
> get
> what I want out of your responses, which I know is probably a little
> frustrating. How do people who know little about PHP know what session best
> practices are, spelled out? I'm not a noob, but I've still learned a good
> deal from your responses that I didn't know before. What about the OP?
If there's anything you want me to go into in more detail please just
ask. I certainly don't think I know it all, but I've been around this
block more than a few times. On the other hand I'm always open to the
possiblity that there's a better way(tm).
> In all reality, I actually agree with you about sessions in my
> heart-of-hearts (maybe a little more now after this thread), as they are
> the
> simplest to implement, and the checks performed on authentication are as
> robust as any involving cookies (which can become hopelessly bogged down in
> checks, digests, and rechecks), although I posit the SAME thing can be
> achieved with instances of cookies. However, simplicity should be the
> operative word, and the complexity of the approach I have described is more
> than a little troublesome.
The same "functionality" can be achieved with cookies, just like the
functionality of a calculator can be achieved with an abacus.
> I appreciate that you posted the historical information on sessions and
> cookies. Whether it's accurate to reality, I don't know, but it makes
> sense,
> not lemons, so for now, it's good enough for me!
It was definitely abridged, but that's the jist of how sessions evolved.
> p.s. Maybe everyone wasn't around when that history occurred...
Don't throw your youth at me, it's unlikely to help.
-Stut
attached mail follows:
Steve,
I have some experience developing web applications. My suggestion is to choose literature/code that uses PHP 4.x IF you plan on distributing the web application to multiple sites. But if instead you plan to have a single site web application, then use the literature/code for the latest and greatest PHP 5.x version.
BTW you have a spartan website ;)
Sincerely,
Rob
Steve wrote:
Date: Mon, 28 May 2007 18:21:01 -0400
From: Steve Finkelstein <sfstevefink.net>
To: php-generallists.php.net
Subject: Web Application Design Literature
Hello -
I'm looking for recommendations on literature which will give me ideas
on best practices for design and implementation of web applications,
with if possible, PHP as its core reference language.
Syntax has never been the challenge for me, like for most, it's always
been the most practical and intelligent way to break up an application
and focus on how to putting it all together for reusability and
maintaining the application.
Anyhow, suggestions are appreciated.
Cheers!
- sf
attached mail follows:
Hi,
I am using tinymce to save news articles with very basic html styling in a
database. This works well upto a point but when I get over a certain number
of characters and then the 'you have an error in your SQL syntax' error. I
am saving in as a LONGBLOB so it should not be a data type mismatch. Any
ideas?
R.
attached mail follows:
2007. 05. 29, kedd keltezéssel 10.29-kor blueboy ezt Ãrta:
> Hi,
>
> I am using tinymce to save news articles with very basic html styling in a
> database. This works well upto a point but when I get over a certain number
> of characters and then the 'you have an error in your SQL syntax' error. I
> am saving in as a LONGBLOB so it should not be a data type mismatch. Any
> ideas?
I'm almost sure this is an escaping issue. Do you use
mysql_real_escape_string() on the stuff you store in the db?
greets
Zoltán Németh
>
> R.
>
attached mail follows:
Zoltán Németh wrote:
> 2007. 05. 29, kedd keltezéssel 10.29-kor blueboy ezt Ãrta:
>> Hi,
>>
>> I am using tinymce to save news articles with very basic html styling in a
>> database. This works well upto a point but when I get over a certain number
>> of characters and then the 'you have an error in your SQL syntax' error. I
>> am saving in as a LONGBLOB so it should not be a data type mismatch. Any
>> ideas?
>
> I'm almost sure this is an escaping issue. Do you use
> mysql_real_escape_string() on the stuff you store in the db?
>
> greets
> Zoltán Németh
>
>> R.
>>
If the mysql_real_escape_string doesn't solve it (which I think it most
likely will), echo out the SQL query its sending and post it here so we
can take a look.
Darren
attached mail follows:
Hello. I've confirmed this problem on my gentoo linux box and using Xampp on windows..
============= apache log =============================================
[Mon May 28 20:38:47 2007] [notice] child pid 16577 exit signal Aborted (6)
*** glibc detected *** /usr/sbin/apache2: free(): invalid next size (fast): 0x082b4d28 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7b2b980]
/lib/libc.so.6(__libc_free+0x89)[0xb7b2cfe9]
/usr/lib/apache2/modules/libphp5.so(shutdown_memory_manager+0x48)[0xb77a0ef8]
/usr/lib/apache2/modules/libphp5.so(php_request_shutdown+0x478)[0xb7776ab8]
/usr/lib/apache2/modules/libphp5.so[0xb7839a18]
/usr/sbin/apache2(ap_invoke_handler+0x182)[0x806b992]
/usr/sbin/apache2(ap_process_request+0x15e)[0x806779e]
/usr/sbin/apache2(apr_vformatter+0xab0)[0x80611f8]
/usr/sbin/apache2(ap_process_connection+0x99)[0x80755b9]
/usr/sbin/apache2[0x8068bc1]
/usr/sbin/apache2[0x8068f56]
/usr/sbin/apache2(ap_mpm_run+0x67e)[0x806964e]
/usr/sbin/apache2(main+0x7df)[0x80701af]
/lib/libc.so.6(__libc_start_main+0xd8)[0xb7add838]
/usr/sbin/apache2(apr_bucket_mmap_make+0x69)[0x8060aa1]
======= Memory map: ========
08048000-080a0000 r-xp 00000000 03:07 1310985 /usr/sbin/apache2
080a0000-080a3000 rw-p 00058000 03:07 1310985 /usr/sbin/apache2
080a3000-08349000 rw-p 080a3000 00:00 0 [heap]
b6d00000-b6d21000 rw-p b6d00000 00:00 0
============= =======================================================
My code snippets
1) lib_marc\trunk\pages\Page.php|12 col 14|
protected $pageContentObjects = array();
2) lib_marc\trunk\pages\Page.php|19 col 13|
$this->pageContentObjects[] = $pageContent;
[ 3) lib_marc\trunk\pages\Page.php|55 col 73|
$p = A::merge_ignore_null_array( U::collect('urlParameters', $this->pageContentObjects) ); ]
4) lib_marc\trunk\pages\XHTMLPage.php|21 col 21|
foreach( $this->pageContentObjects as $pc){
1) this is the declaration
2) another object is added. when commenting this line out there is no problem at all.
[3) doesn't matter]
4) This is foreach loop is causing the trouble even if the loop has an empty body ( foreach (...) {} )
But I can run vardump on it and it shows the item having been added
by 2)
So how can this foreach loop make PHP causing a stack violation?
Any ideas?
You can get the full source code here:
wget http://mawercer.de/marcweber/da.zip
(I'll remove the link again in some days)
I'm using PDO and mysql. The database configuration options can be found in config.php
Everything should be done automatically. (It does create a class location cache
to autoload them and it creates a file containing database metainformation to
execute type safe data queries.(MPDO.php) If you like it keep and use it and drop me a mail telling so ;)
Main entry point is index.php of course.
You need to click on link "Kunden" or use http://localhost/<...>/index.php?page=Kunden
to get this error.
I did use PHP 5.2.2 and mod_php (apache) I didn't try cgi.
Marc
attached mail follows:
Daniel Kasak wrote:
> Hi all.
....
>
> Who knows WTF is wrong and how I can work around it?
without getting into the holywar of download headers,
here is one mans's take/solution:
http://richardlynch.blogspot.com/2006_06_01_archive.html
it should contain enough to help you out.
PS. you might recognize the name from the list
PPS. if you have STFA you would have have found this already, this download
problem comes up regularly.
>
> --
> Daniel Kasak
> IT Developer
> NUS Consulting Group
> Level 5, 77 Pacific Highway
> North Sydney, NSW, Australia 2060
> T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
> email: dkasaknusconsulting.com.au
> website: http://www.nusconsulting.com.au
>
attached mail follows:
Hi,
Thanks for the reply. I already use wordpress for my blog but not as a CMS.
I could not find, for instance, the hability to create users with some sort
of priviledge regarding reading/writing particular documents or areas.
Can you send me more info about it?
On 5/17/07, itoctopus <newsgroupitoctopus.com> wrote:
>
> I've said it before and I'll say it again: Wordpress.
>
> Joomla/Mambo are also a good choice.
>
> --
> itoctopus - http://www.itoctopus.com
> ""robert mena"" <robert.menagmail.com> wrote in message
> news:528f47680705171617j3d4f2141gab6dec8762f46d38mail.gmail.com...
> > Hi there,
> >
> > I'd like to replace my 'intranet' site with a CMS system to speed up
> > the edit process. Some of my requirements are :
> >
> > - written in PHP :)
> > - mysql based
> > - documented/'well structured' - to allow development of customizations
> > - ability to define which pages or sections are public and which are
> > private (and in this case which users can access)
> > - use AJAX (not mandatory) but since some access to the page will come
> > from dial-up to reduce the need to transfer entire html just to update
> > a search or list contents..
> >
> > thanks
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
You could also try Drupal. Drupal 5 comes bundled with jQuery. Drupal is
powerful and flexible and the community is large and supportive.
attached mail follows:
At 11:07 PM +0200 5/28/07, Tijnema wrote:
>On 5/28/07, tedd <teddsperling.com> wrote:
>>Hi Gang:
>>
>>I can upload a text file and an image file via a html form, but I am
>>having problems uploading a PowerPoint file. Apparently, that's a
>>different critter.
>>
Duh!
Thanks for the hints -- it was stupid mistake on my part that.
Sometimes you can get too carried away with trying to make things
secure.
It works fine now that I let it work.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
I would be very interested in knowing which options, that are accessible
with PHP_INI_ALL or PHP_INI_PERDIR, could be risky to allow on a shared
hosting server.
I would like to allow the users to ini_set(), while disabling the risky
options with php_admin_flag/value!
Stuff like 'memory_limit' and so on come to my mind!
Does anybody have more infos on this?
Regards,
Samy
attached mail follows:
2007/5/28, Greg Donald <gdonaldgmail.com>:
> On 5/28/07, Manolet Gmail <manoletgmail.com> wrote:
> > but this doesnt work:
> >
> > exec("svn update",$out);
> > foreach($out as $line)echo"<br/>$line\n";
> >
> > dont print anything... dont update the files
>
> Is it possible you need to provide some type of authentication? `svn
> update` may be asking for input your exec call isn't providing.
well, i have error reporting (E ALL) and dont give me any error, also
i try with
svn update --non-interactive --username user --password pass
and again... nothing appears. Also if the svn update ask for a
password why php dont show it?, or why i dont receive a maximum
ececution time of script error?.
the script run instantly btw,..
>
>
> --
> Greg Donald
> http://destiney.com/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
Hi,
In many apps the messages comes as STDERR, so try:
exec("svn update 2>&1", $out);
Best regards,
Peter Lauri
www.dwsasia.com - company web site
www.lauri.se - personal web site
www.carbonfree.org.uk - become Carbon Free
> -----Original Message-----
> From: Manolet Gmail [mailto:manoletgmail.com]
> Sent: Tuesday, May 29, 2007 5:45 PM
> To: PHP List
> Subject: [PHP] exec dont work for svn
>
> 2007/5/28, Greg Donald <gdonaldgmail.com>:
> > On 5/28/07, Manolet Gmail <manoletgmail.com> wrote:
> > > but this doesnt work:
> > >
> > > exec("svn update",$out);
> > > foreach($out as $line)echo"<br/>$line\n";
> > >
> > > dont print anything... dont update the files
> >
> > Is it possible you need to provide some type of authentication? `svn
> > update` may be asking for input your exec call isn't providing.
>
> well, i have error reporting (E ALL) and dont give me any error, also
> i try with
>
> svn update --non-interactive --username user --password pass
>
> and again... nothing appears. Also if the svn update ask for a
> password why php dont show it?, or why i dont receive a maximum
> ececution time of script error?.
>
> the script run instantly btw,..
>
> >
> >
> > --
> > Greg Donald
> > http://destiney.com/
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
Hi, thanks petter, now im getting this error...
svn: Can't check path '/root/.svn': Permission denied
using this:
$cmd = "svn up";
$cmd .= " --username $user --password $pass --non-interactive --revision $rev";
$cmd .= " --no-auth-cache --config-dir ~/.svn/ 2>&1";
i try with --config-dir /tmp/ with $_SERVER['document_root'] but
always return me the same error, any idea?
2007/5/29, Peter Lauri <listsdwsasia.com>:
> Hi,
>
> In many apps the messages comes as STDERR, so try:
>
> exec("svn update 2>&1", $out);
>
> Best regards,
> Peter Lauri
>
> www.dwsasia.com - company web site
> www.lauri.se - personal web site
> www.carbonfree.org.uk - become Carbon Free
>
> > -----Original Message-----
> > From: Manolet Gmail [mailto:manoletgmail.com]
> > Sent: Tuesday, May 29, 2007 5:45 PM
> > To: PHP List
> > Subject: [PHP] exec dont work for svn
> >
> > 2007/5/28, Greg Donald <gdonaldgmail.com>:
> > > On 5/28/07, Manolet Gmail <manoletgmail.com> wrote:
> > > > but this doesnt work:
> > > >
> > > > exec("svn update",$out);
> > > > foreach($out as $line)echo"<br/>$line\n";
> > > >
> > > > dont print anything... dont update the files
> > >
> > > Is it possible you need to provide some type of authentication? `svn
> > > update` may be asking for input your exec call isn't providing.
> >
> > well, i have error reporting (E ALL) and dont give me any error, also
> > i try with
> >
> > svn update --non-interactive --username user --password pass
> >
> > and again... nothing appears. Also if the svn update ask for a
> > password why php dont show it?, or why i dont receive a maximum
> > ececution time of script error?.
> >
> > the script run instantly btw,..
> >
> > >
> > >
> > > --
> > > Greg Donald
> > > http://destiney.com/
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
The way I handle it:
Step 1-
Add SELECT SQL_CALC_FOUND_ROWS to the front of your initial query and add
the pagination limit to the end (LIMIT 200, 400 or whatever range you want
to display.)
Step 2-
Do a 2nd query: SELECT FOUND_ROWS() immediately after.
What does this do?
It will return your record set within the limit range specified. However
SQL_CALC_FOUND_ROWS also allows you to calculate how many total rows you
would return if you had no limit. By running SELECT FOUND_ROWS() it will
give you the total number of rows in the query. So for instance in the
pseudo query above, mysql_num_rows would only return 200 on the query but
SELECT FOUND_ROWS() might return 2000 if that's how many rows the query
would return.
Now you can use math to determine how many total pages you will have, what
page you are on, etc so you can tweak the pagination to whatever suits your
needs.
""Eduardo Vizcarra"" <evizcarraiteso.mx> wrote in message
news:26.38.49291.220C8564pb1.pair.com...
> Hi All
>
> I am developing a web site that interacts with a MySQL database. When I
> run a query and display the records in a web page, this can become a
> problem because there might be too many records to be displayed in one
> single web page so I am trying to divide the total number of records and
> display them in multiple pages. Let's say, if the query returns 100
> records then I would like to display the first 10 records and then put a
> navigation bar where I can go to the next 10 or return to the previous 10
> records
>
> Is this done at a SQL or PHP level ? any experience on doing this ?
>
> Thanks a bunch
> Eduardo
attached mail follows:
Dear Members!
When I try to get email date through imap_headerinfo the output like this
Wed, 30 May 2007 01:14:03 +0900
Tue, 29 May 2007 22:31:43 +0500
But i want to change it e.g on current date it should be only time 01:14
PM
and on previous day its should be (May 29) how i can do it plz help.
Regards,
Umar Draz
--
View this message in context: http://www.nabble.com/%40imap_headerinfo-%3Edate-tf3835635.html#a10859574
Sent from the PHP - General mailing list archive at Nabble.com.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]