.NET API 介面資料傳輸加密最佳實踐記錄示例

導讀	這篇文章主要介紹了.NET API 介面資料傳輸加密最佳實踐記錄,我們在做 Api 介面時，相信一定會有接觸到要給傳輸的請求 body 的內容進行加密傳輸。其目的就是為了防止一些敏感的內容直接被 UI 層檢視或篡改，需要的朋友可以參考下

我們在做 Api 介面時，相信一定會有接觸到要給傳輸的請求 body 的內容進行加密傳輸。其目的就是為了防止一些敏感的內容直接被 UI 層檢視或篡改。

其實粗略一想就能想到很多種方案，但是哪些方案是目前最適合我們專案的呢？

最先想到的應該就是硬編碼方式，就是哪個介面需要進行傳輸加密，那麼就針對該介面特殊處理：

public class SecurityApiController {
    ...
    public async TaskUpdateUser([FromBody] SecurityRequest request) {
        var requestBody = RsaHelper.Decrypt(privateKey, request.Content);
            var user = JsonHelper.Deserialize(requestBody);
        await UpdateUserAsync(user);
        return new Result(RsaHelper.Encrypt(publicKey, new{ Success=true}));
    }
}

這種方式好處是簡單明瞭，按需程式設計即可，不會對其它介面造成汙染。

一旦這種需求越來越多，我們就會寫大量如上的重複性程式碼；而對於前端而言也是如此，所以當我們需要傳輸加密乃是最基礎的需求時，上面硬編碼的方式就顯得很不合適了。

這個時候我們可以採用統一入口的方式來實現

回顧上面的硬編碼方式，其實每個介面處的加解密處理從 SRP 原則上理解，不應該是介面的職責。所以需要把這部分的程式碼移到一個單獨的方法，再加解密之後我們再把該請求排程到具體的介面。

這種方式其實有很多種實現方式，在這裡我先說一下我司其中一個 .NET4.5 的專案採取的方式。

其實就是額外提供了一個統一的入口，所有需要傳輸加密的需求都走這一個介面：如http://api.example.com/security

public class SecurityController {
    ...
    public async Task EntryPoint([FromBody] SecurityRequest request) {
        var requestBody = RsaHelper.Decrypt(privateKey, request.Content);
        var user = JsonHelper.Deserialize(requestBody);
        var obj = await DispathRouter(requestBody.Router, user);
            return new Result(RsaHelper.Encrypt(publicKey, obj));
    }
     
    public async Task DispathRouter(Router router, object body) {
        ...
        Type objectCon = typeof(BaseController);
            MethodInfo methInfo = objectCon.GetMethod(router.Name);
            var resp = (Task)methInfo.Invoke(null, body);
            return await resp;
    }
}

很明顯這是透過統一入口地址呼叫並配合反射來實現這種目的。

這種好處如前面所說，統一了呼叫入口，這樣提高了程式碼複用率，讓加解密不再是業務介面的一部分了。同樣，這種利用一些不好的點；比如用了反射效能會大打折扣。並且我們過度的進行統一了。我們看到這種方式只能將所有的介面方法都寫到 BaseController。所以我司專案的 Controller 部分，會看到大量如下的寫法：

// 檔案 UserController.cs
public partial class BaseController {
    ...
}
// 檔案 AccountController.cs 
public partial class BaseController {
 
}
// ...

這樣勢必就會導致一個明顯的問題，就是“程式碼爆炸”。這相當於將所有的業務邏輯全部灌輸到一個控制器中，剛開始寫的時候方便了，但是後期維護以及交接換人的時候閱讀程式碼是非常痛苦的一個過程。因為在不同的 Controller 檔案中勢必會重複初始化一些模組，而我們在引用方法的時候 IDE 每次都會顯示上千個方法，有時候還不得不檢視哪些方法名一樣或相近的具體意義。

針對上述程式碼爆炸的方式還有一種最佳化，就是將控制器的選擇開放給應用端，也就是將方法名和控制器名都作為請求引數暴露給前端，但是這樣會加大前端的開發心智負擔。

綜上所述我是非常不建議採用這種方式的。雖說是很古老的.Net4/4.5 的框架，但是我們還是有其它相對更優雅的實現方式。

其實我們熟悉了 .NETCore 下的 Middleware機制，我們會很容易的在 .NETCore 下實現如標題的這種需求：

// .NET Core 版本
public class SecuriryTransportMiddleware {
    private readonly RequestDelegate _next;
 
    public RequestCultureMiddleware(RequestDelegate next)
    {
        _next = next;
    }
     
