Question

我的测试团队尝试破解系统，他们发现GWT-RPC调用以响应格式返回了敏感信息（文件名如下所示）＆＃34; // EX＆＃34;信息。我很惊讶我在这个问题上找不到任何帖子。

HTTP请求（请求有效负载）：

7 | 0 | 5 |的http：/本地主机：8080 / Test_Web / | 14B8AB60CF9C73722670313BAE18D294 |的 ABC | ABC | ABC | 1 | 2 | 3 | 4 | 1 | 5 | 0 |

HTTP响应：

// EX [2,1，[＆＃34; com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException / 3936916533＆＃34;，＆＃34;此应用已过期，请点击刷新浏览器上的按钮。（阻止尝试访问界面＆＃39; abc ＆＃39;，这不是由＆＃39; com.testProject.client.customerClassService ＆＃实现的39 ;;这是错误配置或黑客尝试）＆＃34;]，0,7]

特别是说＆＃34;错误配置或黑客尝试的部分＆＃34;。在我的情况下，黑客尝试作为HTTP响应，因为异常表明＆＃39; abc ＆＃39;未由＆＃39; com.testProject.client.customerClassService ＆＃39;实施。

如上所述在错误消息中隐藏敏感信息（类名称为重点）的任何想法？我试用所有可用的浏览器，它不是来自浏览器。

Answer 1

gwt-rpc服务接口的名称不应被视为敏感信息。在每个gwt-rpc调用上使用ajax发送该方法和所有方法名称和参数...它类似于可以对它们执行的休息服务API资源名称和crud操作。

您获得的异常是由gwt-rpc服务接口/方法/签名的无效名称引起的 - 该呼叫被阻止。在这种情况下，记住输入参数的服务器端验证很重要。你永远不知道这个电话是你的应用程序发出的还是伪造的......

Answer 2

敏感＆＃39;这里收集的信息非常少，所以我们必须假设您已经打开了所有其他模糊处理（删除了类元数据，混淆了rpc类型名称，并且已经超过了您自己生成的JS以确保没有toString()返回它自己的类名）。

在这种情况下，事实证明，如果此类未实现所请求的接口（显然com.google.gwt.user.server.rpc.RPC#decodeRequest(String, Class<?>, SerializationPolicyProvider)），则这是从abc发出的标准RPC错误。如果有这样的界面，我会感到非常惊讶！可以说，如果这样的界面不存在，甚至不会发生这种检查，但即使进行检查也会背叛有关哪些类不存在的信息。您的服务器，也可以被视为敏感＆＃39;。

如果这是一个问题，我的建议是阻止任何 IncompatibleRemoteServiceException到达客户端。这样可以有效地防止对客户端进行任何调试，但只需填写空白＆＃34;您的错误请求出了问题＆＃34;。有一些合法的情况，客户可能应该从这样的例外中获取信息，但从您的角度来看，这可能仍然是敏感的。如果你的问题没有更详细地说明确切的含义，那就很难说了。

说到这里，我将如何重写此行为：首先，查看RemoveServiceServlet.processCall，这是通常通过将其记录到用户来处理失败的地方：

/**
 * Process a call originating from the given request. This method calls
 * {@link RemoteServiceServlet#checkPermutationStrongName()} to prevent
 * possible XSRF attacks and then decodes the <code>payload</code> using
 * {@link RPC#decodeRequest(String, Class, SerializationPolicyProvider)}
 * to do the actual work.
 * Once the request is decoded {@link RemoteServiceServlet#processCall(RPCRequest)}
 * will be called.
 * <p>
 * Subclasses may optionally override this method to handle the payload in any
 * way they desire (by routing the request to a framework component, for
 * instance). The {@link HttpServletRequest} and {@link HttpServletResponse}
 * can be accessed via the {@link #getThreadLocalRequest()} and
 * {@link #getThreadLocalResponse()} methods.
 * </p>
 * This is public so that it can be unit tested easily without HTTP.
 *
 * @param payload the UTF-8 request payload
 * @return a string which encodes either the method's return, a checked
 *         exception thrown by the method, or an
 *         {@link IncompatibleRemoteServiceException}
 * @throws SerializationException if we cannot serialize the response
 * @throws UnexpectedException if the invocation throws a checked exception
 *           that is not declared in the service method's signature
 * @throws RuntimeException if the service method throws an unchecked
 *           exception (the exception will be the one thrown by the service)
 */
public String processCall(String payload) throws SerializationException {
  // First, check for possible XSRF situation
  checkPermutationStrongName();

  RPCRequest rpcRequest;
  try {
    rpcRequest = RPC.decodeRequest(payload, delegate.getClass(), this);
  } catch (IncompatibleRemoteServiceException ex) {
    log(
        "An IncompatibleRemoteServiceException was thrown while processing this call.",
        ex);
    return RPC.encodeResponseForFailedRequest(null, ex);
  }
  return processCall(rpcRequest);
}

我们不想抓住IncompatibleRemoteServiceException而只是按原样登出，我们想写一份不起眼的文字＆＃34;您的请求出了问题，请提交给技术支持＆＃34;回答。请使用RPC.encodeResponseForFailedRequest或RPC.encodeResponseForFailure方法确保将其编写为客户端编码和读取并理解为故意模糊的异常。

GWT-RPC：对请求有效负载进行黑客攻击

2 个答案: