Re: How to prevent malicious linking/posting to webapps?

[Lincoln Yeoh <lyeoh () POP JARING MY>]

Sorry, perhaps it was unclear what attack I'm trying to prevent.

I'm trying to prevent malicious linking to my webapps.

For example say one of my users reads an html enabled message on my webapp
(or on a 3rd party site - yahoo/etc, whilst still logged in to my app).

Say one of the links in the message leads to my webapp specifying
parameters which could do malicious/mischevious stuff.

If the user visits that link, bad things happen, and it's all using the
very authenticated session the user was logged in as.

The links could be a normal clickable link, an img src link, a post form,
or javascript or whatever the attacker manages to get working.

Of course since my apps are only used by internal users they're unlikely to
be attacked for now, but it would be good to know of the possible attacks
and defenses.

The way I proposed was to make it hard for the attacker to create a link
that could actually do stuff.

Have a nice day :),

Link.

At 01:10 PM 13-09-2000 -0400, Brvenik, Jason wrote:
> [snip]
>
> I have some comments here...
>
>
> > ***url/cgi parameter checksumming
> > One option I'm considering is to use cryptographically secure
> > checksums for
> > urls/parameters.
> >
> > So the attacker must be able to guess the correct checksum
> > which is only
> > valid for that session-id and that particular url. The url
> > could also have
> > a randomized parameter (salt) to make things more interesting for the
> > attackers.
>
> You could implement this on the server side with little more overhead than
that of basic authentication.
> For example,
>
> User connects -> ip grabbed as salt
> User logs in -> session key generated,
>    signed with secret (possibly hash of username and password using DES)
>    and maintained under IP of requesting machine + username
> User does stuff -> session key verified using lookup of secret,
>                   signature verified or access denied
>
> Session ends or user logs off -> clean up
>
> benefits
>
> readily available semi random data (no more entropy issues)
> one time passwords will still work.
> no client side code needed.
> no special url's to generate.
> likely as fast as basic auth.
>
>
> In order for an attacker to impersonate, they would have to spoof the IP,
know the password, and get the session key. If they can do all that they
can just log in.
> > Example:
> > checksum=sha1(cookie.sessionid, cgi parameters and values,
> > salt, secret).
> >
> > The secret (nominal 160 bits of entropy) could be a constant,
> > or if you're
> > paranoid it could be randomly generated for that session. Though the
> > entropy won't be 160 bits, the attacker is unlikely to brute force it
> > successfully.
> >
> > The issue I'm having with this is- it's more resource
> > intensive and a lot
> > less convenient! Every url or form on a webpage has to be
> > checksummed. And
> > checking when it's a HTTP-POST is not as easy :(.
> >
> > A potential issue remains:
> > Say a webapp has a view message page, and on that page there's a high
> > impact option like "delete folder now!".
> >
> > If a webapp user happens to read a malicious message on that
> > page, some
> > fancy javascript might be able to cause the user to visit
> > "delete folder
> > now!" from the message view page. And naturally that link
> > will checksum
> > correctly.
> >
> > A solution would be to avoid having such options available
> > when viewing
> > foreign content, in addition to the usual confirmation screens. Also
> > turning off stuff like javascript/ActiveX (triple yuck!)
> > would be a good
> > idea.
> >
> > If anyone has other solutions I'd be glad to hear it,
> > especially if they
> > are easier to do :).
> >
> > Cheerio,
> > Link.