有什么办法只允许我开发的 APP 访问我的 WEB 服务吗？

• 資深大佬 : Xusually

  额。。最简单的就做个登陆认证呗

• 資深大佬 : clf

  自己对客户端加壳加密呗。

• 資深大佬 : AoEiuV020

  破解只有成本问题，你 app 能访问的那别人就能模拟你的 app 去访问，不可能杜绝，考虑安全也要基于这一点再考虑，做成哪怕客户端被破解被模拟也没问题，

• 資深大佬 : neptuno

  可以考虑 1 、客户为什么用其他工具访问你的 web 服务呢（可以加一些 c#专属功能，让其他工具体验变差） 2 、如果是预防不法分子，那就混淆+各种加密，增加成本

• 主 資深大佬 : villivateur

  @Xusually
  @neptuno
  @clf
  客户端需要访问 WEB 端，并请求解密一段二进制，然后把二进制烧录到下位机。主要是防止别人得到明文的二进制。
  所以对用户而言，他不需要认证就可以使用 APP 。

• 資深大佬 : lower

  搞个白名单呗，，只允许客户的 ip 访问

• 資深大佬 : bootvue

  双向 ssl 验证

• 資深大佬 : ch2

  @villivateur #5 使用一次性密钥

• 資深大佬 : coderluan

  很多防盗措施都是自己想多了，对方要有这个能力这活也没必要给你了，相反如果你确认有人想盗版你的软件或者盗用你的服务，那么比起防止被盗，更好的手段是鉴别非法访问然后埋雷，设置成积累到一定程度再引爆，然后就轮到你坐地起价了。

• 資深大佬 : r007b34r

  第三方验证码接口二次认证结果生成匹配的随机浏览器 UA 指纹访问，非匹配 UA 直接拒绝响应。

• 主 資深大佬 : villivateur

  @lower 但这样防不了客户
  @bootvue 客户端的私钥如何保密？

• 資深大佬 : 0o0o0o0

  关键部分用 c++写，然后调用

• 資深大佬 : billgong

  @villivateur 加密狗或者 TPM 就是干这个的

• 資深大佬 : Ediacaran

  找几个重要的工作参数，通过页面内嵌的元素获取

• 資深大佬 : jucelin

  https 用自签证书

• 資深大佬 : Ediacaran

  @Ediacaran 好吧看错了内容。
  每次发布都携带公钥。这样被破解了也知道谁干的

• 資深大佬 : emeab

  mtls 啊.

• 資深大佬 : PerFectTime

  登记著作权，抓到就起诉

• 資深大佬 : dingwen07

  居然没有人提到 HTTPS 客户端验证？
  自建一个 CS ，然后给每个客户端颁发一个证书，发现泄漏就吊销掉那个证书。

• 資深大佬 : libook

  C#有混淆工具吧，把代码混淆后可以提高逆向难度。有条件的话做加壳。同时可以加一些反调试方案，检测到被调试就直接退出，或者进入假逻辑。
  HTTPS 只能起到点对点数据加密，不能做到客户端识别，你可以设置成仅信任你用的签发机构的证书，避免使用自签通配符证书来抓包。
  客户端发数据给服务端的时候给 payload 做签名，签名一定要涉及时间戳，避免有破解者直接构造网络请求发给服务器。而且可以做个 ban IP 的策略，一旦接收到签名错误的请求就把 IP ban 一段时间。

• 資深大佬 : libook

  看到补充内容，破解思路其实就是调试你的程序，找到解密二进制之后的程序，把解密后的内容从内存里读出来。
  你要做的就是让破解者更难以调试出可以拿到解密内容的地方，比如解密方法的返回值，以及烧录方法的参数。
  另一个思路就是者拿到解密内容也不能用，比如解密的内容不是通用的，仅当前烧录的设备可用。

• 資深大佬 : masterclock

  简单加密一下就行了，别搞复杂了
  如果有人搞破解，说明你的服务端做得真 TMD 好，还做什么客户端，收服务端的钱就得了

• 資深大佬 : skiy

  微信扫码登录（逃

• 資深大佬 : s0nnse

  HTTPS 双向证书 差不多了，app 有破解风险就上 app 加固。

• 資深大佬 : powerman

  没有这个必要，微信搞得这么复杂，不还是有人去研究破解微信的协议，想啥呢，老哥，只要有利益驱动，自然有人去研究你的协议，技术手段只是防止对方低成本破解罢了。

• 資深大佬 : devcat9

  ssl pinning
  GRPC 证书

• 資深大佬 : tmtstudio

  AES+RSA

• 資深大佬 : zzzmh

  虽然 C#我是外行，但这个前提来说我感觉几乎做不到，再强的 app 也能被破解，就是值不值得和有没有人折腾的问题。你能做的就是请求全部加密，客户端加壳加密，但也就防住 99%的人了。如果要彻底防住，加个用户名密码，加个 token ，然后可以把没密码的人防住，但这也就不符合你的需求了。

• 資深大佬 : zjsxwc

  隔三差五更换 api ，发布新版本呗

