同事都說有SQL注入風(fēng)險(xiǎn)，我非說沒有
前言
現(xiàn)在的項(xiàng)目，在操作數(shù)據(jù)庫(kù)的時(shí)候，我都喜歡用ORM框架，其中EF是一直以來(lái)用的比較多的；EF 的封裝的確讓小伙伴一心注重業(yè)務(wù)邏輯就行了，不用過多的關(guān)注操作數(shù)據(jù)庫(kù)的具體細(xì)節(jié)。但是在某些場(chǎng)景會(huì)選擇執(zhí)行SQL語(yǔ)句，比如一些復(fù)雜的插入或報(bào)表查詢等，其實(shí)不管用什么方式執(zhí)行SQL語(yǔ)句，防止SQL注入是必須的，所以就有了下面的討論。
正文
1. 先來(lái)個(gè)EF Core執(zhí)行SQL演示
1.1 準(zhǔn)備一個(gè)EF Core的項(xiàng)目
關(guān)于EF Core在項(xiàng)目中的使用，之前分享了一篇很詳細(xì)的文章，這里就不重復(fù)說了，詳細(xì)內(nèi)容請(qǐng)看這里《跟我一起學(xué).NetCore之EF Core 實(shí)戰(zhàn)入門，一看就會(huì)》
1.2 執(zhí)行原生SQL
前提，已經(jīng)生成數(shù)據(jù)庫(kù)，并且有對(duì)應(yīng)的表(以下只是模擬演示，并不是真實(shí)場(chǎng)景)：
在操作數(shù)據(jù)庫(kù)時(shí)，執(zhí)行如下SQL：
有很多小伙伴看到這時(shí)，應(yīng)該也會(huì)懷疑這里會(huì)有SQL注入的風(fēng)險(xiǎn)，因?yàn)檫@里的SQL語(yǔ)句看上去就是一個(gè)拼接的字符串，只是用了插值運(yùn)算符的形式，好像沒什么特別。
1.2 打印日志查看真正執(zhí)行的SQL
表面看上去的確會(huì)有風(fēng)險(xiǎn)，既然說沒有，那就拿出證據(jù)證明，直接把EF執(zhí)行過程的日志打印出來(lái)，看看真正執(zhí)行的SQL語(yǔ)句是什么樣子；
EF Core好像在5.0之后就提供了一個(gè)便捷的配置，可以方便的打印對(duì)應(yīng)的SQL記錄，所以先來(lái)開啟日志打印功能：
開啟日志之后，執(zhí)行一下程序，看看執(zhí)行的真正SQL是什么樣的，控制臺(tái)可以看到如下日志：
可以看到，SQL語(yǔ)句已經(jīng)參數(shù)化了，所以是沒有注入風(fēng)險(xiǎn)的。那到底是為什么呢？因?yàn)镋xecuteSqlInterpolatedAsync中的SQL語(yǔ)句參數(shù)的類型是FormattableString，EF Core內(nèi)部根據(jù)FormattableString結(jié)果，將對(duì)應(yīng)的字符串生成參數(shù)化的SQL語(yǔ)句。
2. FormattableString有點(diǎn)料
為了看看FormattableString的作用，建一個(gè)簡(jiǎn)單的控制臺(tái)程序，看看情況，如下：
可以看到，F(xiàn)ormattableString中包含拼接的字符串和對(duì)應(yīng)的參數(shù)，拿到這些結(jié)果，就可以構(gòu)造成想要的結(jié)果了。
2.1 var使用時(shí)還是要稍微注意一下
之前一個(gè)項(xiàng)目，因?yàn)関ar的使用，線上出現(xiàn)一個(gè)bug，挨個(gè)看了代碼感覺都沒問題，而且開發(fā)和測(cè)試環(huán)境正常，但在線上就是有問題，最后通過模擬線上數(shù)據(jù)調(diào)試才搞定。大概使用如下：
之所以開發(fā)和測(cè)試環(huán)境沒有問題，是沒有模擬全線上環(huán)境，所以讓這個(gè)bug漏掉了；對(duì)于開發(fā)來(lái)說，var用起來(lái)的確很是方便，但對(duì)于類似于上面的場(chǎng)景，使用具體的類型會(huì)避免一些不必要的Bug；
代碼比較簡(jiǎn)單，就不提交了~~~
總結(jié)
在開發(fā)過程中，稍微一個(gè)小細(xì)節(jié)的改動(dòng)，可能效果就不一樣；同樣，一個(gè)小細(xì)節(jié)的忽視，就可能帶來(lái)一個(gè)很不好排查的Bug，所以小伙伴開發(fā)過程中，一定要注意哦！?。?/p>