Tag Archives: Security

About security issues.

Guarding against XSS code injection

We had posted earlier about making sure that (malicious) users cannot inject code into Kerika, in any of the areas where user input is possible.

Here’s the complete list of user actions that we are checking for XSS injecton now:

  1. Board Name
  2. Board Description
  3. Template Name
  4. Template Description
  5. Tag Name
  6. Card Attachment Name
  7. Board Attachment Name
  8. Card Chat
  9. Board Chat
  10. Column Name
  11. Task Name/Detail
  12. Canvas Text
  13. Canvas Attachment Name
  14. Canvas Shape/Object Name
  15. Account Name
  16. Account Billing Information
  17. User’s Name

Guarding against XSS/code-injection

It’s possible to copy-paste text into a Kerika Chat message, and there are legitimate use-cases for this: for example, a developer may ask a question to a coworker who replies with a code snippet.

Kerika handles code in chat messages by storing two versions of the message: as plain-text, and as the original format. When a chat message is displayed, the original format is used but not executed, which means the embedded code is visible, but doesn’t run in the browser. This makes it easy and safe to share code snippets through chat messages.

While making this improvement, we went through all the places where a user can type in text, Card Title and Description, Board Name and Description, Tag, Attachment Name, etc. to make sure we are guarding against malicious code injection.

We will start to do IP blocking

Regrettably, we will start doing IP blocking to stop persistent spammers from setting up Kerika accounts.

We have seen a consistent pattern of misuse that goes like this:

  • Someone signs up with a sina.com email address.  Sina is one of the largest ISPs in China, but we don’t have any users in China for the simple reason that most of Google’s services are blocked by China’s Great Firewall, and Kerika has a tight integration with Google’s G Suite.
  • The spammer isn’t actually located in China; they are in Manila (Philippines) and come from IP addresses like 203.177.13.60
  • These spammers send out hundreds, sometimes thousands, of invitations for users from the qq.com domain to join their (spurious) Kerika team.
  • These recipients are all users of Tencent’s QQ messaging system, based in China. Again, none of them would be actual or potential Kerika users, since the recipients are all located in China.

The user impact of this spamming was relatively small: almost no one with a qq.com email address would reply to these invitations, but the conduct was a very clear misuse of Kerika and harmful to our reputation, quality and brand.

(Among other things, these spurious invitations would pile up in the thousands.)

We have decided, therefore, to start blocking IP addresses using Amazon’s VPC service (since we use Amazon AWS extensively on our back-end.)

This is a brute force method, and not ideal, but we were starting to get really annoyed with these folks.  We hope this doesn’t impact any of our real users in the Philippines; if you are affected, please let us know!

Managing the privacy of your Kerika boards

Kerika offers a great deal of control over how each board is shared:

  1. A board can be made public to everyone.  This makes sense for open-source projects and many nonprofit and advocacy groups, where the goal is to get maximum visibility and publicity rather than to hide the details of what the project is about.

    Making a board public means that anyone who has the URL of the board can view it, even people who are not Kerika users.  Note: we are talking about viewing the board; viewing doesn’t mean anyone who isn’t part of the board team can make changes.

    If a board is viewable by the public, it can be found by anyone using Kerika’s search function.

  2. A board can be viewable by everyone who is part of the account team. This is the default setting, and it makes a lot of sense for most organizations: you want your coworkers to be aware of what your team is doing, unless the project is particularly sensitive.

    An account team consists of everyone who is a Team Member or Visitor on any board owned by the account.

    As people get added to individual boards, they are also automatically added to the account team.  When someone is removed from every board owned by an account, they are automatically removed from the account team as well.

    As with public boards, described above, we are talking only about viewing, not changing: only people who are Board Admins or Team Members on a particular board’s team can make any changes to that board. (And, of course, the Account Owner who owns the board.)
    If you use Kerika’s search function, you can find boards that are being shared with the account team, provided you are part of that particular account team.

  3. A board can be kept private.  This means that only the people who are listed on the board’s team — as a Board Admin, Team Member or Visitor — can view the board.  (And, of course, the Account Owner who owns the board.)

    This is appropriate for any sensitive projects, e.g. stuff related to personnel matters or confidential contracts.

    Private boards can’t be found by Kerika’s search function either, and it doesn’t matter if you know the URL for the board: only the specific people listed on the board team can see anything related to that board.

For each board owned by an account, the Account Owner or Board Admins can manage the board’s team: decide who is part of the team, and what sort of role (Board Admin, Team Member, or Visitor) each person has.

  • Board Admins and Team Members can make changes to all the items on the board, including any documents attached to the board.
  • Visitors have read-only access to the board and all its documents.
  • A person’s role can be changed at any time by the Board Admin or Account Owner: the effect is immediate, and extends to all the documents associated with the board as well regardless of whether you are using Google or Box for your file storage, or whether you are storing your files with Kerika.

A board’s team and current privacy settings can be viewed by clicking on the Team button that appears on the top-right of the Kerika app, when viewing a board:

Board Team button
Board Team button

Clicking on this button brings up the Board Team dialog:

Board Team dialog
Board Team dialog

Each person who is part of the Board Team is listed in this dialog, in alphabetical order along with their role.

At the bottom of the dialog is the board’s current privacy setting: in the example shown above, the board is being shared with everyone who is part of this user’s account team. (We have obscured the URL in the screenshot for security reasons.)

If you are a Board Admin or the Account Owner, you can change the privacy of the board using the Change Privacy link that’s shown on the bottom of the dialog:

