structure
- Original Message -
From: Matt Liotta [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 3:57 PM
Subject: Re: The Dangers of Java
I just applied the patch to one of my servers and it didn't see to make
any difference. For those of you that have
Matt wrote:
For those of you that have the patch, I am curious if
there is any difference between the following two snippets of code.
Hm. Wait a sec. No. No, they don't give an error. (Saved to the wrong server
before.)
Neither of them throw errors. Both seem to work. How very interesting.
-d
It's available in ASP.
- Original Message -
From: Claudia Hoag [EMAIL PROTECTED]
Date: Wednesday, February 18, 2004 8:34 am
Subject: Re:The Dangers of Java
I think it would; it's my understanding that using
GetPageContext().forward() is analogous to Server.Transfer in
classic ASP,
Server.Transfer has been available for classic ASP since version 3.0.
Cheers,
Jeff Garza
- Original Message -
From:
To: CF-Talk
Sent: Wednesday, February 18, 2004 8:34 AM
Subject: Re:The Dangers of Java
I think it would; it's my understanding that using
GetPageContext().forward() is
Well considering that 80% of all enterprises use Java for their web
applications I suspect that your server administrators just aren't
aware of the correct security procedures. Certainly that would appear
to be true considering they disabled cfobject, but Java objects can
still be created
Okay, here's an example. I'm trying to test doing a form post to the secure
side, setting some session variables, and doing a redirect back to the
nonsecure side. I wanted to try doing it with the following line of code
(thinking that maybe a serverside redirect would bypass the pop up warning
cfscript
getPageContext().forward(form.redirect);
/cfscript
Here's their concern:
The Java snippet that you have concerns me.While I
understand its purpose, it exposes a potential threat.For
example, if I knew the relative path to your admin pages, I
could call a change password
this can be trivially defeated with
server sandboxes, but I've never played with them, so I don't know.
Cheers,
barneyb
-Original Message-
From: Deanna Schneider [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 11:31 AM
To: CF-Talk
Subject: Re: The Dangers of Java
Okay
Matt Liotta said:
Well considering that 80% of all enterprises use Java for their web
applications I suspect that your server administrators just aren't
aware of the correct security procedures. Certainly that would
appearto be true considering they disabled cfobject, but Java
objects
No, I don't think so. If you know the path to the admin pages, you
would
just enter it! This is only a threat if your admin pages are not
secured.
Not true. Possibly the security exists at request time as opposed to
execute time. In other words, it may be possible to execute a page you
Okay, here's an example. I'm trying to test doing a form post
to the secure side, setting some session variables, and doing
a redirect back to the nonsecure side. I wanted to try doing
it with the following line of code (thinking that maybe a
serverside redirect would bypass the pop up
Ah, so you are saying that if the directory is protected in IIS, but not in
CF, then this method would get around it?
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
Well, actually, there is a potential problem with your code snippet,
although it's not really specific to the use of Java. You're taking input
from a form and simply using it without validating it first. What would
happen if the user specified an invalid value for form.redirect?
Hi Dave,
This
Ah, so you are saying that if the directory is protected in
IIS, but not in CF, then this method would get around it?
I think it would; it's my understanding that using
GetPageContext().forward() is analogous to Server.Transfer in classic ASP,
which doesn't create an additional HTTP request
You mean you have already found a workaround for Maromedia's fix?
I am not aware of this fix. Care you to share some information? I be
happy to see if it is exploitable.
-Matt
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
Indeed
-Matt
On Feb 17, 2004, at 2:56 PM, Raymond Camden wrote:
Ah, so you are saying that if the directory is protected in IIS, but
not in
CF, then this method would get around it?
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
, particularly FB3.
-Original Message-
From: Raymond Camden [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 11:56 AM
To: CF-Talk
Subject: RE: The Dangers of Java
Ah, so you are saying that if the directory is protected in
IIS, but not in
CF, then this method would get
This is just a snippet. The form itself doesn't allow the
user to enter the redirect, it's entered by the developer
in a hidden field, though I suppose if someone wanted to
hack it they easily could.
Yes, this is exactly what I'm talking about. Any data that comes from the
browser cannot
It is run. Before I sent my original email I confirmed it. At least on
CFMX-NON-J2EE.
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
-Original Message-
From: Deanna Schneider [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 1:04 PM
To: CF-Talk
Subject: Re: The Dangers of Java
snip
So, if I encrypted the redirect on the form page and unencrypted it on the
page where I want to do the forward. Then, are there any major
Yeah, sure would, because it all happens in the
J2EE server.It also is probably possible to
request .CFM files that are protected against
access with code in Application.cfm, since I
don't think Application.cfm runs on a .forward().
This is a VERY common means of security in Fusebox
PROTECTED]
Sent: Tuesday, February 17, 2004 2:20 PM
Subject: RE: The Dangers of Java
This is just a snippet. The form itself doesn't allow the
user to enter the redirect, it's entered by the developer
in a hidden field, though I suppose if someone wanted to
hack it they easily could.
Yes
*sigh*
If you are hard coding the page to redirect to, when not then hard code it
on the form processing page instead of on the form itself?That would
remove one security issue altogether - you would now need to modify the
processing page to redirect somewhere else.
Because the idea is to have
On Tue, 2004-02-17 at 12:47, Deanna Schneider wrote:
And, if I'm entirely honest, I think the server admins are worried that
developers will unwittingly open up security holes, so instead of helping to
educate the developers as to what is safe and not safe, prefer to take the
safest route by
Okay, so if I put the redirect in a session variable, now
does it seem reasonably safe to use?
Yes, it does seem that way to me.
And, if I'm entirely honest, I think the server admins
are worried that developers will unwittingly open up
security holes, so instead of helping to educate
Matt Liotta said:
You mean you have already found a workaround for Maromedia's fix?
I am not aware of this fix. Care you to share some information? I be
happy to see if it is exploitable.
http://www.macromedia.com/devnet/security/security_zone/mpsb04-01.html
Jochem
[Todays Threads]
[This
You might point out that you can easily, unwittingly create security holes
with just CF! For example, if you use unfiltered data from a form or a URL
within a CFQUERY tag, that data could contain code which your database
server will execute.
Yes, they're aware of this. But, I think they're a
().forward() to call a fuse,
even though that fuse would be inaccessible on a URL because of the code
above.
Cheers,
barneyb
-Original Message-
From: Cameron Childress [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 12:29 PM
To: CF-Talk
Subject: RE: The Dangers of Java
Yeah
I just applied the patch to one of my servers and it didn't see to make
any difference. For those of you that have the patch, I am curious if
there is any difference between the following two snippets of code.
cfscript
foo = ;
bar = foo.getClass().forName(java.lang.String);
bar =
29 matches
Mail list logo
