[Cialug] Security on social networking sites

Josh More morej at alliancetechnologies.net
Wed Mar 28 10:03:38 CDT 2007


The problem with hard inside is what Vista is currently experiencing. 
You wind up with numerous "is it OK" dialogs, which can be easily
circumvented.  You might be able to mimic the Linux/OSX solution, and
for every account on the system, you have numerous authentication
levels.  For example, if you detect that a user wants to post a link,
you can require them to first supply their 'tiered' password for that
level of access.  This is then cached for the session.  That would
mitigate the "hacked account" problem, requiring someone to gain/sniff
multiple passwords.  Moreover, it would allow a check for non-standard
use.  In other words, if the hacked account is not normally posting
links then the attacker cannot sniff the password -- it's not in use to
be sniffed.

This obviously doesn't help against an attacker with their own account,
but you could do there what I assume Flickr is doing.  Simply build a
log of all URLs/javascripts detected as they are posted, and feed that
log into a queuing system.  Then, as the queue is checked, you can
remove "bad" posts.  Where flicker fell down is that they only have two
levels:  good and bad, or alive and deleted.  For this to be truly
secure, you need a "pending" type, where posts can be help until they're
known to be good.  Then, the posting user can see their own pending
comments, but the recipient cannot until the post is known clean.

In fact, there might be a need for a URL cleansing service, so that
Flickr could access the API on someone else's server, post a string of
URLs, the service assigns immediate IDs to each, and checks them, and
eventually returns the replies to flickr.  This would reduce the load on
the flickr servers, and possibly provide an income stream for someone
else.  The money would be in the aggregation if other clients use the
service, as you could cache urls and not need to check them.  There
would, of course, be similar problems to what anti-spam blacklists have
encountered, but those are resolvable.  Such a system could also tie
into dshield, and web filtering systems, if the demand was there.

The hard part of the problem is knowing what to check.  You can use
scripting to make the browser construct links that the servers never
see.  The post-parsing engine would basically have to have a rendering
engine in it, and one for each major browser.  That's a non-trivial
exercise.


  

-Josh More, RHCE, CISSP, NCLP 
 morej at alliancetechnologies.net 
 515-245-7701


>>> "Nathan Stien" <nathanism at gmail.com> 03/28/07 9:23 AM >>> 
On 3/28/07, Josh More <morej at alliancetechnologies.net> wrote:
> It's a classic example of gluing security on afterwards.  Flickr has
> some great security concepts in their API, but it's another of those
> "hard outside, soft inside" models, where once you get in, you can
do
> anything you wish.

Do you (or any other cialuggers) have any good ideas on what they
could do to make it "hard outside, hard inside" without sacrificing
usability for non- technical people?

A first step seems like you could just scan links in incoming content
for ".exe".  I've seen a few poorly designed (IMHO) CGI systems that
expose ".exe" in the URL, though, which would be broken by this.  A
more resource- intensive method might be to actually connect to the
server and get a mime type for the content.  This might grab people
who try to use redirects (e.g. tinyurl), but I imagine the cost of
checking every single href in every comment post might be prohibitive.
 Thoughts?

Presumably Flickr are already doing some kind of checking for this
after the fact, since they were on the ball enough to eventually
delete the offending comment from your post.

--  
Nathan P. Stien
Consulting Engineer / Software Developer
Embedded Systems Electronics and Software
http://linkedin.com/in/nathanstien
Mobile: 309.241.2581
_______________________________________________
Cialug mailing list
Cialug at cialug.org
http://cialug.org/mailman/listinfo/cialug



More information about the Cialug mailing list