Board Privacy options
Board Privacy options

So, every board can have it’s own privacy settings: private, shared with account team, or public.

When you are viewing the boards in an account, Kerika shows clearly what the privacy setting is for each board:

Privacy settings, at a glance
Privacy settings, at a glance

If you are part of someone’s account, you will be able to create new boards in that account: you will automatically be a Board Admin on those new boards, but the owner will always be the account you are working in.

You can set your privacy preferences for each account; this will determine whether new boards you create are automatically shared with your coworkers or not:

Privacy preferences
Privacy preferences

All your preferences can be set at https://kerika.com/preferences.  The default setting is Share with Account Team, which works well for most people, most of the time.

 

Switching to Let’s Encrypt for our SSL certificates

We have mentioned below the problems we had with GoDaddy’s SSL certificates; we have fixed this by switching to the open-source certificate authority called Let’s Encrypt.

Lets Encrypt SSL
Lets Encrypt SSL

Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG). It lets us host our own certificates, so we don’t have to rely upon third parties and can have better control over the quality of our service.

Learning to live with email sandboxing

We spent hours recently trying to understand why a particular user wasn’t able to join her coworkers boards, before finally figuring out that it was her company’s “email sandboxing” that was messing up Kerika’s invitation flow

The problem was a real nuisance to debug, and we fear it will affect more of our users in the future so we are going to make a change to our invitation process to make sure it continues to work well for everyone.

Some background:

“Email sandboxing” refers to a process that tries to trap malicious URLs that are included in emails.  While the exact implementation varies by security vendor, the basic process is the same: use a virtual machine as a sandbox, and click on every URL contained within an email.

This can trap a lot of malware emails.  If the URLs are designed to be single-use only, i.e. the URL is unique and intended to be clicked upon just once, the sandbox will “explode” the mine before the user gets to it.

More sophisticated implementations of sandboxing will handle multi-use URLs by watching for return traffic from the sender’s machine, which would indicate (potential) attempts to download malicious software onto the recipient’s computer.

The problem with sandboxing:

The sandboxing approach takes the same brute force approach to all links, in all emails, without trying to understand the context of the email itself.

One consequence may be that “Unsubscribe” links contained in newsletters are clicked on automatically by the email sandbox virtual machine, so the recipient gets just one copy of a newsletter that she signed up for.

To get around this, systems that generate emails automatically, like a newsletter, have to move from a one-click unsubscribe (which would be more user-friendly) to a two-step unsubscribe process (which is more annoying to the user.)

You will have seen the two-step unsubscribe process more and more often in your own newsletters and other mass mailings: you click on the “Unsubscribe” link in a newsletter, and you land on a web page where you are asked to, once again, confirm that you want to unsubscribe.

The user might think this is a last-ditch attempt by the newsletter publisher to hold on to their readers, but it might actually be an attempt to safeguard the newsletter’s subscribers from their own brute force security implementations!

How this affected Kerika:

When you invite someone to join your Kerika board, as a Team Member, Board Admin or Visitor, the invitation gets sent to them by email as well from within the Kerika app.  The emailed invitation looks like this example:

Example of invitation email

Example of invitation email

The email contains two links: the most prominent is the Accept Invitation, but there’s also the Reject Invitation.

Email sandboxing plays havoc with this sort of email invitation: there is an equal possibility that a particular sandbox will click on the Reject Invitation link before it clicks on the Accept Invitation link, which leads to a completely random experience for users who are being invited by the coworkers to join Kerika boards, since Kerika lets you act just once upon an invitation: once you accept it, or reject it, you can’t act upon it a second time.

How we discovered this problem:

One of our users, based in California ,was trying — repeatedly and unsuccessfully — to invite another user, based in Taiwan, to join one of her boards, and the process kept failing.

And for the longest time we couldn’t figure out why!

Our debugging seemed to suggest Kerika itself was somehow auto-rejecting invitations on the user’s behalf, which had us really worried about a serious bug in the server before one of our developers got the idea that perhaps the problem was with the user’s email system, and not Kerika.

When he examined the headers on an email we got from the affected user, he found references like these:

Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10])

A little more sleuthing led us to Symantec’s “threat protection” service, which is one of the common email sandboxing systems out there.

How we are fixing this:

We are moving to a two-step process for people who want to reject invitations that come to them by email: clicking on the Reject Invitation will now take you to a Web page where you will be asked to confirm that you want to reject the invitation.

It’s one more step for users, and not the kind of superb user experience we aim for, but without this there’s no way for us to make sure that the best intentions of security vendors don’t end up crippling our own business!

Why this blog uses HTTPS

It’s not that we have sensitive stuff on the blog: quite the contrary. It’s just that we have implemented HTTP Strict Transport Security (HSTS) across the entire kerika.com domain.

HSTS s a security mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking.

It allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.

Since our blog is on a sub-domain of kerika (blog.kerika.com, to be precise), we needed to implement SSL and HTTPS for the blog as well.

Changing your Kerika password

For folks who sign up directly with Kerika, we store the user password (in an encrypted form, of course), which means that these users can change their passwords directly from within the Kerika application by going to their My Account page at https://kerika.com/my-account:

Changing password for Google sign up
Changing password for Google sign up

For people who sign up using their Google or Box IDs, we rely upon Google/Box to manage their passwords: in fact, we never even see anyone’s Google or Box password, even for a second!

So, their My Account page looks a little different, like in this example of a Kerika+Google user:

Changing password for Google sign up
Changing password for Google sign up