11.5 跨协议攻击

CoAP端点向虚假的源地址发送包不仅能用于增幅，也能用于对一个监听给定地址(IP地址和端口)的受害者进行跨协议攻击。按照下面步骤就会发生：

攻击者往CoAP端点发送一个带有将虚假源地址当做给定地址的消息。

CoAP端点向给定的源地址发送响应消息。

在给定地址接收UDP包的受害者就会按照不同协议的规则进行解析。

它可以用于绕过阻止从攻击者向受害者通信的防火墙规则，但是将允许从CoAP端点(在其他协议中也担当有效角色)到受害者通信。

另外，CoAP端点可能成为由其他基于UDP协议(譬如DNS)的端点发起的跨协议攻击的受害者。在这些情况下，如果端点的安全属性依赖于检查IP地址(和使用虚假IP地址来切断外界攻击的防火墙)，就有可能遭受攻击。通常，由于基于UDP的协议缺乏上下文，因此它们更容易成为跨协议攻击的目标。

最后，由其他方式传输的CoAP URI能够用于使得客户端往其他协议的端点发送消息。

一个减轻跨协议攻击的措施是严格检查接收包的语法和语法中的足够多的差异。举个例子，如果很难使得DNS服务器向CoAP端点发送一个传递检查的DNS响应，那么就会起作用。可惜的是，DNS回复的前两个字节是能被攻击者选中的ID，并且映射为CoAP头部的关键部分，后面两个字节被当做CoAP的消息ID(任何值都可行)。DNS的计数字可以当做一个(不存在但是可选的)CoAP选项0的多重实例，或者当做一个Token。攻击者利用重复的查询来在CoAP端点上达到一个预期效果；服务端增加的响应(如果有的话)将被当做额外的负载。

0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 15: DNS头部 ([RFC1035]的4.1.1节[http://tools.ietf.org/pdf/rfc1035#section-4.1.1]) 和 CoAP消息

一般来说，对于任何一对协议，协议之一很容易设计为使得攻击者生成类似另一种协议的消息的回复。比起保证或者证明不存在可实行的攻击，生成可能未完全启动的但可能被二次开发的攻击的实例通常更加困难。如果端点依据受信任包的源IP地址而没有授权攻击者，那么跨协议攻击才能完全的减轻。相反的，完全依赖防火墙的NoSec环境下的CoAP安全不仅需要防火墙来切断CoAP的端点，并且使得所有其它的端点使用一些基于UDP的协议来往CoAP端点发送UDP消息。

除了上面的考量，也要考虑跨协议攻击的DTLS安全。举例，如果相同的DTLS安全连接("connection")用于传输多种协议的数据，那么DTLS就不对这些协议提供应对跨协议攻击的保护。