reasonably safe to use?
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 just disallowing java all together.
-Deanna, who was just trying to hack something together to test whether or
not the whole server-side redirect thing would even work.
----- Original Message -----
From: "Dave Watts" <[EMAIL 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 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 be trusted without validation. It doesn't matter whether it
> comes from a form or a URL or a cookie. It is trivially easy for an
attacker
> to send whatever data he likes. Hidden fields within a form don't make any
> difference at all.
>
> > 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?
>
> Encryption and unencryption are nice, I guess, but ideally you might be
able
> to avoid passing sensitive data to the client at all, unless that client
> needs the ability to change the data. You can store this sort of data
within
> persistent server scopes if necessary.
>
> > As to your question about untrustworthy developers vs.
> > untrustworthy users, I'm really not sure.
>
> You should ask!
>
> Dave Watts, CTO, Fig Leaf Software
> http://www.figleaf.com/
> phone: 202-797-5496
> fax: 202-797-5444
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
