2

In the latest SPFx video

https://www.youtube.com/watch?v=6r6MqUDzKvI

The SPFX Wizard explains how to add an escape function

Quoting the SPFx Wizard:

"Escape the value for any characters that are invalid or might potentially inject in the script"

Question

  • Does SPFx add any 'special' access to SharePoint REST endpoints?

Because the moment I am logged into Office365,
I can call any available O365 endpoint from any (non-O365/SPFx) script,

So what 'inject in the script' security loophole is fixed with that escape function?

iSPFX iREST

2

How to use escape:

import { escape } from '@microsoft/sp-lodash-subset';

What is sp-lodash-subset:

This package provides a custom bundle of lodash for use with the SharePoint Framework's module loader. To improve runtime performance, it only includes a subset of the most essential lodash functions.

Reference - sp-lodash-subset

What is lodash ?

A modern JavaScript utility library delivering modularity, performance & extras.

Just another plugin IMO.

What security loophole is fixed & what does escape do:

It Converts the characters "&", "<", ">", '"', and "'" in string to their corresponding HTML entities.

Namely, ampersand, less than,greater than and single quote respectively.

Sometimes, some "hackers" nee script kiddies try to inject some malicious characters to perform sql injection or just some harmless mischief like showing alert in the page. When you use this function, it will convert the above mentioned characters to harmless one thus preventing mischief, see below screenshot.

enter image description here

Reference - Lodash escape

No special endpoint is used for SPFx, its the good(perceptions matter) old /_api/web/lists/getByTitle("CustomList") endpoint. Only difference is that here "customlist" is "escaped". You can probably do this using the encodeURIComponent as well.

I checked the file sp-lodash-subset.js inside @node_modules/sp-lodash-subset/dist.

The function escape is as below:

function escape(string) {
      string = toString(string);
      return (string && reHasUnescapedHtml.test(string))
        ? string.replace(reUnescapedHtml, escapeHtmlChar)
        : string;
    }

It internally calls the reHasUnescapedHtml method which is as i descibed above:

var reUnescapedHtml = /[&<>"'`]/g,
    reHasUnescapedHtml = RegExp(reUnescapedHtml.source);    

Does SPFx add any 'special' access to SharePoint REST endpoints?

No it executes with the same rights as the user account that is executing the script, no special priviledges.

  • 2
    I do hope the endpoint itself is protected against injection by smart Microsoft engineers;, so why program an extra layer (which does nothing) yourself? And why do a REST call at all when non-allowed characters are entered? – Danny '365CSI' Engelman Feb 11 '17 at 13:05
0

The message was simply the standard "encode your untrusted input" safety that everyone should be using.

So if your modern webpart has a property "foo", and the end user can simply set the property of "foo", you will want to make sure you encode it before you write it to the page. Many frameworks (like react for example) will do this for you, but if you are simply doing .innerHtml = foo, then if an end user sets foo to be "scriptTag alert('boo'); endScriptTag" then you have a script injection security vulnerability in your code. (ironically, my script tags got stripped out in this RTE, so just pretend they are there in my example)

However in the case of a REST call, rather than escaping the content to display it on the screen, it should instead be UriEncoded using https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent. As the linked document states "To avoid unexpected requests to the server, you should call encodeURIComponent on any user-entered parameters that will be passed as part of a URI."

In this case, an end user setting the property to be "here's a title" would cause the REST call to fail.

So, no special access to end points. Simply a case of "don't trust end user data". I'll follow up with the content creators.

  • My (end)point is that the user's Browser can send anything. This is not the SQL server from years ago requiring injection protection. The Microsoft endpoint itself has protection for that. So adding 'injection protection' yourself is adding, unnecessary, totally not needed, not required, code to the stack.. I am pissed because this so called SPFx wizard has N followers who now are going to write, not required, totally not needed, unnecessary, SPFx code. This is not educating SPFx programmers, this is creating SPFx script kiddies copy pasting code without understanding (like we did with jQuery) – Danny '365CSI' Engelman Feb 13 '17 at 8:42
  • (1) You always need to consider and protect your outputs, whether that is emitting stuff onto a page, or sending it over the wire. Here's why you need to encode your REST parameters. Let's say you have an external email system with a webapi hooked up to your tenancy through AAD/ADAL and available to the contoso.SharePoint.com domain. Basically, you can make REST calls. Now, let's say the API allows batching via URL, by making a call like "my.service.com/batch?getlistname('foo')/item(1)/… – PatMill_MSFT Feb 13 '17 at 18:26
  • (2) Now a mean user (not a developer, a user) could look at the network traffic on a page with your webpart, and notice that you are sending the value of 'listName' over the wire without encoding it. They can now set the listName property to be "myPrivateDocs')/items/copyto('pats/stolen/docs')" and possibly (depending on how the endpoint is written) now copy items from the users private documents. Now if instead you UriEncoded the value, the list being looked at would instead be lists('myPrivateDocs%27%29%2Fitems%2Fcopyto%28%27pats%2Fstolen%2Fdocs%27%29') which would be safe(r). – PatMill_MSFT Feb 13 '17 at 18:32
  • (3) In case it wasn't obvious - the mean user sets the property on the webpart (or field, or whatever) and waits for someone else to visit the page. They don't target themselves. – PatMill_MSFT Feb 13 '17 at 19:22
  • Okay you convinced me.. Microsoft chooses to educate people that Client Side Code can protect (Microsoft) endpoints – Danny '365CSI' Engelman Feb 13 '17 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.