Openfire server processes XML section rules

Original works can be reprinted. During reprinting, you must mark the original source, author information, and this statement in hyperlink form. Otherwise, legal liability will be held. Http://blog.csdn.net/love254443233/article/details/7850075

Server rules for processing XML sections

Each server implementation will contain its own processing accepted section logic. this write logic determines whether the server needs to route a given section to another domain or deliver it to a local entity (typically a client connected to a local account ), or it can be directly processed by the server itself. this chapter provides general rules for processing the XML section. however, special XMPP applications can define delivery rules to modify or supplement the following rules (for example, a series of delivery rules defined for XMPP instant messaging and online status information applications ).

Sequential processing

An XMPP server must ensure that it processes the sections and other XML elements received from a connected client or a remote server from a given inbound stream.

Sequential processing applies to (a) any XML Element Used to negotiate and manage XML streams, and (B) all XML sections, including but not limited:

1. A section sent by a client to its server or its own pure jid that is directly processed by the server (for example, the order of getting a friend roster and initializing attendance information as described in XMPP instant IM ).
2. A section sent by a connected client and is used to deliver to another entity related to the server (for example, a section from an address <juliet@im.example.com> to a <nurse@im.example.com> ). the server must ensure that the segments received from the inbound stream of the sending client are delivered to the expected recipients in order, the recipient address of the delivery destination is treated as a pure jid and a full jid.
3. A section sent by a connected client and is used to deliver to an entity on a remote server (for example, from address <juliet@im.example.com> to <romeo@example.net> ). the routing server must ensure that the segments received from the inbound stream of the sent client are routed to the segments expected to the receiver, the receiver address of the route destination is treated as a pure jid and a full jid. to help ensure sequential processing, the routing server must route these nodes through a single outbound stream to the remote domain,
   Instead of sending some sections on one server-server stream and sending some other sections on another server-server stream.
4. A section of a related entity (for example, from address <juliet@im.example.com> to <romeo@example.net> and routed to <example.net> on a server-server stream by <im.example.com> ). the delivery server must ensure that it delivers the section according to the order it receives from the ingress server's inbound stream, and treat the delivery destination receiver address as the pure jid and the full jid section.
5. A section sent from one server to another for direct processing by the remote domain (for example, from <im.example.com> to <example.net> ).

If the server's processing of a specific request affects the processing of data that may be received from the inbound stream (for example, a mandatory communication policy), it must suspend the processing of the subsequent data, until the request has been processed.

