Right, hence a risk based approach. You know the risks, you can best
determine what steps are needed to protect yourself.
I know I often say things that sound absolute. But security is a
balance of risk vs. costs and we need to make sure we strike the
correct balance.
-dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
"Great spirits have often encountered violent opposition from weak
minds."
--Einstein
On May 18, 2007, at 9:09 AM, [EMAIL PROTECTED] wrote:
Not exactly. Let's say that my initial login process goes against
AD or other LDAP, but the rest of the app is a public FAQ. If the
session is hijacked there would be no way for them to get or change
the login information unless methods were provided within the
application to do so (which you would never do). The worst they
could do is use methods that you expose and deface or delete the
FAQ data.
Shawn Gorrell
Web Development Applications Architect
Federal Reserve Bank - Atlanta
Office (404) 498-8449
"Dean H. Saxe" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/18/2007 08:59 AM
Please respond to
discussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: [ACFUG Discuss] problem with session variables (i think) -
DISREGARD I SOLVED IT
No, because if you login and then switch to plain HTTP, what is to
prevent me from stealing your session token at that point? And
what if I can then change your password? I own your account. =)
From a risk based standpoint, I understand your argument Shawn and
many sites (slashdot, beer advocate, bloglines, etc) do just what
you're suggesting. But it does leave them open to attack.
-dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
"To announce that there must be no criticism of the president, or
that we are to stand by the president right or wrong, is not only
unpatriotic and servile, but is morally treasonable to the American
public."
-- Theodore Roosevelt
On May 18, 2007, at 9:00 AM, [EMAIL PROTECTED] wrote:
But what if the only really important data in the app is the
initial login credential? If the other data besides that is not
sensitive, isn't it sort of a waste?
Shawn Gorrell
Web Development Applications Architect
Federal Reserve Bank - Atlanta
Office (404) 498-8449
"Dean H. Saxe" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/18/2007 08:11 AM
Please respond to
discussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: [ACFUG Discuss] problem with session variables (i think) -
DISREGARD I SOLVED IT
Actually, if you use SSL at all, you need to use if from the
beginning to the end of the session. Otherwise all of the value of
SSL is lost once the user begins transmitting his session tokens
(JSESSIONID) across an insecure link.
-dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
Here in America everything is bought and sold, you can get anything
for little bits of gold.
We'll rape the earth and ruin the air, cut down every tree from
here to there.
-- Donna The Buffalo "America"
On May 18, 2007, at 1:21 AM, Dusty Hale wrote:
I did solve this on my own and apologize for the emails but just in
case you were wondering or if anyone else ever runs into this:
After revamping the entire app with Client Scope instead of Session
Scope and the issue was still there, I knew it had to be something
else other than the variables themselves. This is what was
happening to cause the issue:
1. I set some variables in application.cfm to set the "secure
(https)" and "nonsecure (http)" urls for the application.
2. On my local server these are the same because I don't have SSL
set up. That's why it works fine there.
3. HostMySite.com shared hosting has a "shared SSL URL" which I was
using.
4. when moving in and out of secure and nonsecure URLs the sessions
are not the same of course. Hence the issue.
Solution: until an SSL certificate is acquired to run SSL under the
same domain, I think I need to not move back out of SSL until the
session has ended (user logs out). Looks like I get to keep the
Session Scope for now :-) ...
Sorry to bother everyone's ears/eyes on this.
Dusty
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dusty Hale
Sent: Friday, May 18, 2007 12:20 AM
To: discussion@acfug.org
Subject: FW: [ACFUG Discuss] problem with session variables (i think)
I also added a StuctClear() to my logout code but even with that
somehow the session values are remaining when I run this code in
shared hosting (hostmysite.com).
Again it all works fine on my local server. I've googled this issue
to death this evening with nothing that works :-(
<cflock scope="session" type="exclusive" timeout="5">
<cfset temp = StructClear(session)>
<cfset session.user_accountid = "">
<cfset session.user_name = "">
<cfset session.user_firstname = "">
<cfset session.user_lastname = "">
</cflock>
Shouldn't this block of code set the variables to "empty strings"
on all pages throughout the application (it does on my local
server)? Am I missing something? Cursed? Or just going crazy? Mabey
all of the above!
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dusty Hale
Sent: Thursday, May 17, 2007 10:59 PM
To: discussion@acfug.org
Subject: [ACFUG Discuss] problem with session variables (i think)
I have a strange problem going on with the use of session
variables. If anyone knows of something I may be doing wrong here,
please let me know.
1. I'm diligent about <cflock>ing them.
2. They work fine on my local development server (installed on my
laptop).
3. When I use the code on a shared cf hosting plan (at
hostmysite.com) they get real buggy like pages are not reading the
correct values of the variables. Basically all I'm using them for
is to hold some "login session" information. In my logout code the
variables get set to empty strings and the code on other screens
that checks the session variables for the presence of an accountid
and username set seems to still think the variables have values
other than empty strings (even after the logout code is run).
Here is my logout code:
<cflock scope="session" type="exclusive" timeout="5">
<cfset session.user_accountid = "">
<cfset session.user_name = "">
<cfset session.user_firstname = "">
<cfset session.user_lastname = "">
</cflock>
Here is the code on the other screens that still thinks the session
variables have values other than empty strings (after the logout
code is run):
<!--- set accountid and user level to local variables --->
<cflock scope="session" type="readonly" timeout="5">
<cfset variables.user_accountid = session.user_accountid>
<cfset variables.user_level = session.user_level>
</cflock>
<!--- if no account id user is not logged in --->
<cfif not len(variables.user_accountid)>
<cflocation url="#application.url_secure#login.cfm" addtoken="no">
<cfabort>
</cfif>
1. Am I doing something wrong? I don't think so but let me know if
you see something.
2. Could this be some kind of strange cache issue.
Any thoughts are greatly appreciated.
Dusty
-------------------------------------------------------------
Annual Sponsor - Figleaf Software
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
Annual Sponsor - Figleaf Software
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
Annual Sponsor - Figleaf Software
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
Annual Sponsor - Figleaf Software
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
Annual Sponsor - Figleaf Software
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