• 資深大佬 : 2i2Re2PLMaDnghL

  首先明确一个问题
  只允许我开发的 APP 访问我的 WEB 服务 —— 这是不可行的
  禁止别人开发的 APP 访问我的 WEB 服务 —— 这是可行的
  我直击一个本源：如果别人搞一个虚拟的下位机把你的 App 烧录的内容截取下来，你怎么处理？
  如果下位机设备你可控，那就在下位机上做处理。
  如果下位机设备通用且你不可控，那就把这个二进制进行等功能性的混淆，尽管可用但几乎不可读更难以下手修改。

• 資深大佬 : excitedXXX

  效验 app 签名的 MD5 不知道这个思考可行不

• 資深大佬 : jmk92

  最好加商业壳，不然即便是混淆也容易搞出来源码，源码到手，你怎么写加密过程都没意义了，他完全可以提取出来。
  不需要登录，那么你针对人群有限的话可以搞双向证书，如果是面向全网都可以下载的，那就做机器码、AES 加密。
  当然，前提还是加壳，不然一直盯着数据统计，看有没有虚假请求，也能累坏你啊

• 資深大佬 : bruce0

  不想被别人调用服务 HTTPS 双向认证应该能满足你的需求, 如果怕别人破解 app 拿到证书, 用 C++写相关的代码, 加大反编译难度

• 資深大佬 : ivan_wl

  我和你的场景差不多，可以用 ReadyToRun 做 AOT 编译，编译成 native 指令，至少增加破解难度。客户端认证可以用 WatsonTcp ，支持双向证书认证。客户端的私钥可以混淆后嵌入到 resource 里，代码里处理一下。

• 資深大佬 : dadachen1997

  添加一个 header 字段吧，x-functions-key 做 check

• 資深大佬 : ZeroClover

  加钱 VMProtect ，除非你的 App 有很大的商业价值否则不会有多少人愿意搞动态分析的。
  然后 TLS 相互认证。

• 資深大佬 : ColinWei

  Dnguard HVM 用好几年了，火车头也是用这个

• 資深大佬 : march1993

  下位机读取网卡的 mac 然后用代码验证

• 資深大佬 : 22too

  加一个识别，每次访问必须上传口令，口令认证在另外一个域名下。口令成功，然后再使用口令给业务的域名使用。应该就切割开了。

• 資深大佬 : XiLingHost

  每次访问服务端生成一个二进制可执行文件，然后覆写本地的程序用于下次请求，结合服务端 /客户端双向签名认证，一次访问生成一次新的证书并吊销旧证书，证书加密硬编码在二进制文件中

• 資深大佬 : IvanLi127

  只要经常无故崩溃，应该能让想破解的人崩溃

• 資深大佬 : dingwen07

  @XiLingHost #40 这算任意代码执行漏洞了

• 資深大佬 : robinlovemaggie

  参考银行的做法，强加密和强认证

• 資深大佬 : SIGEV13

  双向认证。
  再强点可以用智能卡、TPM 等硬件。

• 資深大佬 : akira

  客户端上 2 步验证，绑定手机 绑定 ip

• 資深大佬 : passerbytiny

  “只允许我开发的 APP 访问我的 WEB 服务，但用户不用登录”，这并不是无需认证，而是认证规则从“用户”，变成了“应用程序”。这当然是可以做的，从应用分发 /购买上加密钥就能实现，典型的就是物理密钥——加密狗。
  移动平台下，理论上更好做，比如说付费解锁功能的验证。 你可以尝试借助付费验证来做认证：把访问后台的客户端功能，做成一个 1 分钱解锁的客户端功能；同时，把付费验证信息，作为后台接口的动态认证令牌。

• 資深大佬 : 2bNot2b

  必须登录+双向证书认证+参数校验+商业壳基本就稳了

• 資深大佬 : gollwang

  你能同时在两个手机登录微信吗？
  不行的话，这是不是一种思路

• 資深大佬 : pkoukk

  混淆一下就行了，没必要整那么复杂。
  市面上非常多的正在运行的 APP 连混淆都没做，其中不乏一些不小的公司产品

• 資深大佬 : duanxianze

  这个思路本身不合理，上一个老哥说的对，如果你的服务真的那么好，值得别人来破解你的客户端，那么你直接对服务收费就好了，花费大力气加密流程得不偿失。

• 資深大佬 : zhw2590582

  真的有人会为了访问接口，去反编译你的 app 吗，这么值钱的话

• 資深大佬 : rehoni

  单点登录，两步验证，IP 限制；感觉都是思路

• 資深大佬 : cppc

  看了主的附言，目的是保护从服务端下载到的数据不被窃取。但这是个不靠谱的需求，因为别人已经下载了，你光想着保护传输过程没用呀。

• 資深大佬 : 009694

  换个思路 。 不要在 windows 里做加密防护，在下位机做。 你可以把二进制代码段做一个加密，由下位机写入的时候解密，密钥内置在下位机里

• 資深大佬 : tyrantZhao

  白名单服务,特定 IP 可以访问