我有一个问题,人们正在将我的网站克隆出来,并模仿自己从自己的域中拨打我的API来滥用我的服务。我提出的解决方案是Angular Client检查其工作的URL,对其进行加密并添加为API调用的标题。混淆JS代码以防止反向工程。这样,API将收到一个加密的标头,并确保该域是适当的标头。
因此,在客户端
headers.append(`CustomHeader`, this.encryptDomain());
和服务器端,
var domainEncrypted = Request.Content?.Headers?.GetValues("CustomHeader").FirstOrDefault();
var domainPlain = Decrypt(domainEncrypted);
if (domainPlain != myDomain)
{
return BadRequest();
}
您可以帮助我使用代码示例与JS和C#加密和解密算法匹配的代码?因此, EncryptDomain
在JS侧工作, decrypt
在C#侧工作。我知道这不是一个完美的解决方案,但我想尝试。如果有人有更好的主意,欢迎您。
编辑:显然我想做的类似于JScrambler域锁定功能
I have a problem that people are cloning my website front and imitate calls to my API from their own domains to abuse my service. The solution I came up with is for Angular client to check the URL it works on, encrypt it and add as a header to API call. Obfuscate the JS code to prevent reverse engineering. This way API will receive an encrypted header and make sure that the domain is the proper one.
So on the client side
headers.append(`CustomHeader`, this.encryptDomain());
and on the server side
var domainEncrypted = Request.Content?.Headers?.GetValues("CustomHeader").FirstOrDefault();
var domainPlain = Decrypt(domainEncrypted);
if (domainPlain != myDomain)
{
return BadRequest();
}
Can you please help me with code samples to match JS and C# encrypt and decrypt algorithms? So that encryptDomain
works on JS side and Decrypt
works on the C# side. I am aware that this is not a perfect solution, but I want to try. And if anyone has a better idea, you are welcome.
Edit: apparently what I want to do is similar to JScrambler domain lock feature
发布评论
评论(3)
TLDR
不可能通过不同的(克隆)客户端与您的API进行通信,以确保在IP地址的白名单不能/不应使用的情况下。
为什么
这样考虑。您的服务器具有某些标识规则 - 客户端应具有将其标记为信任的一些标识符。在您的问题中,这是一个领域。
域是可以在HTTP标头或您的请求正文中传递的公共信息,这很容易,但客户很容易在他们身边替换此信息。
而且,如果您使用任何类型的密码学来提供更安全的识别机制 - 您只是很难入侵它并再次假装作为可信的客户,因为您在客户端使用的每种机制都可以由黑客进行反向工程。只需查看这个问题。
人们认为您可以使用来保证访问限制是在服务器端使用IP地址的白色名单,因为IP地址是TCP/IP传输级别协议的一部分,并且它具有“握手”过程,可以识别彼此的通信点,很难替换它。 Check this question for details.
那你能做什么?
CORS
设置CORS策略是创建可信赖的客户服务器通信的第一步。大多数浏览器是支持CORS政策,但当然客户可能不是浏览器。问题与浏览器服务器的通信无关,但我应该提到,因为浏览器也是客户端。
客户端加密
您可以使用加密,但是我没有任何理由这样做,因为可以通过您的法律客户端(网站)读取对服务器的任何请求。因此,即使您对其进行了加密 - 任何人都有一个钥匙和加密算法,可以假装成为可信赖的客户。但是,如果您想...
您需要创建独特的密钥,每个请求都会使假装的生活更加艰难。为了使其需要很少的成分:
可以轻松地搜索过服务器端的JS端RSA Crypto库的 “ https://stackoverflow.com/questions/12457234/cencrypt-in-javascript-decrypt-decrypt-in-php-using-public-key-cryptography">示例)
obfusccation库也可以找到Google也可以找到(例如 this )
服务器 - )可以用
system.security.cryptography 命名空间(如果使用C#后端)。
基本上,您制作的更复杂的密钥生成算法和您制作的更加迷惑的代码 - 更难将自己假装自己是一个值得信赖的客户。但是,正如我所说,没有保证的方法可以完全识别受信任的客户。
TLDR
It is not possible to prevent communicate with your API through different (cloned) clients guaranteed way in cases when white-lists of IP addresses can't/shouldn't be used.
Why
Think about it that way. You have a server that has some identification rule - client should have some identifier that marks it as trusted. In your question it is a domain.
Domain is a public information that could be passed in HTTP header or in the body of your request, it is easy, but also it will be easy for clients to replace this information on their side.
And if you use any type of cryptography to provide more secured identification mechanism - you just making it harder to hack it and again pretend as trusted client, because every mechanism you use on the client side could be reverse-engineered by a hacker. Just look at this question.
One think you can use to guaranteed access restriction is to use white-list of IP addresses on server-side, because IP address is a part of TCP/IP transport level protocol and it has "handshake" process to identify communicated points to each other, and it is kind of hard to replace it. Check this question for details.
So what can you do?
CORS
Setup CORS policy is a first step to create a trusted client-server communication. Most of browsers are support CORS policies, but of course client may be not a browser. And the questions was not about browser-server communication, but I should mention that because browser is a client too.
Client-side encryption
You can use encryption, but I don't see any reason to do that because any request to server could be read through your legal client (website). So even if you encrypted it - any person has a key and a crypto algorithm on their side to pretend as trusted client. But if you want to...
You need to create unique key every your request to make life of pretenders little harder. To make it you need few ingredients:
JS-side RSA crypto libraries could be googled easily (for example)
Obfuscation libraries could be found just using google too (like this)
Server-side decryption could be done with
System.Security.Cryptography
namespace if you use C# backend.Basically, more complex key-generation algorithm you make and more obfuscated code you make - more hard for hacker to pretend himself as a trusted client. But as I said there is no guaranteed way to completely identify trusted client.
您不能阻止人们复制您网站的FE资产...他们应该公开使用。您可以尝试通过将构建的应用程序插入更多块(具有Angular的Lazzy-Loading或通过操纵WebPack的配置)来使其变得更加困难。尽管如此,浏览器仍需要纯文本代码,因此,尽管这使其难以阻止复制。
当我们为生产构建角度时,它已经通过其
为了减轻人们滥用您的服务器资源的问题,您需要在后端请求授权和一些Miss-usage检测方面实施强大的实践。
配置 cors>成为代理。
确保您的请求的身份验证是可靠的。市场标准方法是使用a jwt 有效载荷嵌入在
授权>授权
每个标题中要求。它是简单,可靠且资源性的。我还建议实施请求节点。但这是一个分开的问题。
如果您的身份验证已经稳定,则需要检测何时您的真实用户滥用系统。有许多工具可以监视流量(例如 a>),但没有针对“异常流量”的伞定义。检测“异常流量”是您为系统细节构建的构建所需的。一旦您拥有一个网络流量工具,就可以帮助您开始。
You cannot prevent people from copying your website's FE assets... They are supposed to be publicly available. You could try to make it a little harder by spliting your built app in more chunks (with angular's lazzy-loading or by manipulating webpack's config). Still, Browsers require code in plain text, so although this makes it a little harder it does not prevent copying.
When we build angular for production it already does code obfuscation through its optimizations (minification, tree-shaking and so on).
To mitigate the problem of people misusing your Server resources, you need to implement robust practices on Back-End request authorization and some miss-usage detection.
Configuring CORS would not work, as you reported attackers are using BE proxies.
Make sure your request's authentication is solid. A market standard approach is the use of a JWT payload embedded in the
Authorization
Header of each request. It is simple, reliable and resource-inexpensive.I would also recommend the implementation of request throttling. But this is a separated question.
If your authentication is already solid, you would need to detect when your real users are misusing your system. There are many tools to monitor traffic (like azure's) but there is no umbrella definition for "unusual traffic". Detection of "unusual traffic" is what you would need to custom built for the specifics of your system. Once you have a network traffic tool in place that should help you getting started.
为您提供几个解决方案。首先,您可以通过在服务器上应用 cors 策略来阻止。如果您仍然想从代码中执行此操作,则可以在此基础上以C#中的主机名为基础。
Couple of solutions for you. Firstly you can block by applying a CORS policy on server. If you still want to do from code then you can block on this basis of hostname in c# like this.