文章詳情頁

.NET API 接口數(shù)據(jù)傳輸加密最佳實踐記錄

瀏覽：131日期：2022-06-09 11:07:44

硬編碼方式

最先想到的應(yīng)該就是硬編碼方式，就是哪個接口需要進行傳輸加密，那么就針對該接口特殊處理：

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

這種方式好處是簡單明了，按需編程即可，不會對其它接口造成污染。

一旦這種需求越來越多，我們就會寫大量如上的重復(fù)性代碼；而對于前端而言也是如此，所以當(dāng)我們需要傳輸加密乃是最基礎(chǔ)的需求時，上面硬編碼的方式就顯得很不合適了。

這個時候我們可以采用統(tǒng)一入口的方式來實現(xiàn)

統(tǒng)一入口

回顧上面的硬編碼方式，其實每個接口處的加解密處理從 SRP 原則上理解，不應(yīng)該是接口的職責(zé)。所以需要把這部分的代碼移到一個單獨的方法，再加解密之后我們再把該請求調(diào)度到具體的接口。

這種方式其實有很多種實現(xiàn)方式，在這里我先說一下我司其中一個 .NET4.5 的項目采取的方式。

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

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

很明顯這是通過統(tǒng)一入口地址調(diào)用并配合反射來實現(xiàn)這種目的。

這種好處如前面所說，統(tǒng)一了調(diào)用入口，這樣提高了代碼復(fù)用率，讓加解密不再是業(yè)務(wù)接口的一部分了。同樣，這種利用一些不好的點；比如用了反射性能會大打折扣。并且我們過度的進行統(tǒng)一了。我們看到這種方式只能將所有的接口方法都寫到 BaseController。所以我司項目的 Controller 部分，會看到大量如下的寫法：

// 文件 UserController.cs
public partial class BaseController {
	...
}
// 文件 AccountController.cs 
public partial class BaseController {

}
// ...

這樣勢必就會導(dǎo)致一個明顯的問題，就是“代碼爆炸”。這相當(dāng)于將所有的業(yè)務(wù)邏輯全部灌輸?shù)揭粋€控制器中，剛開始寫的時候方便了，但是后期維護以及交接換人的時候閱讀代碼是非常痛苦的一個過程。因為在不同的 Controller 文件中勢必會重復(fù)初始化一些模塊，而我們在引用方法的時候 IDE 每次都會顯示上千個方法，有時候還不得不查看哪些方法名一樣或相近的具體意義。

針對上述代碼爆炸的方式還有一種優(yōu)化，就是將控制器的選擇開放給應(yīng)用端，也就是將方法名和控制器名都作為請求參數(shù)暴露給前端，但是這樣會加大前端的開發(fā)心智負(fù)擔(dān)。

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

中間件

其實我們熟悉了 .NETCore 下的 Middleware機制，我們會很容易的在 .NETCore 下實現(xiàn)如標(biāo)題的這種需求：

// .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<object>(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);
    }
}

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

這樣有什么好處呢？一個最明顯的好處就是解耦了加解密與真正業(yè)務(wù)需求。對真正的業(yè)務(wù)代碼幾乎沒有侵略性。其實我認(rèn)為業(yè)務(wù)開發(fā)能做到這里其實就差不多了，還有其它需求都可以基于這個中間件進行拓展開發(fā)。

那么在 .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 都會導(dǎo)致所有請求都會經(jīng)過它，相當(dāng)于增加了一個過濾器，如果這時候我要新增一個上傳文件接口，那必然也會經(jīng)過這個處理程序。說的更直接一點，如果碰到那些少數(shù)不需要加解密的接口請求那要怎么辦呢？

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

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

注意上述代碼只是做個 demo 展示，真正還是需要通過如 context.GetRouterData() 獲取路由數(shù)據(jù)進行精準(zhǔn)比對。

當(dāng)類似于這種需求開始變多以后（吐槽：誰知道業(yè)務(wù)是怎么發(fā)展的呢？）原來的中間件的“任務(wù)量”開始變得厚重了起來。到時候也會變得難以維護和閱讀。

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

模型綁定

回到需求的開端，不難發(fā)現(xiàn)，我們其實要是如何將前端加密后的請求體綁定到我們編寫的接口方法中。這里面的過程很復(fù)雜，需要解析前端發(fā)起的請求，解密之后還要反序列化成目標(biāo)接口需要的方法參數(shù)。而這個過程還要伴隨著參數(shù)校驗，如這個請求是否符合加密格式。而這個過程的一切都是模型綁定要解決的事。我們以 NETCore 版本為例子，講一下大概的流程；

