如何区分内部和外部 REST API 请求？

Question

在服务器上，有什么方法可以区分内部和外部 REST API 请求吗？

为什么？

我想区分这两个来源的原因是，根据受访者给出的建议，我可能想要返回不同的数据集，具体取决于谁试图发出请求。

概括

我对内部的定义可能不正确。在这种情况下，“内部”是指从与处理该请求的页面相同的域的 XHTTP 请求发出的请求。

外部调用可能是用户从另一个域创建 Curl 请求。

例如：

http.service.ts

内部角度 6 请求

fetchLogin(formData: any): Observable<any> {
    let req = null;
    let headers = null;
    headers = {
      reportProgress: false,
      headers: new HttpHeaders({
        'email': formData['email'],
        'password': formData['password']
      })
    };
    req = new HttpRequest('POST', this.restApiUrl + this.restApiUrlEndpoint + '/oauth/', '', headers);
    return this.http.request(req)
    .map( (data) => {
      return 'body' in data ? data['body'] : null;
    })
    .pipe(
      catchError(this.handleError)
    );
  }

模板.cfm

外部冷聚变请求

<cfset httpUrl = request.restApiUrl & request.restApiUrlEndpoint & "/oauth/">

<cfhttp url="#httpUrl#" method="post" result="result" timeout="30">
  <cfhttpparam type="header" name="email" value="foo@bar.com" />
  <cfhttpparam type="header" name="password" value="foo" />
</cfhttp>

请理解，我简化了这两个代码片段以保持清晰。

当请求到达服务器时，我如何判断哪个请求是通过 XHTTP 发送的，哪个请求是通过 CFHTTP [Curl] 发送的？

我正在使用 Taffy.io REST API 框架，因此这里有一个简化的方法，位于“资源”CFC 内，我可以用它来处理请求：

资源/oauthMember.cfc

<cfcomponent extends="taffy.core.resource" taffy_uri="/oauth">

<cffunction name="post">
  <cfset var local = StructNew()>
  <cfset local.data['email'] = "">
  <cfset local.data['password'] = "">
  <cfset local.requestBody = getHttpRequestData().headers>
  <cftry>
    <cfset local.data['email'] = Trim(local.requestBody['email'])>
    <cfset local.data['password'] = Trim(local.requestBody['password'])>
    <cfcatch>
    </cfcatch>
  </cftry>
  ...processing code
  <cfreturn representationOf(local.data) />
</cffunction>

</cfcomponent>

向其中一个调用添加额外的标头是不可行的，因为这很容易被欺骗。

有任何想法吗？

环境

Windows 2008R2 Lucee 4.5 IIS7+

Answer 1

简而言之，您不能信任公共 REST API 数据中传入的任何请求。请求内容/标头中的任何内容都可以通过curl 或自定义程序构建。如果您的 Web 服务器进行了相应配置并且可以从套接字本身直接访问源连接地址，那么您可能对套接字源 IP 地址有一定的信任。如今这种情况很少见，因为通常 Web 服务器现在位于负载均衡器、具有 NAT 隧道的防火墙等后面。但即使在这种情况下，源 IP 地址也可能仅用于某种​​白名单。此外，当您的应用程序可能需要负载均衡器进行扩展时，今天具有此类访问权限的服务器明天可能会失去这种访问权限。另请注意，用户可能在源路径上有 HTTP 代理。因此，使用源 IP 作为 API 标准看起来是一种不好的做法。

\n\n

Good practice is to create public API that is invariant to caller. API calls should concentrate on REST request body and headers provided to check for theirs validity, acceptability and security. Indeed, many API calls should be done in sequence like \xe2\x80\x9clogin\xe2\x80\x9d -> sessionToken -> \xe2\x80\x9cAPI calls with sessionToken\xe2\x80\x9d -> \xe2\x80\x9clogout with sessionToken\xe2\x80\x9d (token invalidated). In that case important data (user Id, role, security context, etc) stored on server attached to sessionToken somehow. Note: many API architects do not recommend to store sessionToken in cookie, as it may simplify CSRF attacks (if no other countermeasures provided).

\n\n

What you and probably many others want is to have \xe2\x80\x9cprivate\xe2\x80\x9d API to implement your web site functionality itself and \xe2\x80\x9cpublic\xe2\x80\x9d API to your customers. That\xe2\x80\x99s a bit different story.

\n\n

Public API you document, publish (at least to customers), promise to keep unchanged during long period of time.

\n\n

Private API you may change at any moment and you may design it in a way that is comfortable to you. But if your site is live, anyone can still scan his own traffic and construct similar requests with curl (or something alike). You may, however, do some tricks to made abuser\xe2\x80\x99s life harder, like issue some kind of JavaScript-calculated page tokens, use short-lived request chains etc, but this is not eliminated threat completely. So API cannot relay on that \xe2\x80\x9cnobody can construct such request\xe2\x80\x9d if all data for the request may be obtained from page and traffic by legitimate user.

\n\n

Resume:\nBetter to have public API for customers and private API to site itself and do not mix them.

\n