如何區分內部和外部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，不要混用它們。