templates with getPageContext().forward(), and the pages provide no security
to prevent unauthorized access. This is potentially the case if all the
security stuff is taken care of in "wrapper" files.
Of course, the exploit also requires the attacker to be able to run
arbitrary code on your CF server (actually it's underlying J2EE server).
Depending on how the host is set up, it may be possible for people to do
that without having access to your specific web account, and that may be
what he'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
> To: CF-Talk
> Subject: Re: The Dangers of Java
>
> 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
> about leaving a secure site) (Note: I don't even know if what
> I'm trying to
> do would work and if the session variables would get set before it
> forwarded, etc. but I could easily figure that out if I could test it)
>
> <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
> utility for users and execute the code.
>
> Is this valid? If so, how would you go about preventing that
> from happening?
>
>
> ----- Original Message -----
> From: "Matt Liotta"
>
> > 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 anyway using alternate syntax. What you
> need to find
> > it is exactly what their security concerns are and report
> back to the
> > list. I'm sure we can come up with appropriate responses
> once we know
> > what is the issue.
> >
> > -Matt
> >
> >
> > On Feb 17, 2004, at 1:53 PM, Deanna Schneider wrote:
> >
> > > Hi All,
> > > We're in the process of migrating to CFMX, and the server
> > > administrators
> > > have real reservations about allowing us to do anything
> with Java.
> > > They have
> > > disallowed read access, such that
> getPageContext().forward() won't
> > > even
> > > work. They've disallowed cfinvoke, cfimport, and
> cfobject by default.
> > >
> > > I don't know enough about java to be able to make a
> rational argument
> > > for
> > > allowing us to use those tags and the native classes. Can anyone
> > > point me to
> > > any _readable_ information about the risks?
> > >
> > > Thanks.
> > > -Deanna
> > >
> > >
> > > --
> > > Deanna Schneider
> > > UWEX-Cooperative Extension
> > > Interactive Media Developer
> > >
> >
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
