Assurance

["Joe St Sauver" <>]

Hi,

Steven wrote:

#I'll summarize the long back story.. a student recently brought us an 
#new app that they had recently built. Its 120 lines of javascript, and 
#leverages both node.js and the meteor platform. 

bearbucks.meteor.com appears to be down, so I can't check directly, but
I'm assuming that the Javascript was loaded from the web page, and run
in the user's browser, correct?

1) Security types will tell you that disabling scripting in the browser is
a best practice, but if you do, obviously that breaks all sorts of things
that have become routine (like much of Google's functionality). Hence,
people run with scripting enabled, which is really *quite* insecure.

I used to show people pages with irritating but non-damaging JavaScript
special effects, but I've seen some people who'd had JS disabled who've
turned it on just to see the weirdness, so I've stopped doing that. :-(

2) Alternatively, you can run something like NoScript as a browser extension,
but many non-techncial users find that it drives them crazy and really
hurts the web experience (and thus quickly gets disabled or uninstalled),
and thus you're back at ground zero, typically with scripting enabled.

For example, Noscript tends to flag XSS vulnerabilies for Shib :-;

But if the endpoint is insecure, as it is with scripting enabled, its 
largely game over, I'm afraid.

#This app sits in front of our Banner student system and acts as a proxy. 
#It presents its own login page, 

... users *should* perceive that site as a potential phishing site, right?

If they connect to yee-old.randomsite.foo, and it asks them for their
institutional credentials, they know that they should run away, not
give them up, and then immediately tell their local IT security folks, 
right? 

#and immediately navigates thru Banner and retrieves how many dining hall 
#points that user currently has. 
#
#The good news is that while the student actually deployed this in the 
#cloud (bearbucks.meteor.com), he also brought it to our attention. It 
#didn't take much effort to develop this app. We've also determined that 
#a slightly modified version of this app works just fine with our IDP 
#login page.
#
#Up until now, we had been thinking that 2-factor would provide a defense 
#against phished and stolen passwords.

It depends on the type of two factor you deploy. Not all technologies
are equally robust to MITM (or MITB (Man In the Browser)) attacks. 

See http://en.wikipedia.org/wiki/Man-in-the-browser for a discussion of
MITB.

Also note that at least some two factor solutions WILL protect against
subsequent attempts at exploitation, even if they may fail against an
active real-time MITM/MITB attack (thin gruel, but sometimes you take
what you can get). 

#But, this is a little different. This proxy sits in front of our apps; 
#it isn't a dead end that's just trying to trick people into entering 
#their passwords.
#
#Most worrisome, tho, is that we think that if we implemented some forms 
#of two factor in the authN process of our apps that this proxy could 
#quickly evolve to handle the extra step. 

True, for some forms of multifactor, harder for others.

#If we TXTed a code to the 
#person's mobile phone and presented a web form, the proxy could easily 
#handle that. We also expect that the proxy could evolve to deal with 
#CAPTCHA style approaches.

Again, I agree with your analysis, however fortunately there are other
forms of two factor that are more robust.

Ultimately, however, if a user decides to use their two factor solution
to approve an unsafe authentication operation, you're basically SOL.

#So, beyond user education, 

Candidly, it's hard to imagine a program of user education that would
be whole-ly successful at fully thwarting this exposure.

Users routinely approve all sorts of horribly insecure stuff (e.g.,
"This site uses an untrusted cert to identify itself, issued by
Snakeoil, Inc. Would you like to add the certificate authority used
by this certificate to your list of trust anchors?" "Sure, why not?"
[click],[p0n3d])

Regards,

Joe