SharePoint Apps a word of caution

Posted on 8/11/2012 @ 12:15 PM in #SharePoint by | Feedback | 2135 views

Lucky for SharePoint, it is the first foray into this brave world where the browser is masquerading as an operating system. For the very first time, with SharePoint 2013, we will have apps from different vendors, talking to different domains live in the browser.

Sound fun eh?

Well, all is hunky dory until you consider that browsers don’t have concepts such as process isolation, encryption, obfuscation etc.. Stuff that we are so used to in operating systems that we don’t even think about it. Browsers have JavaScript, and broken HTML5 – it is not secure! In fact, in the current technology spectrum you cannot achieve anything other than laughable security at message level without involving a plugin or some sort of thick code like Java. The only security worth it’s salt in pure html/javascript scenarios, still, is transport security – and that’s it.

Now, SharePoint 2013 uses numerous services etc. to enable cross-domain oAuth protected requests. If you examine the web.config of SharePoint 2013, you’ll see numerous elements like this,

  <location path="_vti_bin/CrossDomainAjax.ashx">
    <system.web>
      <httpRuntime requestValidationMode="2.0" />
    </system.web>
  </location>

This means, ASP.NET 2.0 style request validation. Request validation was enabled by default. However, it applied only to ASP.NET pages (.aspx files and their class files) and only when those pages were executing.  SharePoint 2013 has chosen to go with the 2.0 model, not the 4.0 model. I can understand why, it is unreasonable for Microsoft to validate every single request that you will send, Microsoft doesn’t know about your incoming requests. As a result, your non-aspx artifacts are wide open to XSS attack.

What kind of attack you may ask?

  • Imagine you have a banking app that uses oAuth to securely access your account information.
  • Imagine that you have a second app on the same page that shows you funny cat videos from youtube.

The cat videos app can have full client side access to the banking app. Not all apps will have this issue, depends how you write them of course. But certainly some will. This means, the funny cats will be able to access cookies, tamper with the page, even iFrames, and worst case scenario, masquerade as an authenticated you, and allow the cat videos app to do whatever the hell it pleases in the Bank of America app – as you of course. The server will have no clue, and frankly it is becoming laughably easy to do things like click-jacking, frankly I’m worried :).

Remember that in all of these scenarios, the SharePoint server itself is completely unharmed, untouched.

What is the workaround? Well you have to be very careful on how you write secure apps for SharePoint. You will need Ninja JavaScript dev. skills, and you will need to understand the app model and security concepts very well. That’s all there is to it. Yeah right!

What worries me of course is, the avg. developer out there, and even worse, the avg. manager out there who are dealing with an overload of technology under shrinking budgets and insane timelines are not going to understand the ramifications of developing secure apps in SharePoint. I mean, the avg. SharePoint developer doesn’t understand the basic concepts of JavaScript or Security. And if that’s the average, half of them are dumber than that. Not to sound condescending, that is really not my purpose here, but technology is getting too complicated even for the experts, and I see this new “power” of “apps” as a fermenting ground for attacks.

Perhaps I’m worrying too much about a funny cat doing bank transfers in my bank accounts. Am I? Is this the return to the Planet of the apps?

Sound off but keep it civil:

Older comments..


On 8/13/2012 11:03:50 PM Nik Patel said ..
Well Said Sahil.. I do concur your view points as well. With the scripted technologies, what worries me more is messy code. I will reserve my thoughts until I really see the full potential (good and bad) of apps archiecture..

Nik