深圳网站建设app开发晋中住房与城乡建设厅网站

深圳网站建设app开发,晋中住房与城乡建设厅网站,怎样做彩票网站代理,wordpress 附件id[toc] React Native 在效率和跨平台上确实香#xff0c;但安全这块如果不额外加固#xff0c;几乎是“裸奔”。 很多团队一开始觉得#xff1a;App 是壳#xff0c;逻辑在服务器 被反编译了也没啥大不了结果上线后才发现#xff1a; JS bundle 被直接扒出来API 被抓包[toc]React Native 在效率和跨平台上确实香但安全这块如果不额外加固几乎是“裸奔”。很多团队一开始觉得App 是壳逻辑在服务器被反编译了也没啥大不了结果上线后才发现JS bundle 被直接扒出来API 被抓包参数规则一清二楚业务校验逻辑被逆向复刻甚至直接被做成“外挂 App”这篇文章就从RN 项目真实会被攻击的角度系统讲一套可落地的安全强化方案。RN 项目常见安全痛点先说结论RN 默认安全级别非常低。1. JS bundle 明文存储无论 Android 还是 iOSindex.android.bundlemain.jsbundle基本都是明文 JS 文件稍微懂点的人apktool d app.apk或者直接解 IPA就能看到完整业务逻辑。2. API 请求太容易被抓HTTPS 证书没校验参数规则固定Token 生成逻辑在 JS 里Charles / Fiddler / mitmproxy 一开API 路径、参数、返回结构一清二楚。3. 混淆机制非常有限Metro 的 minify ≠ 安全变量名可以还原业务流程完全可读关键算法一览无余JS Bundle 加密方案到底可不可行结论先给出来可行但只能作为第一道门槛。基本思路JS bundle 不明文落盘Native 启动时解密解密后的 JS 仅存在于内存中架构示意加密 bundle → 打包进 assets ↓ Native 启动 ↓ Native 解密 ↓ JS 引擎加载内存代码Android 示例AES 加密 Bundle可运行1. 构建阶段加密 JSopenssl enc -aes-256-cbc -salt\-in index.android.bundle\-out index.android.bundle.enc\-k my_secret_key打包时只放.enc文件。2. Native 解密并加载Androidprivatebyte[]decrypt(byte[]encrypted)throwsException{SecretKeySpeckeynewSecretKeySpec(my_secret_key.getBytes(),AES);CiphercipherCipher.getInstance(AES);cipher.init(Cipher.DECRYPT_MODE,key);returncipher.doFinal(encrypted);}解密完成后直接丢给 RN 引擎加载。安全收益静态分析直接失效拿到 APK 也看不到 JS提高逆向成本注意这不是终极方案只要解密逻辑在客户端就一定能被 Hook。API 安全不要只靠 HTTPSHTTPS 只是“防路人”不是“防攻击者”。HMAC 签名最基础也最有效思路每个请求都带一个签名sign HMAC(secret, path timestamp body)服务端验证签名合法性。JS 侧示例importCryptoJSfromcrypto-js;functionsignRequest(path,body,ts){constrawpathtsJSON.stringify(body);returnCryptoJS.HmacSHA256(raw,SECRET).toString();}服务端校验时间戳是否过期签名是否一致安全效果参数被改签名就不对重放攻击直接失效非对称签名更高安全级别强烈建议签名逻辑放 NativeNative 生成签名私钥存在 Keychain / KeystoreJS 只能调用 Native 方法RN 调用 Native 签名constsignawaitNativeSecurity.sign(payload);JS 即使被扒也拿不到私钥。环境检测越狱 / Root 一定要做很多攻击只发生在 Root / 越狱设备上。Android Root 检测示例publicbooleanisRooted(){String[]paths{/system/bin/su,/system/xbin/su,/sbin/su};for(Stringpath:paths){if(newFile(path).exists()){returntrue;}}returnfalse;}iOS 越狱检测示例funcisJailBroken()-Bool{letpaths[/Applications/Cydia.app,/Library/MobileSubstrate/MobileSubstrate.dylib,/bin/bash]returnpaths.contains{FileManager.default.fileExists(atPath:$0)}}检测到异常怎么办不要直接崩溃容易被绕可以限制功能降级 API关闭关键业务入口后台记录风险设备用原生增强安全是 RN 的正确姿势核心原则安全逻辑尽量不写 JS。适合放 Native 的内容加解密签名Token 生成设备指纹风控策略示例Token 在 Native 生成consttokenawaitNativeSecurity.generateToken();Native 内部读取设备信息加盐时间戳签名JS 永远拿不到规则细节。注意点千万不要依赖单一防护这是最重要的一点。任何单点防护 迟早被破。推荐组合拳防护点作用JS Bundle 加密防静态分析Native 安全逻辑防规则泄露API 签名防抓包篡改Root/JB 检测防 Hook服务端风控最终兜底实际场景我们真实踩过的坑场景 1业务校验写在 JS校验规则被扒黑产直接写脚本刷接口解决校验移到 Native 服务端二次校验场景 2Token 生成在 JS算法被还原请求被批量模拟解决Token 私钥放 KeystoreJS 只拿结果场景 3只做了混淆三天被逆API 全暴露解决多层防护而不是“我做了混淆就安全了”总结RN 项目安全不能指望一个方案解决所有问题。真正靠谱的思路是提高逆向成本缩小攻击面把关键逻辑移出 JS用服务端兜底记住一句话RN 的安全不是“防破解”而是“防滥用 防规模化攻击”