Sequential processing is only applicable to a single inbound stream. therefore, the server is not responsible for securing it from the same local account (for example, the Section received from <juliet@im.example.com/balcony> and <juliet@im.example.com/Chamber> through two different inbound streams) or the same remote domain (for example, a remote domain uses two different inbound streams for stream negotiation; however, the server can close the stream (4.9.3.3) with a <conflict/> stream error. If the remote server tries to negotiate multiple streams,
For details, see 4.9.3.3.

General considerations

At the top layer, the server has three main considerations for processing the XML section. They are sometimes different, but they need to be managed in a consistent way:

1. If possible, it is better to deliver a section to the specified receiver.
2. If a section cannot be delivered, it is helpful to notify the sender.
3. Facilitating Directory Access attacks (13.11) and connection status leaks (13.10.2) are not good.

Possible delivery-related attacks should be kept in mind as follows:

1. From the attacker's perspective, the server (I) Delivery node or the offline message stored for later delivery (see [{rfc6121 | XMPP instant im]) and (ii) ignore it quietly (because it does not return an error immediately under any use case) If there is any difference; therefore, in the scenario where the Server delivers a section or bar offline storage for later delivery, if the account does not exist, it needs to quietly ignore this section.
2. How does the server handle the issue of sending the jid <localpart @ domainpart> to a section affected by directory retrieval? If the server responds differently based on whether an account has an account for a given pure jid, the attacker can determine whether an account exists.
3. How does the server process messages sent to a section containing all jids affected by information leakage, because a request can be sent to multiple full jids and different responses can be received online based on whether the user has a device with full jid. using Random resources (whether generated by the client or the server, see Chapter 7) can significantly mitigate this attack,
   Therefore, to some extent, it is attacked by the Directory of hell.

Naturally, if the entity that receives an error from a user's server knows the user's attendance information or is authorized to know it, the attendance information is not leaked (for example, the so-called attendance information subscription or direct attendance information). If the server returns an error to an entity that already knows a user, the server is not under Directory Access attacks (for example, because the entity is in the user's contact list). For more information about these things, see XMPP instant im.

No 'to' address

If the section does not have the 'to' attribute, the server must handle it directly by sending its entity. The meaning of "directly processing it" here depends on whether the section is message, presence, or IQ. because all the sections received from other servers must have the 'to' attribute, this rule applies only to the sections received from the local entities connected to the server (usually a client.

Message

If the server receives a message section without the 'to' attribute, it must treat the message as the 'to' address as the pure jid of the sending entity <localpart @ domainpart>.

Presence

If the server receives a presence section without the 'to' attribute, it must broadcast this section to the entity that subscribes to the attendance information of the sender entity, if applicable (XMPP multicast im defines the semantics of such broadcasts for attendance information applications ).

IQ

If the server receives an IQ section without the 'to' attribute, it must represent the account sending this section to process this section, as shown below:

1. If the IQ section is of the "get" or "set" type and the server understands the namespace with a limited load, the server must handle this section on behalf of the sending entity or return an appropriate error to the sending entity. although the meaning of "processing" is determined by the semantics of a limited namespace, generally, the server returns an IQ section of the appropriate type "result" or "error" to respond to a section of the "get" or "set" type, the response is as if the server is sending the pure jid of the object. for example, if the sending entity sends an IQ section with the type "get" and the load is limited by the 'jabber: IQ: roster' namespace (see XMPP instant IM,
   Then the server will return the roster related to the pure jid of the sent object to the specific resource that requests the roster to send the object.
2. If the type of the IQ section is "get" or "set" and the server does not understand the namespace that limits the load, the server must return an error to the sending entity, this error must be <service-unavailable/>.
3. If the IQ section is of the "error" or "result" type ", the server must process the error or result based on the load or type related to the IQ, "get" or "set" (if no related section exists, the error or result section must be ignored on the server ).

Remote domain

If the jid domain contains a 'to' attribute but does not match any of the complete qualified domain names configured on the server (fqdns, the server should try to route this section to the remote domain (subject to the local server's Inter-Domain Communication rules and security policies, because such communication is optional for any given deployment ). there are two possible use cases as described in the following chapter.

Security Warning: These Rules apply only to client-server streams. As described in 8.1.1.2,
If the domain part of the jid in the 'to' attribute and the fully qualified domain name (FQDN) of the receiving server do not match, the server cannot (must not) receive the section on a server-server stream.

Existing stream

If a server-server stream already exists between two domains, the sender's server should try to route this section to the authorization server for the remote server on the existing stream.

No existing stream

If there is no existing Server-server stream between the two domains, the sender's server will handle the following:

1. Resolve the complete qualified domain name (FQDN) of the remote domain, as described in 13.9.2 ).
2. Negotiate the server-server stream between two domains (as described in Chapter 5 and chapter 6 ).
3. Route this section to the authorization server for the remote domain on the newly created stream.

Error Handling

If a route to the expected receiver's server fails, the sender's server must return an error to the sender. if the remote domain fails to be parsed, the local error must be <remote-server-not-found/> (8.3.3.16 ).
If the parsing is successful but the stream cannot be negotiated, the error must be <remote-server-Timeout/> (8.3.3.17 ).

If the stream negotiation with the expected receiver's Server succeeds, but the remote server cannot deliver this section to the receiver, the remote server must return an appropriate error to the sender through the sender's server.

Local Region

If the domain of the jid contained in the 'to' attribute matches the complete qualified domain name (FQDN) of the server, the server must first determine whether the FQDN is provided by the server itself or by a specific local service. if it is the latter, the server must route this section to that service. if it is the former, the server must perform the following actions. in any case, the server cannot (must not) route or "Forward" this section to another domain, this is because it is the responsibility of the server to process all the domain parts of the 'to' address and the configured FQDN matching section of the server (In addition, this can also prevent loop processing ).

Domain

If the format of the jid contained in the 'to' attribute is <domainpart>, then the server must either (a) Perform proper processing based on the section type, or (B) an error section is returned to the sender.

Domain/Resource

If the jid in the 'to' attribute is in the format of <domainpart/resourcepart>, the server must either (a) Perform proper processing based on the section type or (B) A section error is returned to the sender.

Local part @ domain part

This type of address is usually related to an account on the server. The following rules provide some general guidelines. For more details about the rules for instant messaging and attendance information scenarios, see XMPP instant im.

This user does not exist

If no local account is associated with <localpart @ domainpart>, how the section is processed depends on the type of the Section.

1. For message section, the server must either (a) quietly ignore this section, or (B) return a <service-unavailable/> section error (8.3.3.19) to the sender.
2. For the presence section, the server should ignore this section (or as described in XMPP instant IM ).
3. For the IQ section, the server must return a <service-unavailable/> error (8.3.3.19) to the sender.

User exists

If the format of the jid contained in the 'to' attribute is <localpart @ domainpart>, how the section is processed depends on the section type.

1. For message section, if the account has at least one connected resource, the server should deliver this section to at least one connected resource. if no connected resource exists, the server must either (a) store the message offline and deliver it the next time the account has connected resources, or (B) returns a <service-unavailable/> error (8.3.3.19 ).
2. For the presence section, if an connected resource has sent an initial presence (that is, there is a "presence session" as described in XMPP instant IM "), the server should deliver this section to that resource.
   If no connected resource exists, the server should ignore this section (or as shown in XMPP instant IM ).
3. For the IQ section, the server must handle it directly on behalf of the expected receiver.

Local part @ domain part/resource part

If the jid contained in the 'to' attribute is in the format of <localpart @ domainpart/resourcepart> and the user exists but no connected resource can exactly match the full jid, this section should be processed as described in 10.5.3.2 when the jid format is <localpart @ domainpart>.

If the jid in the 'to' attribute is in the format of <localpart @ domainpart/resourcepart>, the user exists and a connected resource exactly matches the full jid, the server must deliver this section to the connected resource.