    public async Task InvokeAsync(HttpContext context)
    {
        // request handle
        var encryptedBody = context.Request.Body;
        var encryptedContent = new StreamReader(encryptedBody).ReadToEnd();
        var decryptedBody = RsaHelper.Decrypt(privateKey, encryptedContent);
        var originBody = JsonHelper.Deserialize(decryptedBody);
         
        var json = JsonHelper.Serialize(dataSource);
        var requestContent = new StringContent(json, Encoding.UTF8, "application/json");
        stream = await requestContent.ReadAsStreamAsync();
        context.Request.Body = stream;
         
        await _next(context);
        // response handle
        var originContent = new StreamReader(context.Response.Body).ReadToEnd();
        var encryptedBody = RsaHelper.Encrypt(privateKey, originContent);
        var responseContent = new StringContent(json, Encoding.UTF8, "application/json");
        context.Response.Body = await responseContent.ReadAsStreamAsync();
        // 或者直接
        // await context.Response.WriteAsync(encryptedBody);
    }
}

為了方便描述，以上程式碼我省略了必要的校驗和異常錯誤處理

這樣有什麼好處呢？一個最明顯的好處就是解耦了加解密與真正業務需求。對真正的業務程式碼幾乎沒有侵略性。其實我認為業務開發能做到這裡其實就差不多了，還有其它需求都可以基於這個中介軟體進行擴充開發。

那麼在 .NET Framwork 沒有中介軟體怎麼辦呢？

其實在 .NET Framwork 框架下 IHttpModule 能和中介軟體一樣能做到這點：

public class SecurityTransportHttpModule : IHttpModule {
    ...
    public void Init(HttpApplication context) {
        ...
        context.BeginRequest += ContextBeginRequest;
        context.PostRequestHandlerExecute += ContextPostRequestHandlerExecute;
    }
     
    private void ContextBeginRequest(object sender, EventArgs e) {
        HttpContext context = ((HttpApplication)sender).Context;
        var encryptedBody = context.Request.Body;
        ...
        context.Request.Body = stream;
    }
     
    private void ContextPostRequestHandlerExecute(object sender, EventArgs e)
        {
            HttpContext context = ((HttpApplication)sender).Context;
            ...
            context.Response.Write(encryptedBody)
        }
}

為什麼之前提到這種方案就“差不多”了呢，實際上上面這種方式在某些場景下會顯得比較“累贅”。因為無論透過中介軟體和還是 IHttpModule 都會導致所有請求都會經過它，相當於增加了一個過濾器，如果這時候我要新增一個上傳檔案介面，那必然也會經過這個處理程式。說的更直接一點，如果碰到那些少數不需要加解密的介面請求那要怎麼辦呢？

其實上面可以進行擴充處理，比如對特定的請求進行過濾：

if(context.Request.Path.Contains("upload")) {
    return;
}

注意上述程式碼只是做個 demo 展示，真正還是需要透過如 context.GetRouterData() 獲取路由資料進行精準比對。

當類似於這種需求開始變多以後（吐槽：誰知道業務是怎麼發展的呢？）原來的中介軟體的“任務量”開始變得厚重了起來。到時候也會變得難以維護和閱讀。

這個時候就是我目前較為滿意的解決方案登場了，它就是模型繫結 ModelBinding。

回到需求的開端，不難發現，我們其實要是如何將前端加密後的請求體繫結到我們編寫的介面方法中。這裡面的過程很複雜，需要解析前端發起的請求，解密之後還要反序列化成目標介面需要的方法引數。而這個過程還要伴隨著引數校驗，如這個請求是否符合加密格式。而這個過程的一切都是模型繫結要解決的事。我們以 NETCore 版本為例子，講一下大概的流程；

模型繫結的過程其實就是將請求體的各個欄位於具體的 CLR 型別的欄位屬性進行一一匹配的過程。.NetCore 再程式啟動時會預設提供了一些內建的模型繫結器，並開放 IModelBinderProvider 介面允許使用者自定義模型繫結器。我們透過檢視 MvcCoreMvcOptionsSetup 就清楚看到框架為我們新增 18 個自帶的模型繫結器。以及如何呼叫的方式。

所以接下來我們很容易的可以一葫蘆畫瓢的照抄下來：

