NYCPHP Meetup

[nycphp-talk] <a href> vs. <form> request

Christopher Hendry chendry at nyc.rr.com
Wed Apr 16 20:39:34 EDT 2003


ok - dunno what I'm talking about, but could you possible append some sort
of hash value to the href - which could only be generated by your script and
not any third party?  Make the key available only to the valid websites in
order for them to generate it - and don't accept anything that does have a
submit.

-> -----Original Message-----
-> From: Jerry Kapron [mailto:nyphp at newageweb.com]
-> Sent: Wednesday, April 16, 2003 8:12 PM
-> To: NYPHP Talk
-> Subject: Re: [nycphp-talk] <a href> vs. <form> request
->
->
-> 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
->
->
->
->
-> --- Unsubscribe at http://nyphp.org/list/ ---
->
->
->





More information about the talk mailing list