：WebUploader結(jié)合AES+RSA實現(xiàn)文件加密上傳)
1. 項目概述與技術(shù)選型思考1.1 為什么還在vue2里選百度WebUploader先說結(jié)論在2024年還在維護(hù)vue2項目說明這是個存量系統(tǒng)大概率是企業(yè)后臺、政務(wù)平臺或者金融類管理系統(tǒng)。這類系統(tǒng)最大的特點就是不能隨便動底層架構(gòu)但安全要求又逐年升級所以“老框架老插件新加密要求”的組合特別典型。百度WebUploader這個插件很多人一聽就覺得過時了。但坦白講它在企業(yè)級場景里依然有不可替代的價值分片上傳、斷點續(xù)傳、并發(fā)限制、MD5秒傳這些能力現(xiàn)在很多前端上傳組件要折騰半天才能實現(xiàn)WebUploader開箱即用。尤其在內(nèi)網(wǎng)環(huán)境部署的系統(tǒng)里性能穩(wěn)定、兼容性好還不需要額外依賴這幾點到現(xiàn)在依然是硬需求。我這次接手的項目就是個典型場景vue2.6 element-ui WebUploader的存量后臺需要把附件上傳模塊從裸HTTP明文傳輸升級為加密存儲。需求拆開看其實有兩層前端在文件上傳前先做加密不能明文走網(wǎng)絡(luò)后端存儲時保留密文防止拖庫后文件內(nèi)容直接泄露1.2 加密方案選型的核心矛盾最初產(chǎn)品提需求時人員想的是“上傳前用密碼加密一下就行”但真正落地要考慮的事情就多了。核心矛盾在于文件體積不同加密策略必須分層一套方案打天下是不現(xiàn)實的。我測試過幾種路線單純用JSEncryptRSA加全部文件內(nèi)容幾百KB的小文件還行上MB就卡死。RSA是非對稱加密密鑰長、運算重不適合大量數(shù)據(jù)。單純用CryptoJS的AES加速度沒問題但密鑰寫死在前端等于脫褲子放屁抓包拿到密鑰就能解密。AES RSA混合AES負(fù)責(zé)加密文件內(nèi)容RSA負(fù)責(zé)把AES的密鑰加密后傳給后端。既解決性能問題也解決密鑰分發(fā)問題。這是主流方案。最后定的是AES-256 RSA-2048的混合加密。AES用CBC模式PKCS7填充密鑰隨機生成RSA公鑰來自后端接口私鑰永遠(yuǎn)不出后端。這樣前端就算被完全逆向也拿不到解密能力。接下來我先說封裝細(xì)節(jié)然后給完整代碼再講全鏈路聯(lián)調(diào)和坑。這個順序能幫你先建立整體認(rèn)知再抄作業(yè)的時候就不容易抄歪。2. 整體設(shè)計與技術(shù)鏈路拆解2.1 前端加密的完整鏈路整個加密上傳的流程我畫了個流程圖在腦子里文字描述是這樣的用戶選擇文件WebUploader接管文件隊列上傳前觸發(fā)before-send-file鉤子這里做加密每個文件隨機生成一個AES密鑰32字節(jié)用CryptoJS的AES-CBC加密文件二進(jìn)制內(nèi)容得到密文用后端下發(fā)的RSA公鑰加密AES密鑰得到密鑰密文把密文文件和密鑰密文一起post到后端后端收到后用RSA私鑰解出AES密鑰再用AES密鑰解文件內(nèi)容按業(yè)務(wù)需要存儲這個鏈路里有個很容易被忽略的關(guān)鍵點不是所有場景都需要后端解出明文再存儲。如果需求是“后端只存密文永不讀明文”那后端不需要解密只需要把密文和密鑰分開存查詢時把密文交給有權(quán)限的前端自行解密。但這個項目的要求是“存儲時加密使用時可控”所以我讓后端解密后以密文形式入庫只有業(yè)務(wù)層通過接口訪問時才在內(nèi)存中臨時解密。這樣數(shù)據(jù)庫被拖了也只是密文。2.2 為什么要AES和RSA配合用生活類比來說AES像一把房間鑰匙加密解密都快適合處理大件行李但房間鑰匙不能直接交給別人萬一被復(fù)制就完了。RSA像個保險箱慢但安全適合送“房間鑰匙”這份小物件。具體到我們的鏈路AES密鑰是隨機生成的每次上傳都不同即使這次被破解也影響不了歷史文件RSA公鑰加密AES密鑰保證只有持RSA私鑰的后端才能取出AES密鑰網(wǎng)絡(luò)抓包只能看到一堆無意義的base64字符文件內(nèi)容加密后再進(jìn)行Base64編碼傳輸這個過程繞開了WebUploader默認(rèn)的FormData裸傳行為可以在過程中插入自定義校驗邏輯2.3 WebUploader與vue2生命周期的綁定方式百度WebUploader原生是基于jQuery的但vue2項目里引入它要處理兩個問題WebUploader實例的創(chuàng)建和銷毀要和組件生命周期保持一致WebUploader內(nèi)部操作的是真實DOMpicker按鈕需要避開vue的虛擬DOM管理我的做法是把上傳封裝成一個獨立的Uploader.vue組件在使用它的父組件里傳入上傳參數(shù)WebUploader實例在mounted中創(chuàng)建在beforeDestroy中手動銷毀。這樣既隔離了生命周期又能讓W(xué)ebUploader和vue2的數(shù)據(jù)流通過props和$emit對接。具體來說封裝的好處有三點如果項目里有多個頁面需要上傳文件不用重復(fù)初始化WebUploader傳不同的配置就行WebUploader實例的清理邏輯destroy、解綁事件集中在組件內(nèi)部不會因為頁面切換導(dǎo)致內(nèi)存泄漏加密邏輯CryptoJS相關(guān)只在這個組件里被引用一旦出問題可以快速定位3. 核心細(xì)節(jié)解析與工具選型3.1 依賴引入的細(xì)節(jié)控制項目用的依賴版本很關(guān)鍵直接貼出來vue2.6.14webuploader0.1.9直接npm安裝或者用官方dist文件也可以crypto-js4.1.1jsencrypt3.3.2這里提個坑WebUploader在npm上的包名叫webuploader但安裝之后不能直接import它需要掛window。在vue2 CLI項目里我是在index.html里通過script標(biāo)簽引的CDN或本地文件這樣能直接訪問window.WebUploader避免webpack打包CommonJS時出現(xiàn)“WebUploader is not defined”的錯誤。CryptoJS的引入方式import CryptoJS from crypto-js這個庫是純JavaScript實現(xiàn)的不管在瀏覽器還是webpack環(huán)境都穩(wěn)。JSEncrypt也一樣import JSEncrypt from jsencrypt需要額外注意一點CryptoJS處理中文文件名時直接encrypt會報錯或亂碼。這是因為CryptoJS默認(rèn)把字符串按UTF-8編碼處理而文件名有時候編碼方式不同。我是在加密前統(tǒng)一將文件名encodeURIComponent轉(zhuǎn)了一下加密后拿到字節(jié)數(shù)組再拼接然后在FileName字段中單獨加密傳輸避免文件名亂碼的問題。3.2 加密參數(shù)配置的“為什么”先看核心加密參數(shù)配置const AESKey CryptoJS.lib.WordArray.random(32) // 32字節(jié) 256位 const AESIV CryptoJS.lib.WordArray.random(16) // 16字節(jié) 128位為什么要隨機生成AESIV因為CBC模式下相同的明文和相同的密鑰如果IV相同產(chǎn)生的密文也是相同的。攻擊者可以從“相同密文”推斷出“相同明文”的信息這叫做確定性加密漏洞。每次隨機IV即使同一個文件上傳了兩次密文也完全不一樣這就增加了破解難度。CBC模式和PBKDF2相關(guān)的參數(shù)我也給一下推薦值密鑰長度256位32字節(jié)IV長度128位16字節(jié)填充PKCS7CryptoJS默認(rèn)模式CBC編碼Base64CryptoJS在代碼里通過這種方式設(shè)置const encrypted CryptoJS.AES.encrypt( CryptoJS.enc.Utf8.parse(plainText), AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 } )3.3 文件內(nèi)容加密的兩種姿勢WebUploader在before-send-file鉤子里能拿到file對象但拿到的file是WebUploader包裝后的對象。加密時有兩種處理方式第一種通過FileReader把file讀取為ArrayBuffer然后轉(zhuǎn)成WordArray交給CryptoJS處理const reader new FileReader() reader.onload function(e) { const arrayBuffer e.target.result const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encrypted CryptoJS.AES.encrypt(wordArray, AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) // 后續(xù)將 encrypted.toString() 作為上傳內(nèi)容 } reader.readAsArrayBuffer(file)這種方式適合小文件和中等文件因為它是把整個文件讀進(jìn)內(nèi)存再加密文件太大的話前端會有內(nèi)存壓力。第二種如果文件超大比如視頻、壓縮包WebUploader本身支持分片上傳但分片加密會引入“每個分片需要獨立IV和密鑰”的復(fù)雜度。這個項目里我暫時沒做分片級加密因為實際業(yè)務(wù)上傳的文件平均都在1MB以內(nèi)ArrayBuffer方式完全能扛住。如果你接手的是要傳大片視頻的項目我給個建議每個分片用相同的密鑰但每個分片隨機生成IV傳輸時把IV和分片密文一起發(fā)給后端后端按分片索引依次解密后拼接。這樣能把“加密”和“斷點續(xù)傳”兩個需求同時滿足分片加密的代碼量其實只多幾十行。3.4 非對稱加密保護(hù)和字段封裝生成了AES密鑰之后用JSEncrypt做RSA加密const encryptor new JSEncrypt() encryptor.setPublicKey(publicKey) // 后端下發(fā)的RSA公鑰 const encryptedKey encryptor.encrypt(AESKey.toString(CryptoJS.enc.Base64))注意這里加密的對象是Base64編碼后的AESKey字符串。AESKey是WordArray對象直接傳給JSEncrypt會出問題先轉(zhuǎn)成Base64字符串是穩(wěn)妥的。上傳時把下面幾個字段封裝成一個JSON對象fileNameencodeURIComponent后的原始文件名encryptedKeyRSA加密后的AES密鑰Base64encryptedIVAES的IV這個我直接拼接在密文頭部或者單獨字段看后端解析習(xí)慣contentAES加密后的文件內(nèi)容Base64timestamp時間戳可以防止重放攻擊后端可選校驗這段JSON用一個自定義header傳給后端或者作為FormData的一個字段。我在實際項目里用的是FormData方式因為后端已經(jīng)有一套MultipartFile接收邏輯直接多加了幾個字段改動量小。這里有個實戰(zhàn)技巧如果content特別大比如10MB不要直接把整個JSON塞進(jìn)FormData的普通字段里而是把content作為單獨的文件字段其他信息放在普通字段。這樣后端拿到MultipartFile的時候就是已經(jīng)加密的密文文件存儲邏輯不需要改動太多。我項目里就是這么處理的把“加密后的內(nèi)容”重新包裝成一個Blob文件讓W(xué)ebUploader上傳這個Blob文件。4. 實操過程與完整實現(xiàn)4.1 后端下發(fā)RSA公鑰的接口約定第一步需要后端提供一個公鑰接口。這個接口不涉及敏感操作可以設(shè)計為公開接口返回格式如下{ code: 0, data: { publicKey: -----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... } }在vue2項目的api模塊里加一個方法// api/upload.js import request from /utils/request export function getRsaPublicKey() { return request({ url: /api/system/public-key, method: get }) }這里的request就是axios封裝實例不用改底層邏輯正常調(diào)用就行。4.2 完整Uploader.vue組件代碼下面是這個項目的核心組件我按實際代碼精簡后給出。先看完整結(jié)構(gòu)再逐段解釋。template div classuploader-container div iduploader-picker classuploader-picker選擇文件/div div iduploader-list classuploader-list/div /div /template script import CryptoJS from crypto-js import JSEncrypt from jsencrypt import { getRsaPublicKey } from /api/upload export default { name: EncryptUploader, props: { accept: { type: String, default: */* }, maxSize: { type: Number, default: 20 * 1024 * 1024 }, uploadUrl: { type: String, default: /api/upload } }, data() { return { uploader: null, rsaPublicKey: } }, async mounted() { const res await getRsaPublicKey() this.rsaPublicKey res.data.publicKey this.initUploader() }, methods: { initUploader() { const _this this this.uploader window.WebUploader.create({ pick: { id: #uploader-picker, multiple: false }, accept: { title: Files, extensions: this.accept }, server: this.uploadUrl, fileVal: file, auto: false, chunked: false, duplicate: true, resize: false, compress: false, formData: { // 這里不寫死業(yè)務(wù)字段因為要動態(tài)放入加密數(shù)據(jù) } }) this.uploader.on(before-send-file, function(file) { return _this.handleBeforeSendFile(file) }) this.uploader.on(uploadSuccess, function(file, response) { _this.$emit(upload-success, file, response) }) this.uploader.on(uploadError, function(file, reason) { _this.$emit(upload-error, file, reason) }) this.uploader.on(error, function(type) { if (type Q_EXCEED_SIZE_LIMIT) { _this.$message.error(文件大小超出限制) } _this.$emit(upload-type-error, type) }) this.uploader.on(uploadComplete, function(file) { _this.$emit(upload-complete, file) }) }, handleBeforeSendFile(file) { // 返回一個PromiseWebUploader會等待它resolve后再繼續(xù) return new Promise((resolve, reject) { const reader new FileReader() reader.onload (event) { try { const arrayBuffer event.target.result const result this.encryptFile(arrayBuffer, file.name) // WebUploader通過file對象的一個擴(kuò)展屬性把加密后的內(nèi)容傳出去 file.encryptedBlob new Blob([result.content], { type: application/octet-stream }) file.encryptedFileName result.encryptedFileName file.encryptedKey result.encryptedKey file.encryptedIv result.encryptedIv file.timestamp result.timestamp this.uploader.options.server this.uploadUrl // 關(guān)鍵替換WebUploader內(nèi)部的上傳文件數(shù)據(jù) this.overrideUploadMethod(file, result) resolve() } catch (e) { reject(e) } } reader.onerror () { reject(new Error(讀取文件失敗)) } reader.readAsArrayBuffer(file.source) }) }, encryptFile(arrayBuffer, fileName) { // 1. 生成AES密鑰和IV const aesKey CryptoJS.lib.WordArray.random(32) const aesIv CryptoJS.lib.WordArray.random(16) // 2. 用AES加密文件內(nèi)容 const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encryptedContent CryptoJS.AES.encrypt(wordArray, aesKey, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString() // 3. 用RSA公鑰加密AES密鑰 const encryptor new JSEncrypt() encryptor.setPublicKey(this.rsaPublicKey) const encryptedKey encryptor.encrypt(aesKey.toString(CryptoJS.enc.Base64)) const encryptedIv encryptor.encrypt(aesIv.toString(CryptoJS.enc.Base64)) // 4. 文件名也加密 const encryptedFileName encryptor.encrypt(encodeURIComponent(fileName)) return { content: encryptedContent, encryptedKey, encryptedIv, encryptedFileName, timestamp: Date.now() } }, overrideUploadMethod(file, encryptResult) { // 這里用比較“偏門”但穩(wěn)定有效的方式 // 直接操作WebUploader內(nèi)部Hooks替換上傳時的FormData const me this.uploader const oldSend me.uploader.options.server // 在before-send-file的Promise resolve之后修改file的上傳數(shù)據(jù) file.formData { encryptedKey: encryptResult.encryptedKey, encryptedIv: encryptResult.encryptedIv, encryptedFileName: encryptResult.encryptedFileName, timestamp: encryptResult.timestamp } // WebUploader把file.formData合并進(jìn)上傳請求 // 同時我們把file.source修改成加密后的Blob file.source file.encryptedBlob }, submit() { if (this.uploader) { this.uploader.upload() } } }, beforeDestroy() { if (this.uploader) { this.uploader.destroy() this.uploader null } } } /script4.3 代碼里幾個隱蔽但關(guān)鍵的點這份代碼看起來邏輯不復(fù)雜但真正運行起來會踩一些隱蔽的坑我逐一說。第一個坑WebUploader默認(rèn)會把file.source作為上傳文件但上傳時FormData里的文件名、文件內(nèi)容都來自file.source。我直接把file.source file.encryptedBlob替換掉同時把file.name改成file.encryptedFileName對應(yīng)的值。這樣上傳請求發(fā)出去時后端收到的就是密文內(nèi)容和密文文件名。但WebUploader在before-send-file鉤子執(zhí)行完后內(nèi)部會重新讀取file.source的size等屬性。如果你把Blob文件替換了但沒更新file.size后續(xù)校驗可能會報錯。我在實際項目里加了一行file.size file.encryptedBlob.size這行不加的話WebUploader會出現(xiàn)“上傳文件為空”或者進(jìn)度條不動的問題。很多人在這里卡了很久其實就這么簡單。第二個坑Promise.resolve后WebUploader會繼續(xù)流程但沒有一個官方API讓你“再改一遍上傳參數(shù)”。用file.formData把extra字段帶過去是我嘗試出來的方式。WebUploader官方文檔里提到“如果要附加參數(shù)可以在uploader.option(formData)里配置”但那是對所有文件統(tǒng)一的。要針對單個文件動態(tài)附加就得在file對象上掛formData屬性內(nèi)部request方法會合并。我后來翻源碼確認(rèn)了這一點在webuploader.js的Request方法里確實有合并file.formData的邏輯。所以這個方法不是hack是官方預(yù)留的口子。第三個坑加密后的Base64內(nèi)容會比原始文件大不少Base64編碼膨脹約33%如果你在業(yè)務(wù)里對上傳文件大小做了限制加解密后校驗的是“加密后大小”要在組件里相應(yīng)地調(diào)整校驗上限。我在props里專門加了一個enableEncryptSizeLimit的配置默認(rèn)不限制如果后端限制的話用加密前原始大小去判斷。第四個坑CryptoJS處理ArrayBuffer時有個字節(jié)序問題。CryptoJS.lib.WordArray.create(arrayBuffer)時如果是ArrayBuffer它會按大端序讀取。但ArrayBuffer本身沒有字節(jié)序概念FileReader讀出來就是原始字節(jié)。所以這里沒問題。但如果你在某些場景下先用了DataView或TypedArray做轉(zhuǎn)換就可能出現(xiàn)字節(jié)序翻轉(zhuǎn)的問題。我的建議是不要在中途用Uint8Array轉(zhuǎn)換直接用WordArray.create最穩(wěn)。4.4 父組件里的使用方式封裝好后父組件里這樣用template div encrypt-uploader refuploaderRef acceptpdf,doc,docx,xls,xlsx,jpg,jpeg,png :max-size10 * 1024 * 1024 :upload-urluploadUrl upload-successhandleSuccess upload-errorhandleError / el-button typeprimary clicksubmitUpload上傳/el-button /div /templatesubmitUpload方法methods: { submitUpload() { this.$refs.uploaderRef.submit() }, handleSuccess(file, response) { // 處理業(yè)務(wù)邏輯比如回顯、保存記錄 this.$message.success(上傳成功) }, handleError(file, reason) { this.$message.error(上傳失敗) } }我在實際項目里把uploader組件的submit方法暴露給了父組件因為“選完文件后由用戶點擊統(tǒng)一上傳”是后臺系統(tǒng)的常見交互。如果你希望選完即傳就在after-file-added鉤子或選擇文件的回調(diào)里直接調(diào)this.uploader.upload()。5. 與vue2生態(tài)的兼容性細(xì)節(jié)5.1 在vue2里處理WebUploader全局依賴WebUploader不是ESM模塊npm安裝后還需要在main.js里或者index.html里引入。我試驗過兩種方式方式一在index.html里直接加scriptscript src/static/js/webuploader.min.js/scriptpublic目錄是靜態(tài)資源根路徑這樣可以避免webpack打包時對WebUploader代碼的處理問題。缺點是把全局變量掛到了window上但WebUploader本來就依賴全局這不算什么問題。方式二在組件內(nèi)importimport WebUploader from webuploader這種方式在打包時會報“window is not defined”之類的錯或者打出的包體積很大因為WebUploader壓縮前有200KB。我建議直接用script標(biāo)簽方式簡單粗暴穩(wěn)。5.2 vue2響應(yīng)式特性對WebUploader實例的影響這個點很多文章不提但我踩過很深的坑不要把WebUploader實例直接放進(jìn)vue的data里。因為vue2的響應(yīng)式系統(tǒng)會遞歸遍歷data對象的每個屬性用Object.defineProperty重寫。WebUploader實例內(nèi)部有大量DOM引用、事件隊列和內(nèi)部方法被vue代理后會導(dǎo)致兩個問題性能下降每次屬性讀取都走getter攔截上傳隊列操作頻繁時卡頓明顯穩(wěn)定性問題內(nèi)部某些屬性被攔截后可能會改變this指向?qū)е率录卣{(diào)觸發(fā)異常我一開始把uploader: null放在了data里結(jié)果在上傳文件列表更新時瀏覽器直接卡死。后來把這個變量移出data用普通對象created() { this._uploader null // 不走響應(yīng)式 }之后完全沒有這個性能問題了。這個細(xì)節(jié)如果你在用vue2做上傳組件一定會遇到。5.3 大文件上傳時vue2頁面的內(nèi)存管理WebUploader上傳大文件時瀏覽器內(nèi)存會明顯上漲。配合CryptoJS的加密處理內(nèi)存上漲幅度會更大。我這個項目用的文件不大但如果你要處理500MB以上的視頻或壓縮包必須注意幾點加密時不要再用FileReader.readAsDataURL轉(zhuǎn)Base64直接用readAsArrayBuffer更省內(nèi)存加密完成后把reader和中間變量置空讓瀏覽器能GCWebUploader的隊列里不要積壓太多文件盡量傳完一個清理一個組件銷毀時要調(diào)用uploader.destroy()并且把file.source等引用清掉否則一些瀏覽器會持續(xù)卡頓下面這段是我在項目里加的清理邏輯this.uploader.on(uploadComplete, function(file) { file.source null file.formData null file.encryptedBlob null // 注意不要直接刪除file對象它在隊列里可能還有引用 })這樣每個文件傳完就釋放內(nèi)存實測連續(xù)上傳幾十個文件瀏覽器內(nèi)存基本穩(wěn)定。6. 全鏈路聯(lián)調(diào)與后端配合要點6.1 前端上傳請求的實際格式前端配置完成并運行上傳后F12看到的請求體大致是這樣的POST https://api.example.com/api/upload HTTP/1.1 Host: api.example.com Content-Type: multipart/form-data; boundary----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; namefile; filenameencrypted_blob.bin Content-Type: application/octet-stream 二進(jìn)制密文內(nèi)容 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedKey MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedIv MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedFileName MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nametimestamp 1702960585000 ------WebKitFormBoundary7MA4YWxkTrZu0gW--可以看到原始文件名不會出現(xiàn)在任何地方后端只看到一堆base64字符串和一個“encrypted_blob.bin”的占位文件名。這已經(jīng)完全滿足“防止抓包看到明文”的需求。6.2 后端接包與解密的示例邏輯如果后端是Java SpringBootController大致這么寫PostMapping(/api/upload) public Result upload( RequestParam(file) MultipartFile file, RequestParam(encryptedKey) String encryptedKey, RequestParam(encryptedIv) String encryptedIv, RequestParam(encryptedFileName) String encryptedFileName, RequestParam(value timestamp, required false) Long timestamp ) throws Exception { // 1. RSA私鑰解出AES密鑰 // 2. AES密鑰IV解出文件名 // 3. AES密鑰IV解出文件內(nèi)容 // 4. 按業(yè)務(wù)場景存儲或返回 }Java后端解密AES密鑰時用Cipher.getInstance(RSA/ECB/PKCS1Padding)對應(yīng)JSEncrypt默認(rèn)的RSA Padding。解密文件名時注意前端使用encodeURIComponent編碼Java端需要URLDecoder.decode(decryptedFileName, UTF-8)。如果是PHP或Python后端原理類似關(guān)鍵是確認(rèn)三件事RSA Padding模式是PKCS1AES模式是CBC、Padding是PKCS7Base64編碼和解碼兩邊一致6.3 加解密一致性驗證方法聯(lián)調(diào)的時候最容易出問題的是“前端加密沒問題后端解出來是亂碼”。我建議在正式聯(lián)調(diào)前先做一次本地閉環(huán)驗證用Node.js跑一次加密再用后端代碼解密比對原始文件哈希。前端加密后把密文和密鑰這些參數(shù)保存一份到本地或console然后在后端寫個測試單元解一遍。解出來對比原始文件的MD5值如果一致鏈路就通了。這個驗證特別重要否則你會發(fā)現(xiàn)一切看著正常實際解密后文件根本打不開。我整理了一張驗證維度表供參考驗證項前端操作后端操作結(jié)果判斷AES密鑰加密JSEncrypt加密后得到encryptedKeyRSA私鑰解密解出的AESKey與前端一致文件內(nèi)容AES-CBC加密Base64輸出AES-CBC解密解出的文件MD5與原文件一致文件名encodeURIComponent加密解密URLDecoder.decode中文文件名無亂碼重放攻擊防護(hù)增加timestamp字段判斷是否在規(guī)定窗口期過期請求拒絕6.4 部署和測試環(huán)境里的額外注意事項項目在測試環(huán)境聯(lián)調(diào)時我由于公鑰更新不及時吃過虧。后端的RSA密鑰對是打包時生成的每次部署生成一次前端的公鑰在啟動時獲取。如果中間件或網(wǎng)關(guān)緩存了接口響應(yīng)前端可能拿到舊公鑰后端用新私鑰解不開。解決辦法是每次發(fā)布時后端清一下接口緩存前端在啟動時強制性拉取公鑰接口加時間戳參數(shù)繞過緩存export function getRsaPublicKey() { return request({ url: /api/system/public-key?ts${Date.now()}, method: get, headers: { cache-control: no-cache } }) }另外如果使用了Nginx反代要確保這個接口沒有被緩存否則上線后會出現(xiàn)“昨天還能傳今天全報解密失敗”的詭異問題。7. 常見問題與排查技巧實錄7.1 WebUploader在vue2項目里選完文件沒反應(yīng)這個現(xiàn)象通常不是加密邏輯的問題而是WebUploader的picker沒正確綁定。檢查三點組件掛載后DOM是否真的存在mounted里init沒問題但如果你在created里init就會出這個問題pick的id選擇器是否指向了一個已存在且可見的元素WebUploader是基于Flash和HTML5雙實現(xiàn)的現(xiàn)代環(huán)境優(yōu)先走HTML5所以不需要Flash插件我在項目里碰到過一次原因是組件在彈窗里彈窗還沒渲染完時就初始化了WebUploaderpicker綁不到DOM。解決辦法是在彈窗的open回調(diào)或nextTick里再初始化。7.2 加密后文件打不開或解出亂碼這類問題十有八九出在CryptoJS和C#或Java的AES模式參數(shù)不一致上。我見到最多的錯誤是前端用了CBCPkcs7后端用了ECBBase64字符串里帶了換行符或多余空格切割或傳遞時被破壞加密后的密文經(jīng)過URL傳輸被解析成空格這里給一個排查清單確認(rèn)AES mode、padding、key、iv都一致確認(rèn)RSA padding與后端一致確認(rèn)Base64字符在傳輸過程中沒有被URL編碼破壞確認(rèn)Blob替換后上傳時的流內(nèi)容就是加密后的二進(jìn)制最后一句話前端加密的密文傳到后端時multipart/form-data是二進(jìn)制流不會做URL解碼所以理論上不會出Base64被轉(zhuǎn)空格的問題。但如果你走的是JSON請求體那就要注意把Base64里所有“”替換成“%2B”或者用URL-safe Base64。7.3 WebUploader在vue2下打包后報錯“WebUploader is not defined”這是老生常談的問題重新梳理一下用script標(biāo)簽方式引入不使用import在組件mounted里再訪問window.WebUploader不要在模塊頂層直接訪問因為此時Script可能還沒加載完如果用CDN確認(rèn)引入順序在業(yè)務(wù)代碼之前我給組件里加了一個安全性檢查if (!window.WebUploader) { this.$message.error(文件上傳組件加載失敗請刷新頁面重試) return }7.4 keep-alive頁面里上傳組件內(nèi)存泄漏vue2項目里常有用keep-alive緩存頁面的場景。Uploader組件在activated和deactivated時不會銷毀所以beforeDestroy可能不觸發(fā)WebUploader實例會殘留在內(nèi)存里。我的處理方式是在deactivated鉤子里主動暫停上傳并釋放實例deactivated() { if (this.uploader) { this.uploader.stop(true) this.uploader.destroy() this.uploader null } }, activated() { // 重新初始化 }如果你發(fā)現(xiàn)緩存頁面反復(fù)進(jìn)出后瀏覽器內(nèi)存持續(xù)暴漲大概率就是這個問題。不用全組銷毀只要在離開時destroy就行。7.5 加密后文件上傳到OSS但無法在線上預(yù)覽加密存儲的代價就是所有依賴完整文件的預(yù)覽能力都沒了因為OSS里存的是密文。這個在需求階段就要和產(chǎn)品確認(rèn)清楚。如果需要預(yù)覽有兩種常見解法后端解密后通過一個臨時簽名的接口輸出到瀏覽器預(yù)覽預(yù)覽完即失效把縮略圖或視頻轉(zhuǎn)碼流放行成明文原始文件保持密文我在項目里是先把圖片壓縮生成一個縮略圖明文只對原始文件加密。這樣列表頁展示縮略圖不受影響下載原文件時才走解密接口。這個方案兼顧了體驗和安全推薦給你參考。8. 安全加固與擴(kuò)展實踐8.1 加解密過程的時間性能實測加密耗時這個數(shù)據(jù)我實測過幾次給你一個參考文件大小AES-256加密耗時Base64編碼耗時總耗時100KB約20ms約5ms約25ms1MB約150ms約40ms約190ms5MB約800ms約200ms約1s20MB約3.2s約800ms約4s在普通辦公網(wǎng)絡(luò)環(huán)境下多出這幾秒通常是可以接受的。但如果你要上傳超大文件建議在UI上做一個“加密中”的loading提示避免用戶以為卡死了。8.2 再加一層自定義Header校驗除了加密本身我還在項目里加了自定義Header校驗前端在請求頭里帶一個由時間戳和AESKey摘要計算出來的簽名后端做同源校驗防止有人直接拿著加密后的請求重放。這個簽名邏輯也很簡單const sign CryptoJS.HmacSHA256(timestamp encryptedKey, aesKey.toString()).toString()后端解密后用自己的邏輯校驗sign是否一致。相當(dāng)于給加密鏈路再加了一道鎖。雖然對普通業(yè)務(wù)來說RSAAES已經(jīng)夠用但如果你對接的是政務(wù)系統(tǒng)或網(wǎng)絡(luò)安全等級保護(hù)要求高的場景這層簽名是很有必要的。8.3 后續(xù)擴(kuò)展方向這個方案后續(xù)還可以做幾個擴(kuò)展把加密從“上傳加密”擴(kuò)展到“下載解密”后端存密文用戶下載時前端解密展示全程不在服務(wù)器落明文引入文件指紋MD5、SHA-256在上傳前先做秒傳判斷同時保證加密后的文件指紋一致可以用來去重結(jié)合消息隊列做異步解密任務(wù)避免大文件解密時阻塞主線程影響其他接口響應(yīng)在我做過的系統(tǒng)里擴(kuò)展方向往往取決于業(yè)務(wù)對文件安全重視到什么程度。加密是一個不能只做一半的事情前端加密了后端存儲還暴露明文就白做了后端解密后又會把明文暴露在接口層也要加權(quán)限控制。所以全鏈路都要考慮到才能算完成了一次加密存儲改造。最后說一點個人體會前端加密從來都不是萬能的密鑰、算法、傳輸、存儲、權(quán)限每個環(huán)節(jié)都可能成為短板。但在現(xiàn)實項目里RSAAES混合加密已經(jīng)是性價比最高的方案了——性能開銷可接受、破解難度足夠、實現(xiàn)成本也不算高。如果你和我一樣在維護(hù)老項目這套東西真的可以直接復(fù)制過去用比從零搭一套安全體系省太多事了。 Vue2項目實戰(zhàn)：WebUploader結(jié)合AES+RSA實現(xiàn)文件加密上傳
1. 項目概述與技術(shù)選型思考1.1 為什么還在vue2里選百度WebUploader先說結(jié)論在2024年還在維護(hù)vue2項目說明這是個存量系統(tǒng)大概率是企業(yè)后臺、政務(wù)平臺或者金融類管理系統(tǒng)。這類系統(tǒng)最大的特點就是不能隨便動底層架構(gòu)但安全要求又逐年升級所以“老框架老插件新加密要求”的組合特別典型。百度WebUploader這個插件很多人一聽就覺得過時了。但坦白講它在企業(yè)級場景里依然有不可替代的價值分片上傳、斷點續(xù)傳、并發(fā)限制、MD5秒傳這些能力現(xiàn)在很多前端上傳組件要折騰半天才能實現(xiàn)WebUploader開箱即用。尤其在內(nèi)網(wǎng)環(huán)境部署的系統(tǒng)里性能穩(wěn)定、兼容性好還不需要額外依賴這幾點到現(xiàn)在依然是硬需求。我這次接手的項目就是個典型場景vue2.6 element-ui WebUploader的存量后臺需要把附件上傳模塊從裸HTTP明文傳輸升級為加密存儲。需求拆開看其實有兩層前端在文件上傳前先做加密不能明文走網(wǎng)絡(luò)后端存儲時保留密文防止拖庫后文件內(nèi)容直接泄露1.2 加密方案選型的核心矛盾最初產(chǎn)品提需求時人員想的是“上傳前用密碼加密一下就行”但真正落地要考慮的事情就多了。核心矛盾在于文件體積不同加密策略必須分層一套方案打天下是不現(xiàn)實的。我測試過幾種路線單純用JSEncryptRSA加全部文件內(nèi)容幾百KB的小文件還行上MB就卡死。RSA是非對稱加密密鑰長、運算重不適合大量數(shù)據(jù)。單純用CryptoJS的AES加速度沒問題但密鑰寫死在前端等于脫褲子放屁抓包拿到密鑰就能解密。AES RSA混合AES負(fù)責(zé)加密文件內(nèi)容RSA負(fù)責(zé)把AES的密鑰加密后傳給后端。既解決性能問題也解決密鑰分發(fā)問題。這是主流方案。最后定的是AES-256 RSA-2048的混合加密。AES用CBC模式PKCS7填充密鑰隨機生成RSA公鑰來自后端接口私鑰永遠(yuǎn)不出后端。這樣前端就算被完全逆向也拿不到解密能力。接下來我先說封裝細(xì)節(jié)然后給完整代碼再講全鏈路聯(lián)調(diào)和坑。這個順序能幫你先建立整體認(rèn)知再抄作業(yè)的時候就不容易抄歪。2. 整體設(shè)計與技術(shù)鏈路拆解2.1 前端加密的完整鏈路整個加密上傳的流程我畫了個流程圖在腦子里文字描述是這樣的用戶選擇文件WebUploader接管文件隊列上傳前觸發(fā)before-send-file鉤子這里做加密每個文件隨機生成一個AES密鑰32字節(jié)用CryptoJS的AES-CBC加密文件二進(jìn)制內(nèi)容得到密文用后端下發(fā)的RSA公鑰加密AES密鑰得到密鑰密文把密文文件和密鑰密文一起post到后端后端收到后用RSA私鑰解出AES密鑰再用AES密鑰解文件內(nèi)容按業(yè)務(wù)需要存儲這個鏈路里有個很容易被忽略的關(guān)鍵點不是所有場景都需要后端解出明文再存儲。如果需求是“后端只存密文永不讀明文”那后端不需要解密只需要把密文和密鑰分開存查詢時把密文交給有權(quán)限的前端自行解密。但這個項目的要求是“存儲時加密使用時可控”所以我讓后端解密后以密文形式入庫只有業(yè)務(wù)層通過接口訪問時才在內(nèi)存中臨時解密。這樣數(shù)據(jù)庫被拖了也只是密文。2.2 為什么要AES和RSA配合用生活類比來說AES像一把房間鑰匙加密解密都快適合處理大件行李但房間鑰匙不能直接交給別人萬一被復(fù)制就完了。RSA像個保險箱慢但安全適合送“房間鑰匙”這份小物件。具體到我們的鏈路AES密鑰是隨機生成的每次上傳都不同即使這次被破解也影響不了歷史文件RSA公鑰加密AES密鑰保證只有持RSA私鑰的后端才能取出AES密鑰網(wǎng)絡(luò)抓包只能看到一堆無意義的base64字符文件內(nèi)容加密后再進(jìn)行Base64編碼傳輸這個過程繞開了WebUploader默認(rèn)的FormData裸傳行為可以在過程中插入自定義校驗邏輯2.3 WebUploader與vue2生命周期的綁定方式百度WebUploader原生是基于jQuery的但vue2項目里引入它要處理兩個問題WebUploader實例的創(chuàng)建和銷毀要和組件生命周期保持一致WebUploader內(nèi)部操作的是真實DOMpicker按鈕需要避開vue的虛擬DOM管理我的做法是把上傳封裝成一個獨立的Uploader.vue組件在使用它的父組件里傳入上傳參數(shù)WebUploader實例在mounted中創(chuàng)建在beforeDestroy中手動銷毀。這樣既隔離了生命周期又能讓W(xué)ebUploader和vue2的數(shù)據(jù)流通過props和$emit對接。具體來說封裝的好處有三點如果項目里有多個頁面需要上傳文件不用重復(fù)初始化WebUploader傳不同的配置就行WebUploader實例的清理邏輯destroy、解綁事件集中在組件內(nèi)部不會因為頁面切換導(dǎo)致內(nèi)存泄漏加密邏輯CryptoJS相關(guān)只在這個組件里被引用一旦出問題可以快速定位3. 核心細(xì)節(jié)解析與工具選型3.1 依賴引入的細(xì)節(jié)控制項目用的依賴版本很關(guān)鍵直接貼出來vue2.6.14webuploader0.1.9直接npm安裝或者用官方dist文件也可以crypto-js4.1.1jsencrypt3.3.2這里提個坑WebUploader在npm上的包名叫webuploader但安裝之后不能直接import它需要掛window。在vue2 CLI項目里我是在index.html里通過script標(biāo)簽引的CDN或本地文件這樣能直接訪問window.WebUploader避免webpack打包CommonJS時出現(xiàn)“WebUploader is not defined”的錯誤。CryptoJS的引入方式import CryptoJS from crypto-js這個庫是純JavaScript實現(xiàn)的不管在瀏覽器還是webpack環(huán)境都穩(wěn)。JSEncrypt也一樣import JSEncrypt from jsencrypt需要額外注意一點CryptoJS處理中文文件名時直接encrypt會報錯或亂碼。這是因為CryptoJS默認(rèn)把字符串按UTF-8編碼處理而文件名有時候編碼方式不同。我是在加密前統(tǒng)一將文件名encodeURIComponent轉(zhuǎn)了一下加密后拿到字節(jié)數(shù)組再拼接然后在FileName字段中單獨加密傳輸避免文件名亂碼的問題。3.2 加密參數(shù)配置的“為什么”先看核心加密參數(shù)配置const AESKey CryptoJS.lib.WordArray.random(32) // 32字節(jié) 256位 const AESIV CryptoJS.lib.WordArray.random(16) // 16字節(jié) 128位為什么要隨機生成AESIV因為CBC模式下相同的明文和相同的密鑰如果IV相同產(chǎn)生的密文也是相同的。攻擊者可以從“相同密文”推斷出“相同明文”的信息這叫做確定性加密漏洞。每次隨機IV即使同一個文件上傳了兩次密文也完全不一樣這就增加了破解難度。CBC模式和PBKDF2相關(guān)的參數(shù)我也給一下推薦值密鑰長度256位32字節(jié)IV長度128位16字節(jié)填充PKCS7CryptoJS默認(rèn)模式CBC編碼Base64CryptoJS在代碼里通過這種方式設(shè)置const encrypted CryptoJS.AES.encrypt( CryptoJS.enc.Utf8.parse(plainText), AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 } )3.3 文件內(nèi)容加密的兩種姿勢WebUploader在before-send-file鉤子里能拿到file對象但拿到的file是WebUploader包裝后的對象。加密時有兩種處理方式第一種通過FileReader把file讀取為ArrayBuffer然后轉(zhuǎn)成WordArray交給CryptoJS處理const reader new FileReader() reader.onload function(e) { const arrayBuffer e.target.result const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encrypted CryptoJS.AES.encrypt(wordArray, AESKey, { iv: AESIV, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) // 后續(xù)將 encrypted.toString() 作為上傳內(nèi)容 } reader.readAsArrayBuffer(file)這種方式適合小文件和中等文件因為它是把整個文件讀進(jìn)內(nèi)存再加密文件太大的話前端會有內(nèi)存壓力。第二種如果文件超大比如視頻、壓縮包WebUploader本身支持分片上傳但分片加密會引入“每個分片需要獨立IV和密鑰”的復(fù)雜度。這個項目里我暫時沒做分片級加密因為實際業(yè)務(wù)上傳的文件平均都在1MB以內(nèi)ArrayBuffer方式完全能扛住。如果你接手的是要傳大片視頻的項目我給個建議每個分片用相同的密鑰但每個分片隨機生成IV傳輸時把IV和分片密文一起發(fā)給后端后端按分片索引依次解密后拼接。這樣能把“加密”和“斷點續(xù)傳”兩個需求同時滿足分片加密的代碼量其實只多幾十行。3.4 非對稱加密保護(hù)和字段封裝生成了AES密鑰之后用JSEncrypt做RSA加密const encryptor new JSEncrypt() encryptor.setPublicKey(publicKey) // 后端下發(fā)的RSA公鑰 const encryptedKey encryptor.encrypt(AESKey.toString(CryptoJS.enc.Base64))注意這里加密的對象是Base64編碼后的AESKey字符串。AESKey是WordArray對象直接傳給JSEncrypt會出問題先轉(zhuǎn)成Base64字符串是穩(wěn)妥的。上傳時把下面幾個字段封裝成一個JSON對象fileNameencodeURIComponent后的原始文件名encryptedKeyRSA加密后的AES密鑰Base64encryptedIVAES的IV這個我直接拼接在密文頭部或者單獨字段看后端解析習(xí)慣contentAES加密后的文件內(nèi)容Base64timestamp時間戳可以防止重放攻擊后端可選校驗這段JSON用一個自定義header傳給后端或者作為FormData的一個字段。我在實際項目里用的是FormData方式因為后端已經(jīng)有一套MultipartFile接收邏輯直接多加了幾個字段改動量小。這里有個實戰(zhàn)技巧如果content特別大比如10MB不要直接把整個JSON塞進(jìn)FormData的普通字段里而是把content作為單獨的文件字段其他信息放在普通字段。這樣后端拿到MultipartFile的時候就是已經(jīng)加密的密文文件存儲邏輯不需要改動太多。我項目里就是這么處理的把“加密后的內(nèi)容”重新包裝成一個Blob文件讓W(xué)ebUploader上傳這個Blob文件。4. 實操過程與完整實現(xiàn)4.1 后端下發(fā)RSA公鑰的接口約定第一步需要后端提供一個公鑰接口。這個接口不涉及敏感操作可以設(shè)計為公開接口返回格式如下{ code: 0, data: { publicKey: -----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... } }在vue2項目的api模塊里加一個方法// api/upload.js import request from /utils/request export function getRsaPublicKey() { return request({ url: /api/system/public-key, method: get }) }這里的request就是axios封裝實例不用改底層邏輯正常調(diào)用就行。4.2 完整Uploader.vue組件代碼下面是這個項目的核心組件我按實際代碼精簡后給出。先看完整結(jié)構(gòu)再逐段解釋。template div classuploader-container div iduploader-picker classuploader-picker選擇文件/div div iduploader-list classuploader-list/div /div /template script import CryptoJS from crypto-js import JSEncrypt from jsencrypt import { getRsaPublicKey } from /api/upload export default { name: EncryptUploader, props: { accept: { type: String, default: */* }, maxSize: { type: Number, default: 20 * 1024 * 1024 }, uploadUrl: { type: String, default: /api/upload } }, data() { return { uploader: null, rsaPublicKey: } }, async mounted() { const res await getRsaPublicKey() this.rsaPublicKey res.data.publicKey this.initUploader() }, methods: { initUploader() { const _this this this.uploader window.WebUploader.create({ pick: { id: #uploader-picker, multiple: false }, accept: { title: Files, extensions: this.accept }, server: this.uploadUrl, fileVal: file, auto: false, chunked: false, duplicate: true, resize: false, compress: false, formData: { // 這里不寫死業(yè)務(wù)字段因為要動態(tài)放入加密數(shù)據(jù) } }) this.uploader.on(before-send-file, function(file) { return _this.handleBeforeSendFile(file) }) this.uploader.on(uploadSuccess, function(file, response) { _this.$emit(upload-success, file, response) }) this.uploader.on(uploadError, function(file, reason) { _this.$emit(upload-error, file, reason) }) this.uploader.on(error, function(type) { if (type Q_EXCEED_SIZE_LIMIT) { _this.$message.error(文件大小超出限制) } _this.$emit(upload-type-error, type) }) this.uploader.on(uploadComplete, function(file) { _this.$emit(upload-complete, file) }) }, handleBeforeSendFile(file) { // 返回一個PromiseWebUploader會等待它resolve后再繼續(xù) return new Promise((resolve, reject) { const reader new FileReader() reader.onload (event) { try { const arrayBuffer event.target.result const result this.encryptFile(arrayBuffer, file.name) // WebUploader通過file對象的一個擴(kuò)展屬性把加密后的內(nèi)容傳出去 file.encryptedBlob new Blob([result.content], { type: application/octet-stream }) file.encryptedFileName result.encryptedFileName file.encryptedKey result.encryptedKey file.encryptedIv result.encryptedIv file.timestamp result.timestamp this.uploader.options.server this.uploadUrl // 關(guān)鍵替換WebUploader內(nèi)部的上傳文件數(shù)據(jù) this.overrideUploadMethod(file, result) resolve() } catch (e) { reject(e) } } reader.onerror () { reject(new Error(讀取文件失敗)) } reader.readAsArrayBuffer(file.source) }) }, encryptFile(arrayBuffer, fileName) { // 1. 生成AES密鑰和IV const aesKey CryptoJS.lib.WordArray.random(32) const aesIv CryptoJS.lib.WordArray.random(16) // 2. 用AES加密文件內(nèi)容 const wordArray CryptoJS.lib.WordArray.create(arrayBuffer) const encryptedContent CryptoJS.AES.encrypt(wordArray, aesKey, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString() // 3. 用RSA公鑰加密AES密鑰 const encryptor new JSEncrypt() encryptor.setPublicKey(this.rsaPublicKey) const encryptedKey encryptor.encrypt(aesKey.toString(CryptoJS.enc.Base64)) const encryptedIv encryptor.encrypt(aesIv.toString(CryptoJS.enc.Base64)) // 4. 文件名也加密 const encryptedFileName encryptor.encrypt(encodeURIComponent(fileName)) return { content: encryptedContent, encryptedKey, encryptedIv, encryptedFileName, timestamp: Date.now() } }, overrideUploadMethod(file, encryptResult) { // 這里用比較“偏門”但穩(wěn)定有效的方式 // 直接操作WebUploader內(nèi)部Hooks替換上傳時的FormData const me this.uploader const oldSend me.uploader.options.server // 在before-send-file的Promise resolve之后修改file的上傳數(shù)據(jù) file.formData { encryptedKey: encryptResult.encryptedKey, encryptedIv: encryptResult.encryptedIv, encryptedFileName: encryptResult.encryptedFileName, timestamp: encryptResult.timestamp } // WebUploader把file.formData合并進(jìn)上傳請求 // 同時我們把file.source修改成加密后的Blob file.source file.encryptedBlob }, submit() { if (this.uploader) { this.uploader.upload() } } }, beforeDestroy() { if (this.uploader) { this.uploader.destroy() this.uploader null } } } /script4.3 代碼里幾個隱蔽但關(guān)鍵的點這份代碼看起來邏輯不復(fù)雜但真正運行起來會踩一些隱蔽的坑我逐一說。第一個坑WebUploader默認(rèn)會把file.source作為上傳文件但上傳時FormData里的文件名、文件內(nèi)容都來自file.source。我直接把file.source file.encryptedBlob替換掉同時把file.name改成file.encryptedFileName對應(yīng)的值。這樣上傳請求發(fā)出去時后端收到的就是密文內(nèi)容和密文文件名。但WebUploader在before-send-file鉤子執(zhí)行完后內(nèi)部會重新讀取file.source的size等屬性。如果你把Blob文件替換了但沒更新file.size后續(xù)校驗可能會報錯。我在實際項目里加了一行file.size file.encryptedBlob.size這行不加的話WebUploader會出現(xiàn)“上傳文件為空”或者進(jìn)度條不動的問題。很多人在這里卡了很久其實就這么簡單。第二個坑Promise.resolve后WebUploader會繼續(xù)流程但沒有一個官方API讓你“再改一遍上傳參數(shù)”。用file.formData把extra字段帶過去是我嘗試出來的方式。WebUploader官方文檔里提到“如果要附加參數(shù)可以在uploader.option(formData)里配置”但那是對所有文件統(tǒng)一的。要針對單個文件動態(tài)附加就得在file對象上掛formData屬性內(nèi)部request方法會合并。我后來翻源碼確認(rèn)了這一點在webuploader.js的Request方法里確實有合并file.formData的邏輯。所以這個方法不是hack是官方預(yù)留的口子。第三個坑加密后的Base64內(nèi)容會比原始文件大不少Base64編碼膨脹約33%如果你在業(yè)務(wù)里對上傳文件大小做了限制加解密后校驗的是“加密后大小”要在組件里相應(yīng)地調(diào)整校驗上限。我在props里專門加了一個enableEncryptSizeLimit的配置默認(rèn)不限制如果后端限制的話用加密前原始大小去判斷。第四個坑CryptoJS處理ArrayBuffer時有個字節(jié)序問題。CryptoJS.lib.WordArray.create(arrayBuffer)時如果是ArrayBuffer它會按大端序讀取。但ArrayBuffer本身沒有字節(jié)序概念FileReader讀出來就是原始字節(jié)。所以這里沒問題。但如果你在某些場景下先用了DataView或TypedArray做轉(zhuǎn)換就可能出現(xiàn)字節(jié)序翻轉(zhuǎn)的問題。我的建議是不要在中途用Uint8Array轉(zhuǎn)換直接用WordArray.create最穩(wěn)。4.4 父組件里的使用方式封裝好后父組件里這樣用template div encrypt-uploader refuploaderRef acceptpdf,doc,docx,xls,xlsx,jpg,jpeg,png :max-size10 * 1024 * 1024 :upload-urluploadUrl upload-successhandleSuccess upload-errorhandleError / el-button typeprimary clicksubmitUpload上傳/el-button /div /templatesubmitUpload方法methods: { submitUpload() { this.$refs.uploaderRef.submit() }, handleSuccess(file, response) { // 處理業(yè)務(wù)邏輯比如回顯、保存記錄 this.$message.success(上傳成功) }, handleError(file, reason) { this.$message.error(上傳失敗) } }我在實際項目里把uploader組件的submit方法暴露給了父組件因為“選完文件后由用戶點擊統(tǒng)一上傳”是后臺系統(tǒng)的常見交互。如果你希望選完即傳就在after-file-added鉤子或選擇文件的回調(diào)里直接調(diào)this.uploader.upload()。5. 與vue2生態(tài)的兼容性細(xì)節(jié)5.1 在vue2里處理WebUploader全局依賴WebUploader不是ESM模塊npm安裝后還需要在main.js里或者index.html里引入。我試驗過兩種方式方式一在index.html里直接加scriptscript src/static/js/webuploader.min.js/scriptpublic目錄是靜態(tài)資源根路徑這樣可以避免webpack打包時對WebUploader代碼的處理問題。缺點是把全局變量掛到了window上但WebUploader本來就依賴全局這不算什么問題。方式二在組件內(nèi)importimport WebUploader from webuploader這種方式在打包時會報“window is not defined”之類的錯或者打出的包體積很大因為WebUploader壓縮前有200KB。我建議直接用script標(biāo)簽方式簡單粗暴穩(wěn)。5.2 vue2響應(yīng)式特性對WebUploader實例的影響這個點很多文章不提但我踩過很深的坑不要把WebUploader實例直接放進(jìn)vue的data里。因為vue2的響應(yīng)式系統(tǒng)會遞歸遍歷data對象的每個屬性用Object.defineProperty重寫。WebUploader實例內(nèi)部有大量DOM引用、事件隊列和內(nèi)部方法被vue代理后會導(dǎo)致兩個問題性能下降每次屬性讀取都走getter攔截上傳隊列操作頻繁時卡頓明顯穩(wěn)定性問題內(nèi)部某些屬性被攔截后可能會改變this指向?qū)е率录卣{(diào)觸發(fā)異常我一開始把uploader: null放在了data里結(jié)果在上傳文件列表更新時瀏覽器直接卡死。后來把這個變量移出data用普通對象created() { this._uploader null // 不走響應(yīng)式 }之后完全沒有這個性能問題了。這個細(xì)節(jié)如果你在用vue2做上傳組件一定會遇到。5.3 大文件上傳時vue2頁面的內(nèi)存管理WebUploader上傳大文件時瀏覽器內(nèi)存會明顯上漲。配合CryptoJS的加密處理內(nèi)存上漲幅度會更大。我這個項目用的文件不大但如果你要處理500MB以上的視頻或壓縮包必須注意幾點加密時不要再用FileReader.readAsDataURL轉(zhuǎn)Base64直接用readAsArrayBuffer更省內(nèi)存加密完成后把reader和中間變量置空讓瀏覽器能GCWebUploader的隊列里不要積壓太多文件盡量傳完一個清理一個組件銷毀時要調(diào)用uploader.destroy()并且把file.source等引用清掉否則一些瀏覽器會持續(xù)卡頓下面這段是我在項目里加的清理邏輯this.uploader.on(uploadComplete, function(file) { file.source null file.formData null file.encryptedBlob null // 注意不要直接刪除file對象它在隊列里可能還有引用 })這樣每個文件傳完就釋放內(nèi)存實測連續(xù)上傳幾十個文件瀏覽器內(nèi)存基本穩(wěn)定。6. 全鏈路聯(lián)調(diào)與后端配合要點6.1 前端上傳請求的實際格式前端配置完成并運行上傳后F12看到的請求體大致是這樣的POST https://api.example.com/api/upload HTTP/1.1 Host: api.example.com Content-Type: multipart/form-data; boundary----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; namefile; filenameencrypted_blob.bin Content-Type: application/octet-stream 二進(jìn)制密文內(nèi)容 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedKey MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedIv MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nameencryptedFileName MIGfMA0GCSqGSIb3...Base64 ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; nametimestamp 1702960585000 ------WebKitFormBoundary7MA4YWxkTrZu0gW--可以看到原始文件名不會出現(xiàn)在任何地方后端只看到一堆base64字符串和一個“encrypted_blob.bin”的占位文件名。這已經(jīng)完全滿足“防止抓包看到明文”的需求。6.2 后端接包與解密的示例邏輯如果后端是Java SpringBootController大致這么寫PostMapping(/api/upload) public Result upload( RequestParam(file) MultipartFile file, RequestParam(encryptedKey) String encryptedKey, RequestParam(encryptedIv) String encryptedIv, RequestParam(encryptedFileName) String encryptedFileName, RequestParam(value timestamp, required false) Long timestamp ) throws Exception { // 1. RSA私鑰解出AES密鑰 // 2. AES密鑰IV解出文件名 // 3. AES密鑰IV解出文件內(nèi)容 // 4. 按業(yè)務(wù)場景存儲或返回 }Java后端解密AES密鑰時用Cipher.getInstance(RSA/ECB/PKCS1Padding)對應(yīng)JSEncrypt默認(rèn)的RSA Padding。解密文件名時注意前端使用encodeURIComponent編碼Java端需要URLDecoder.decode(decryptedFileName, UTF-8)。如果是PHP或Python后端原理類似關(guān)鍵是確認(rèn)三件事RSA Padding模式是PKCS1AES模式是CBC、Padding是PKCS7Base64編碼和解碼兩邊一致6.3 加解密一致性驗證方法聯(lián)調(diào)的時候最容易出問題的是“前端加密沒問題后端解出來是亂碼”。我建議在正式聯(lián)調(diào)前先做一次本地閉環(huán)驗證用Node.js跑一次加密再用后端代碼解密比對原始文件哈希。前端加密后把密文和密鑰這些參數(shù)保存一份到本地或console然后在后端寫個測試單元解一遍。解出來對比原始文件的MD5值如果一致鏈路就通了。這個驗證特別重要否則你會發(fā)現(xiàn)一切看著正常實際解密后文件根本打不開。我整理了一張驗證維度表供參考驗證項前端操作后端操作結(jié)果判斷AES密鑰加密JSEncrypt加密后得到encryptedKeyRSA私鑰解密解出的AESKey與前端一致文件內(nèi)容AES-CBC加密Base64輸出AES-CBC解密解出的文件MD5與原文件一致文件名encodeURIComponent加密解密URLDecoder.decode中文文件名無亂碼重放攻擊防護(hù)增加timestamp字段判斷是否在規(guī)定窗口期過期請求拒絕6.4 部署和測試環(huán)境里的額外注意事項項目在測試環(huán)境聯(lián)調(diào)時我由于公鑰更新不及時吃過虧。后端的RSA密鑰對是打包時生成的每次部署生成一次前端的公鑰在啟動時獲取。如果中間件或網(wǎng)關(guān)緩存了接口響應(yīng)前端可能拿到舊公鑰后端用新私鑰解不開。解決辦法是每次發(fā)布時后端清一下接口緩存前端在啟動時強制性拉取公鑰接口加時間戳參數(shù)繞過緩存export function getRsaPublicKey() { return request({ url: /api/system/public-key?ts${Date.now()}, method: get, headers: { cache-control: no-cache } }) }另外如果使用了Nginx反代要確保這個接口沒有被緩存否則上線后會出現(xiàn)“昨天還能傳今天全報解密失敗”的詭異問題。7. 常見問題與排查技巧實錄7.1 WebUploader在vue2項目里選完文件沒反應(yīng)這個現(xiàn)象通常不是加密邏輯的問題而是WebUploader的picker沒正確綁定。檢查三點組件掛載后DOM是否真的存在mounted里init沒問題但如果你在created里init就會出這個問題pick的id選擇器是否指向了一個已存在且可見的元素WebUploader是基于Flash和HTML5雙實現(xiàn)的現(xiàn)代環(huán)境優(yōu)先走HTML5所以不需要Flash插件我在項目里碰到過一次原因是組件在彈窗里彈窗還沒渲染完時就初始化了WebUploaderpicker綁不到DOM。解決辦法是在彈窗的open回調(diào)或nextTick里再初始化。7.2 加密后文件打不開或解出亂碼這類問題十有八九出在CryptoJS和C#或Java的AES模式參數(shù)不一致上。我見到最多的錯誤是前端用了CBCPkcs7后端用了ECBBase64字符串里帶了換行符或多余空格切割或傳遞時被破壞加密后的密文經(jīng)過URL傳輸被解析成空格這里給一個排查清單確認(rèn)AES mode、padding、key、iv都一致確認(rèn)RSA padding與后端一致確認(rèn)Base64字符在傳輸過程中沒有被URL編碼破壞確認(rèn)Blob替換后上傳時的流內(nèi)容就是加密后的二進(jìn)制最后一句話前端加密的密文傳到后端時multipart/form-data是二進(jìn)制流不會做URL解碼所以理論上不會出Base64被轉(zhuǎn)空格的問題。但如果你走的是JSON請求體那就要注意把Base64里所有“”替換成“%2B”或者用URL-safe Base64。7.3 WebUploader在vue2下打包后報錯“WebUploader is not defined”這是老生常談的問題重新梳理一下用script標(biāo)簽方式引入不使用import在組件mounted里再訪問window.WebUploader不要在模塊頂層直接訪問因為此時Script可能還沒加載完如果用CDN確認(rèn)引入順序在業(yè)務(wù)代碼之前我給組件里加了一個安全性檢查if (!window.WebUploader) { this.$message.error(文件上傳組件加載失敗請刷新頁面重試) return }7.4 keep-alive頁面里上傳組件內(nèi)存泄漏vue2項目里常有用keep-alive緩存頁面的場景。Uploader組件在activated和deactivated時不會銷毀所以beforeDestroy可能不觸發(fā)WebUploader實例會殘留在內(nèi)存里。我的處理方式是在deactivated鉤子里主動暫停上傳并釋放實例deactivated() { if (this.uploader) { this.uploader.stop(true) this.uploader.destroy() this.uploader null } }, activated() { // 重新初始化 }如果你發(fā)現(xiàn)緩存頁面反復(fù)進(jìn)出后瀏覽器內(nèi)存持續(xù)暴漲大概率就是這個問題。不用全組銷毀只要在離開時destroy就行。7.5 加密后文件上傳到OSS但無法在線上預(yù)覽加密存儲的代價就是所有依賴完整文件的預(yù)覽能力都沒了因為OSS里存的是密文。這個在需求階段就要和產(chǎn)品確認(rèn)清楚。如果需要預(yù)覽有兩種常見解法后端解密后通過一個臨時簽名的接口輸出到瀏覽器預(yù)覽預(yù)覽完即失效把縮略圖或視頻轉(zhuǎn)碼流放行成明文原始文件保持密文我在項目里是先把圖片壓縮生成一個縮略圖明文只對原始文件加密。這樣列表頁展示縮略圖不受影響下載原文件時才走解密接口。這個方案兼顧了體驗和安全推薦給你參考。8. 安全加固與擴(kuò)展實踐8.1 加解密過程的時間性能實測加密耗時這個數(shù)據(jù)我實測過幾次給你一個參考文件大小AES-256加密耗時Base64編碼耗時總耗時100KB約20ms約5ms約25ms1MB約150ms約40ms約190ms5MB約800ms約200ms約1s20MB約3.2s約800ms約4s在普通辦公網(wǎng)絡(luò)環(huán)境下多出這幾秒通常是可以接受的。但如果你要上傳超大文件建議在UI上做一個“加密中”的loading提示避免用戶以為卡死了。8.2 再加一層自定義Header校驗除了加密本身我還在項目里加了自定義Header校驗前端在請求頭里帶一個由時間戳和AESKey摘要計算出來的簽名后端做同源校驗防止有人直接拿著加密后的請求重放。這個簽名邏輯也很簡單const sign CryptoJS.HmacSHA256(timestamp encryptedKey, aesKey.toString()).toString()后端解密后用自己的邏輯校驗sign是否一致。相當(dāng)于給加密鏈路再加了一道鎖。雖然對普通業(yè)務(wù)來說RSAAES已經(jīng)夠用但如果你對接的是政務(wù)系統(tǒng)或網(wǎng)絡(luò)安全等級保護(hù)要求高的場景這層簽名是很有必要的。8.3 后續(xù)擴(kuò)展方向這個方案后續(xù)還可以做幾個擴(kuò)展把加密從“上傳加密”擴(kuò)展到“下載解密”后端存密文用戶下載時前端解密展示全程不在服務(wù)器落明文引入文件指紋MD5、SHA-256在上傳前先做秒傳判斷同時保證加密后的文件指紋一致可以用來去重結(jié)合消息隊列做異步解密任務(wù)避免大文件解密時阻塞主線程影響其他接口響應(yīng)在我做過的系統(tǒng)里擴(kuò)展方向往往取決于業(yè)務(wù)對文件安全重視到什么程度。加密是一個不能只做一半的事情前端加密了后端存儲還暴露明文就白做了后端解密后又會把明文暴露在接口層也要加權(quán)限控制。所以全鏈路都要考慮到才能算完成了一次加密存儲改造。最后說一點個人體會前端加密從來都不是萬能的密鑰、算法、傳輸、存儲、權(quán)限每個環(huán)節(jié)都可能成為短板。但在現(xiàn)實項目里RSAAES混合加密已經(jīng)是性價比最高的方案了——性能開銷可接受、破解難度足夠、實現(xiàn)成本也不算高。如果你和我一樣在維護(hù)老項目這套東西真的可以直接復(fù)制過去用比從零搭一套安全體系省太多事了。