NYCPHP Meetup

[Jerry Kapron]

Chris,

>You can't really do that. When someone clicks a link, their browser sends
an
>HTTP GET request. If someone wanted to write their own form that used a
method
>of "get" and submitted to the same URL, they could reproduce this exact
same
>request. Of course, they could also just manually send their own GET
request,
>though that is less convenient.

I'm aware of all this.

>I'm not sure what sort of security you think is lessened by this fact.

I know this does not make much sense when you don't know what the project
is.  Unfortunately I can not reveal any details at this point. This is a
client's project.  The significant fact is that for a specific reason the
users will want to link to the some scripts by submitting a form instead of
clicking on an <a href> link.  I know there is no difference on the back end
whether the request came from a form or a <a href> link, but it's not really
about the back end. The request needs to come from an <a href> link, period.
I know it sounds weird but trust me there is a very good reason for that.

>If you are wanting to make sure people can only access a particular page,
it is best
>to use sessions or something and just make sure that person has access.
>
>If you are particularly concerned that the user clicked your specific link,
you
>can use something like a shared secret. For example, when you generate the
>link, attach a URL variable to it that you also keep on the server (in the
>session or something). You can then check to ensure that this URL variable
is
>correct when determining whether the user can access the page.

None of these would apply. I forgot to mention that the links will be placed
on third party sites (or rather extranet sites) by other webmasters. In
addition to checking the referer header against a database containing
qualified referer URL's, I also need to make sure that they are not linking
from a form. Again, sounds weird but you need to trust me.

>Maybe that gives you some ideas. I recommend, however, that you don't
concern
>yourself with what happens on the client. This can lead to a false sense of
>security. It is best to consider each HTTP request as a request that can
truly
>be anything. Use your own programming logic to determine the rest.

This usually applies to all my other projects but this one is really
different.


Thank you much for your help .. cheers!

Jerry