At 10:29 AM 6/15/01 -0400, Shafik Yaghmour wrote:
> Yeah this is kind'a old if you have been developing sites for a
>while, you also need to consider that someone can also do this off the
>site as well. So if they have the ability to link to a site from your
>site they can get people to go to that site and then do the post from that
>site and this defeats this protection. Therefore, although, everyone
disparages
>HTTP_REFERER checking, in this case it will protect the innocent user.
I agree, it's an old problem (well as long as the web has been around :) )
and there are various ways to try to solve it depending on the
circumstances. I did post to vuln-dev regarding this last year - asking for
other people's ideas on how they solve it (Subject: "How to prevent
malicious linking/posting to webapps?").
> For critical areas you could also force the user to enter their
>password or something similar which will also prevent this attack from
>working.
This does work reasonably well, but I'd reserve this for very critical
areas only ("Are you sure you want to buy 10 million shares of Company X").
This is used in at least one local bank. If you use this too often the
users get annoyed, but so far they like it when it's used judiciously.
For less critical but still important things, I've been using confirmation
pages and checksums.
Basically, the cgi parameters are passed to the app. If there's no
confirmation value, a confirmation value is generated using a cryptographic
hash of the active session's random string, the relevant cgi parameters,
and a secret, then a confirmation form is displayed with hidden fields
containing those parameters. If the user clicks yes, the values are
resubmitted along with the new valid confirmation value. If the user clicks
no, the user is returned to the calling page using the decoded stack cgi
parameter (if present) .
If an invalid confirmation value is provided, the app logs the attempt and
the HTTP-Referer, and displays the confirmation form with a warning as well.
Only if the confirmation value is correct will the action take place.
One problem of linking confirmation values to the session is that if the
user times out the forms have to be reloaded, regenerated and some info
might be lost.
For example, if user is typing out a message in a form containing the
confirmation value but times out, if the user clicks submit, the user has
to log in again. If it weren't for the confirmation value being tied to the
session, the user's data could be submitted automatically after a
successful login. I still prefer it being tied to the session tho, because
that reduces further the chance of replay attacks - once the session is
invalid, you can't use that confirmation value anymore, even if it's for
the same action and same objects.
Regards,
Link.
This archive was generated by hypermail 2b30 : Sat Jun 16 2001 - 11:16:45 PDT