如何区分内部和外部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)
    );
  }

template.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标准看起来是不好的做法。

好的做法是创建对调用者不变的公共API。 API调用应集中于提供的REST请求正文和标题，以检查其有效性，可接受性和安全性。 实际上，许多API调用应按顺序完成，如“login” - > sessionToken - >“使用sessionToken调用API” - >“使用sessionToken注销”（令牌无效）。 在那种情况下，以某种方式附加到sessionToken的服务器上存储的重要数据（用户ID，角色，安全上下文等）。 注意：许多API架构师不建议在cookie中存储sessionToken，因为它可以简化CSRF攻击（如果没有提供其他对策）。

您和许多其他人想要的是拥有“私有”API来实现您的网站功能本身以及为您的客户提供“公共”API。 这是一个有点不同的故事。

您记录，发布（至少向客户）的公共API，承诺在​​很长一段时间内保持不变。

您可以随时更改私有API，并且可以以对您感觉舒适的方式进行设计。 但是，如果您的网站是实时的，任何人仍然可以扫描自己的流量并使用curl（或类似的东西）构建类似的请求。 但是，您可能会做一些技巧来使滥用者的生活变得更加困难，例如发布某种JavaScript计算的页面令牌，使用短期请求链等，但这并不是完全消除威胁。 因此，如果请求的所有数据都可以通过合法用户从页面和流量获得，则API无法继续“无人可以构造此类请求”。

简历：最好为客户提供公共API，为站点本身提供私有API，不要混用它们。