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
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
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.
foo = "";
bar = foo.getClass().forName("java.lang.String");
bar = bar.newInstance(
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, sure would, because it all happens in the
> > J2EE
> 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
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]
[T
> 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 educat
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
*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 h
AIL PROTECTED]>
To: "CF-Talk" <[EMAIL 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
> 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
>
-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
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 issues
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]
> 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 canno
sebox
applications, 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
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]
> 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]
> 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
> 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,
T
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]
> 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 u
> 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 y
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
> appear to be true considering they disabled cfobject, but Java
> objects c
#x27;s concerned with. I believe 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
>
> getPageContext().forward(form.redirect);
>
>
> 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 ut
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
abou
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 anywa
27 matches
Mail list logo
