Protect the source code of your Web program

The so-called "Web source code" here refers to things such as HTML and Javascript on the client side. When you work hard to write a web application, it may be hoped that the fruits of your work will not be arbitrarily plagiarized or modified by others. However, if these items are not processed, they will be easily copied.

To be honest, I personally think that, as a descriptive language, the web source code is not compiled, that is, no matter how encrypted, it will eventually appear in the form of source code on the client, it is absolutely impossible to prevent being viewed. However, we still need to discuss this issue, because although it is not absolute, it is relatively safe, just as the security of the system is not absolute. As long as we can make the vast majority of people helpless, our goal will be achieved.

First, disabling right-click is a common method. In any case, it cannot completely prevent users from viewing the source code. However, since it cannot prevent users from viewing the code, they can only process the code, people cannot understand what it means.

A classic and effective method is to use the js escape method to convert most of the source code into code such as % xx after being encoded by escape, unicode characters are converted to % uxxxx format, so it looks messy. When using the code, use the Code as the data, convert it back to the original appearance using unescape, and then use js to write it into the desired location, so it can be used normally.

This method is simple in principle and can be called repeatedly. The source code is encrypted through several layers (the decrypted program itself is also encrypted as the source code), which is enough for most people to be confused. His disadvantage is that the encoding efficiency is not high, and the data size increases a lot after encoding. This encoding is also easy to understand.

Based on this principle, you can write your own algorithms to replace escape. However, because this part of the source code is also plain text, it is of little significance. You can only refer to people who use ready-made tools to decode escape, programmers can use your source code to modify the output and obtain the plaintext of your code.

As the world's largest software vendor, Microsoft is aware of the intellectual property protection of scripts. Therefore, it has added support for coding scripts in IE5 or later versions, the "encoding" here is slightly different from the above mentioned. This is based on Microsoft's dedicated wse (windows script encoder) for script encoding, and its scope is not limited to client scripts, it can also encode wsh and even the server-side ASP scripts. The encoded scripts seem to be a bunch of messy and unambiguous characters (as if unicode will be retained without encoding ), decoding is performed inside the script engine during running. Because the decoding algorithm is built in the script engine, it is difficult for people to solve the source code. In addition, because integrity verification is required in decoding, unicode cannot be modified even if it is displayed as the original code. If it is modified to a byte, the entire code segment will become invalid.

This method seems safe at present and there are no ready-made tools to crack it. But you need to know that these algorithms are reversible. That is to say, someone will find out their algorithms sooner or later. I even guess the script engine itself provides an encoding and decoding interface that can be called directly. The decryption tool will come out sooner or later. In addition, this encryption method has a major defect, that is, it must require IE5 or above for use. You must know that there are not a few IE4 users, so it restricts the promotion and use to a large extent.

Is there really no solution for both sides?

Here, I came up with an idea: using random keys + fixed or random algorithms for encryption is just a temporary idea, not mature yet, and can only cheat ordinary people, write it down for reference:

First, consider an algorithm that requires keys, such as xor. Write the encryption algorithm on the server side. When a user accesses this page, a random key is generated, the decryption algorithm and encrypted data are sent to the client page, and the key generated by the session is sent to the client in a special way (such as the cookie sent by the server ), then, the client reads the key in the cookie for real-time decryption. Because cookies without expired parameters exist in the memory, they cannot be found in the hard disk, therefore, unless you know the page on which the cookie is written and view its http header (you must also send the sessionID to the server to maintain the session to prevent the key from changing), the decryption will not be possible. Because the page sending cookie to the client can be random (any page before the encrypted page appears), and the keys and algorithms can be random, the keys and algorithms can be found, the corresponding process of data is rather complicated, which can scare a lot of people.

Whether this encryption method is feasible remains to be discussed. I just want to try it out when I have time.