模型綁定的過程其實就是將請求體的各個字段于具體的 CLR 類型的字段屬性進行一一匹配的過程。.NetCore 再程序啟動時會默認(rèn)提供了一些內(nèi)置的模型綁定器，并開放 IModelBinderProvider 接口允許用戶自定義模型綁定器。我們通過查看 MvcCoreMvcOptionsSetup 就清楚看到框架為我們添加 18 個自帶的模型綁定器。以及如何調(diào)用的方式。

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

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<SafeDataWrapper>(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<ILoggerFactory>();
    var configuration = context.Services.GetRequiredService<IConfiguration>();
    return new SecurityTransportModelBinder(loggerFactory, configuration);
}

return null;
    }
}

這里我做了一個方便我自己的拓展功能，就是顯示打了 IApiEncrypt 接口標(biāo)簽的才會正常進行解析綁定。

剩下的就是在 ConfigureService 中添加進去即可：

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

這樣實現(xiàn)過后，我們就能像使用 FromBody 那樣就能按需調(diào)用即可：

[HttpPost("security")]
public async Task<ResultDto> DemoDecrypt([ModelBinder(typeof(SecurityTransportModelBinder))] OriginBusinessRequest request)
{
    //激活結(jié)果
	...
    return await Task.FromResult(WriteSafeData(data, publicKey));
}

如果是默認(rèn)處理加解密也是可以的，直接在對應(yīng)的請求實體類打上 IApiEncrypt 標(biāo)簽就會自動執(zhí)行模型綁定

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

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

優(yōu)化的方式也很簡單，其實我們可以通過過濾器可以解決，這也是為什么我要加 IApiEncrypt 的原因，因為有了這個就能確定知道這是一個安全傳輸?shù)恼埱螅M而進行特殊處理。

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

總結(jié)

針對接口級傳輸加密這個需求，我們總共討論了四種實現(xiàn)方式。其實各有各的好處和缺點。

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

統(tǒng)一入口適合制定了一種接口規(guī)范，所有加密的請求都走這一個接口。然后通過路由解析調(diào)度到不同的控制器。其實我講了我司在 .NET Framework 下采取的一種方案，好處時實現(xiàn)簡單，做到了代碼復(fù)用，對業(yè)務(wù)代碼進行了解耦。但缺點是用了反射成為了性能消耗點，并且當(dāng)業(yè)務(wù)越來越多就會產(chǎn)生代碼爆炸，成為了維護災(zāi)難。

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

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

其實我還想到了一種類似 Aop 的方案，那就是實現(xiàn)一個路由過濾器的功能，當(dāng)請求進來，通過路由處理程序?qū)φ埱篌w進行解密，然后重寫請求流。然后調(diào)度到對應(yīng)的原始路由，最后在響應(yīng)的時候再加密重寫一次。不過查閱了一番資料，并沒有收獲。

參考資料

https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.modelbinding.imodelbinderprovider?view=aspnetcore-7.0
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/write?view=aspnetcore-6.0
https://www.stevejgordon.co.uk/html-encode-string-aspnet-core-model-binding

到此這篇關(guān)于.NET API 接口數(shù)據(jù)傳輸加密最佳實踐記錄的文章就介紹到這了,更多相關(guān).net api接口數(shù)據(jù)傳輸加密內(nèi)容請搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持！

ASP.NET

上一條：.Net Core和RabbitMQ限制循環(huán)消費的方法下一條：.NET6打包部署到Windows Service的全過程

排行榜

					
					使用Docker的NFS-Ganesha鏡像搭建nfs服務(wù)器的詳細(xì)過程
Java之JSP教程九大內(nèi)置對象詳解(中篇)
idea導(dǎo)入maven項目的方法
jsp實現(xiàn)剪子石頭布小游戲
Django使用HTTP協(xié)議向服務(wù)器傳參方式小結(jié)
ASP.NET MVC使用typeahead.js實現(xiàn)輸入智能提示功能
基于canvas實現(xiàn)手寫簽名（vue）
最新IntelliJ IDEA 2020版本的安裝教程詳解
PHP結(jié)合vue導(dǎo)出excel出現(xiàn)亂碼的解決方法分享
Spring Data JPA使用JPQL與原生SQL進行查詢的操作
.Net core 的熱插拔機制的深入探索及卸載問題求救指南
				