OStatus/Security

Things to consider...

Trust

Within a single StatusNet instance, we've got one piece of software that controls the data for both subscribers and subscribees, so we know that when a message claims to be from a given account that it's legitimate. When dealing with accounts on remote servers, we know a lot less about the internals, and need to be more careful!

The trust root for a given remote account is its profile URI; anything that we can confirm from that profile URI we know is good... or at least is as good as it applies to that profile URI.

From the profile URI we learn:

• URI of its Atom feed
  • so we trust that things in that feed are legit output from that profile
• URI of the Atom feed's PuSH hub
  • so we trust that PuSH deliveries from that hub are legit representations of the feed data
    • which we validate against a shared secret chosen at PuSH sub setup time
• URI of the Atom feed's Salmon callback endpoint
  • so we trust that when we send notifications to them, they're going to the right place
• Salmon magic signature public key
  • so we trust that any Salmon notifications or replies that are signed with that key are legitimately from that profile

There are other things we might not know so well, however.

• Unique notice identifiers (tag: URIs or offsite URLs) might or might not actually be under the profile's control
  • PRIORITY: LOW
  • RISK? What's the risk of accepting notices with a "unique" ID that might conflict with someone else's legit notices? Possible DoS of other peoples' notices with predictable URIs...
  • Mitigation ideas:
    •  ?

• Secondary profile identifiers (eg messages from various users represented in a group feed) might or might not actually legitimately represent that profile
  • PRIORITY: MODERATE TO HIGH (spoofed messages would appear in the target user's local subscribers' inboxes)
  • RISK? Spoofed profile updates, spoofed notices could damage user reputation.
  • Mitigation ideas:
    •   Record the source feed profile of any given OStatus message; group messages that can't be validated as a direct delivery can be marked as unconfirmed and the bad group tracked down and killed.
      • Downside: extra work for moderators/admins to track down spoof reports, spoofiness possibly not clear enough to other end users. now implemented; source profile and delivery method saved in ostatus_source table -- but may not adequately handle posts that come through multiple channels
    • Perform same-origin check between group's profile URI and group posters' profile URIs and only accept them if they match. Downside: limits full participation between group members on different servers. :(
    • Digitally sign each <event> with Salmon-style magic signature, preserve that signature in group reposts
      • Downside: could be horridly slow.
      • Downside: it may be difficult to validate signatures on republished events

And of course other things that we'll want to keep an eye on...

Resource consumption

PRIORITY: LOW TO MODERATE (memory and time limits in place should cause reasonably fast failout of most such issues)

• access speed, memory consumption for remote resources -- we don't want to fill our disk or delay our real work
  • profile page
  • avatar
  • feed
  • hub
    • mitigation: perform PuSH subscription setup in background
  • salmon endpoint on notifications
    • mitigation: send Salmon notifications in background
• space & time used by a subscription or reply flood

Content safety

PRIORITY: TOP (HTML scrubber in progress via @evan)

Accepting arbitrary HTML content for display within the site can be rather dangerous; we'll need to scrub to limit what HTML is accepted.

• script elements
• scripts in event handlers attributes
• CSS containing JavaScript references
• various other potential horrors

Cleartext exposure

PRIORITY: LOW (server-to-server communications are relatively low-risk compared to client-to-server where untrusted connections are rampant)

• MitM attacks could spoof profile pages etc
  • Spoofed profile page could serve a spoofed public key for Salmon signature validation.
  • mitigation: use HTTPS for profile URIs if possible
• PuSH delivery's HMAC signature is based on a shared secret sent at subscription time. If subscription is performed over HTTP, it could be intercepted or modified.
  • danger period only at PuSH subscription setup time
  • mitigation: use HTTPS for hub if possible

Phishing

PRIORITY: LOW (current OMB model is roughly the same)

Our remote-subscribe UI model works roughly like this:

• you're sitting on a profile page on a foreign site
• you click "subscribe"
• you tell it your home account as Webfinger or profile URI ('somebody@identi.ca' or 'http://identi.ca/somebody')
• the foreign site sends you to your home site to set up the subscription...
  • ...where you might be prompted to log in.

The user needs to be careful to confirm that they're in the right place before putting in their credentials.

Mitigation ideas?

• Instead of sending to the home site, could send a notification to the server which'll display the confirmation next time you visit.
  • Downside: probably much more confusing flow
• Better identity integration with browser to somehow magically confirm you're going to the right place
  •  ???