public class SecurityTransportModelBinder : IModelBinder {
    ...
    public async Task BindModelAsync(ModelBindingContext bindingContext)
    {
        if (bindingContext == null)
        {
            throw new ArgumentNullException(nameof(bindingContext));
        }
 
        try
        {
            var request = bindingContext.HttpContext.Request;
            var model = await JsonSerializer.DeserializeAsync(request.Body, new JsonSerializerOptions
            {
                PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
            });
            var decryptContent = RsaHelper.Decrypt(model.Info, privateKey);
            var activateModel = JsonSerializer.Deserialize(decryptContent, bindingContext.ModelMetadata.ModelType, new JsonSerializerOptions
            {
                PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
            });
            //重新包裝
            if (activateModel == null)
            {
                bindingContext.Result = ModelBindingResult.Failed();
            }
            else
            {
                bindingContext.Result = ModelBindingResult.Success(activateModel);
            }
        }
        catch (Exception exception)
        {
            bindingContext.ModelState.TryAddModelError(
                bindingContext.ModelName,
                exception,
                bindingContext.ModelMetadata);
        }
 
        _logger.DoneAttemptingToBindModel(bindingContext);
        //return Task.CompletedTask;
    }
}

抄了 ModelBinder 還不行，還要抄 ModelBinderProvider：

public class SecurityTransportModelBinderProvider : IModelBinderProvider
{
    public IModelBinder GetBinder(ModelBinderProviderContext context)
    {
        if (context == null)
        {
            throw new ArgumentNullException(nameof(context));
        }
 
        if (context.Metadata.IsComplexType && typeof(IApiEncrypt).IsAssignableFrom(context.Metadata.ModelType))
        {
            var loggerFactory = context.Services.GetRequiredService();
            var configuration = context.Services.GetRequiredService();
            return new SecurityTransportModelBinder(loggerFactory, configuration);
        }
 
        return null;
    }
}

這裡我做了一個方便我自己的擴充功能，就是顯示打了 IApiEncrypt 介面標籤的才會正常進行解析繫結。

剩下的就是在 ConfigureService 中新增進去即可：

services.AddControllers(options => {
    ...
    options.ModelBinderProviders.Insert(0, new SecurityTransportModelBinderProvider());
})

這樣實現過後，我們就能像使用 FromBody 那樣就能按需呼叫即可：

[HttpPost("security")]
public async TaskDemoDecrypt([ModelBinder(typeof(SecurityTransportModelBinder))] OriginBusinessRequest request)
{
    //啟用結果
    ...
    return await Task.FromResult(WriteSafeData(data, publicKey));
}

如果是預設處理加解密也是可以的，直接在對應的請求實體類打上 IApiEncrypt 標籤就會自動執行模型繫結

public class UserUpdateRequest: IApiEncrypt {
    public int UserId { get; set; }
    public string Phone { get; set; }
    public string Address { get; set; }
    ...
}

這種方案其實也還是有缺點的，從剛剛的使用來看就知道，模型繫結無法解決返回自動加密處理。所以我們不得不在每個介面處寫下如 WriteSafeData(data, publicKey) 這種顯式加密的程式碼。

最佳化的方式也很簡單，其實我們可以透過過濾器可以解決，這也是為什麼我要加 IApiEncrypt 的原因，因為有了這個就能確定知道這是一個安全傳輸的請求，進而進行特殊處理。

注意，這不是 .NET Core 獨有的特性，.Net Framework 也有模型繫結器

針對介面級傳輸加密這個需求，我們總共討論了四種實現方式。其實各有各的好處和缺點。

硬編碼方式適合只有特定需求的場景下是適合這種方案的。但是一旦這種需求成為一種規範或普遍場景時，這個方法就不合適了

統一入口適合制定了一種介面規範，所有加密的請求都走這一個介面。然後透過路由解析排程到不同的控制器。其實我講了我司在 .NET Framework 下采取的一種方案，好處時實現簡單，做到了程式碼複用，對業務程式碼進行了解耦。但缺點是用了反射成為了效能消耗點，並且當業務越來越多就會產生程式碼爆炸，成為了維護災難。

而中介軟體或 IHttpModule 方式就很好的解決這了這點。但同樣也不是使用所有場景，如對新增的不需要加密的介面要進行過濾處理等。

最後介紹了模型繫結這種方式，技能很方便的滿足大多數場景，也滿足個別列外的需求。但同樣也有缺點，就是無法針對介面響應體進行自動加密處理，所謂好事做到底，送佛送到西，這事只能算是做到一半吧。

其實我還想到了一種類似 Aop 的方案，那就是實現一個路由過濾器的功能，當請求進來，透過路由處理程式對請求體進行解密，然後重寫請求流。然後排程到對應的原始路由，最後在響應的時候再加密重寫一次。不過查閱了一番資料，並沒有收穫。

原文來自：