Vulnerability Development mailing list archives
Re: How to prevent malicious linking/posting to webapps?
From: Lincoln Yeoh <lyeoh () POP JARING MY>
Date: Wed, 13 Sep 2000 16:46:28 +0800
At 11:24 PM 11-09-2000 +0200, Bluefish (P.Magnusson) wrote:
And the web app has a command which is accessed by a url similar to http://www.mydomain.com/webapp?command=deletefolder&folderid=1 (assuming using cookies for session authentication and the session is
active).
So.... We would perhaps draw the conclusion that having the session id in a cookie is a bit... risky ;-) Given that you can fool someone to run your javascript or html file while browsing the site in another window.... *argh*
But having the session id in the url (the alternative to cookies) means it can be taken from the http-referer field, if a user is somehow directed to a malicious website (less likely but not impossible). I am also assuming that cookies could be stolen by the attacker through stuff like javascript (ick!). However the attacker cannot directly use these cookies if we tie the session-ids to the legitimate user's source IP (risking problems for some legit users). Thus it's more likely for the stolen cookie info to be used to launch a less direct attack - like malicious links/redirects. Well since I haven't had many responses I'll put some stuff up for discussion: ***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. 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.
Current thread:
- All Advantage Spyware Daehlie Owns (Sep 12)
- Re: All Advantage Spyware Nick Summy (Sep 12)
- Re: All Advantage Spyware Justin Lintz (Sep 12)
- Re: All Advantage Spyware Robert Collins (Sep 12)
- Re: All Advantage Spyware Blue Boar (Sep 12)
- Re: All Advantage Spyware Brad Griffin (Sep 12)
- Re: All Advantage Spyware Thierry (Sep 12)
- Message not available
- Re: All Advantage Spyware Dimitry Andric (Sep 12)
- How to prevent malicious linking/posting to webapps? Lincoln Yeoh (Sep 12)
- Re: How to prevent malicious linking/posting to webapps? Bluefish (P.Magnusson) (Sep 12)
- Re: How to prevent malicious linking/posting to webapps? Lincoln Yeoh (Sep 13)
- Re: How to prevent malicious linking/posting to webapps? Robert Collins (Sep 14)
- Re: How to prevent malicious linking/posting to webapps? Pluto (Sep 13)
- Message not available
- Re: How to prevent malicious linking/posting to webapps? Slawek (Sep 12)
- Re: All Advantage Spyware Russel Smith (Sep 12)
- Re: All Advantage Spyware Jonathan Rickman (Sep 12)
- Re: All Advantage Spyware Brad Griffin (Sep 12)
- Re: All Advantage Spyware Doug Kahler (Sep 12)