Difference between revisions of "Client Test Cases"

From XMPP WIKI
Jump to navigation Jump to search
Line 28: Line 28:
# Carbon sender impersonation [https://rt-solutions.de/en/2017/01/cve-2017-5589_xmpp_carbons/ CVE-2017-5589]  
# Carbon sender impersonation [https://rt-solutions.de/en/2017/01/cve-2017-5589_xmpp_carbons/ CVE-2017-5589]  
# MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
# MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
# Impersonation via XEP-0297 Stanza Forwarding:
# Impersonation via XEP-0297 Stanza Forwarding: Similar to the MAM impersonation but with a top-level <forward> element. Clients are supposed to clearly indicate that a message has been forwarded. Misbehaving clients might instead show the forwarded message as if it came from that person. There's also zero guarantee that a forwarded message is not in fact a forgery.
Similar to the MAM impersonation but with a top-level <forward> element.
Clients are supposed to clearly indicate that a message has been forwarded.
Misbehaving clients might instead show the forwarded message as if it came from that person.
There's also zero guarantee that a forwarded message is not in fact a forgery.


= Multi User Chats =
= Multi User Chats =

Revision as of 14:14, 13 September 2019

This is a list of different test cases that client developers should apply to their code base.


Tool Suite

TODO: create and document an automated tool suite.

An ideal tool suite would be one of (or all of):

  • A hosted component with well-defined JIDs exhibiting the test case behavior
  • An XMPP component that can be self-hosted
  • A set of bot scripts / tools that can connect to a given (set of) account(s)

Message Errors

A client should properly support the following cases:

  1. A message is rejected by the other side - display error on message, show text message describing the failure in the details
  2. A message is accepted by the other side (you receive a Receipt) - display normally or with an additional checkmark
  3. A message is accepted (Receipt), then bounced (you receive an error) - the error is probably from a stale session and should be ignored - display checkmark
  4. A message is bounced, then accepted - first display error, then checkmark

There is a hosted version of test 1. at xmpp:reject@yax.im

Impersonation attacks

  1. Roster push impersonation CVE-2015-8688
  2. Carbon sender impersonation CVE-2017-5589
  3. MAM impersonation: a <message> from a remote JID containing a <result> with a wrapped <message>
  4. Impersonation via XEP-0297 Stanza Forwarding: Similar to the MAM impersonation but with a top-level <forward> element. Clients are supposed to clearly indicate that a message has been forwarded. Misbehaving clients might instead show the forwarded message as if it came from that person. There's also zero guarantee that a forwarded message is not in fact a forgery.

Multi User Chats

Joining

  1. A join is not responded to at all by the MUC
  2. A join is responded to with an error presence
  3. A join is responded with a captcha challenge message
  4. After sending the captcha challenge response a MUC responds with a "not-authorized" error presence (which does *not* mean in this case the muc is password protected)
  5. Captcha messages may be archived (MAM) by the server, a client should ignore them
  6. The join response does not contain a subject
  7. The join response does not contain a self-presence
  8. The join response neither contains a subject nor a self-presence

Staying inside

  1. The client gets kicked by the MUC, with or without a message
  2. The client gets banned by the MUC, with or without a message
  3. The MUC join completes, but the occupant is then silently removed, all subsequent messages get rejected (see XEP-0410)

MUC-PMs

TODO

Affiliation

  1. The client gets muted by the MUC, with or without a message

Other

  1. Another occupant sends an invalid presence to the room (I'm looking at you, old Gajim)

HTTP File Upload

A testing component could reject the file slot request IQ with different errors based on the requested file name / file size. A client developer would have a set of according files to trigger different conditions.

Jingle

TODO: all kinds of handshake failures

MAM

TODO: incomplete archive, incoherent IDs, duplicates