一、反攻击技术的核心问题

这里的所谓“Web源代码”，指的是客户端的诸如HTML、Javascript之类的东西，当你辛辛苦苦写出来一个web应用程序时，可能希望自己的劳动成果不被别人任意剽窃修改，但是这些东西如果不加处理，很容易被人拷贝。

其实说实话，我个人认为，作为描述性的语言，web源代码没有经过编译，也就是说，无论怎么加密，它在客户端都会最终以源代码形式出现，要绝对的防止被察看是不可能的。但是，我们还是要讨论这个问题，因为虽然没有绝对，但是相对比较安全就好了，正如系统的安全没有绝对，只有相对一样。只要能让绝大多数人束手无策，我们的目的也就达到了。

首先，禁止右键是一个比较常见的方法，这无论如何是不能彻底阻止用户察看源代码，但是既然无法防止用户察看代码，就只能把代码加工，让人看了也无法理解其意义。

一个比较经典而有效的方法是利用的js的escape方法，将源代码经过escape 编码后，大部分文字被转换成了型如%xx的编码，unicode字符被转换成%uxxxx格式，于是看起来一片混乱。使用的时候先将这段编码作为数据，利用unescape转换回原貌，再用js写进需要的位置，于是便可正常使用了。

这个方法原理简单，而且可以反复调用，将源代码经过数层加密(将解密的程序本身也作为源代码进行加密)，已经足以让大部分的人摸不着头脑了。他的缺点是编码效率不高，经过编码后数据量增加很多。而且这种编码要解也很容易。

仿照这个原理，其实你可以自己写出自己的算法来代替escape，不过因为这个部分源代码也是明文，所以其实意义不大，只能唬唬那些利用现成工具解码的人，稍微会编程的人都可以利用你的源代码部分，修改一下输出，得到你的代码明文。

作为全球最大的软件商，微软公司也意识到了脚本的知识产权保护问题，因此在IE5以上的版本里加入了对编码脚本的支持，这里的“编码”和上面所述的略有不同，这是通过微软专门的wse(windows script encoder)进行脚本编码，其范围也不仅仅局限于客户端脚本，它也可以对wsh，甚至服务器端的ASP脚本进行编码，经过编码的脚本看起来是一堆乱七八糟毫无疑义的字符(好像unicode会不经编码原封不动的保留下来)。

在运行的时候在脚本引擎内部进行解码，由于解码算法是脚本引擎内置的，所以一般人难以解出源代码。另外，由于解码中要进行完整性效验，即使unicode以原码显示出来了也不能被修改，修改哪怕是一个字节，就会使整段代码失效。

这个方法目前看来很安全，还没有现成的工具对其进行破解。但是要知道，这些算法是可逆的，也就是说迟早会有人找出其算法，我甚至猜测script engine本身提供了编码解码的接口，可以直接调用的。解密工具迟早要出来。而且这个加密方法有个很大的缺陷，就是必须要求IE5以上才能用，要知道，IE4的用户不在少数，因此在很大程度上限制了推广使用。

真的没有两全的办法了吗？

写到这里，我自己产生了一个想法：利用随机密匙+固定或随机算法进行加密，只是一时想法，还不成熟，而且也只是可以骗过一般人而已，不妨写下来供参考：

先想一种需要密匙的算法，比如xor，在服务器端写好加密算法，当用户访问此页的时候生成一个随机密匙，将解密算法以及加密后的数据发到客户端页面上，而在之前将此次会话生成的密匙通过某种特别途径发给客户端(比如服务器发来的 cookie)，然后在客户端读出cookie里的密匙进行实时解密。

由于不带过期参数的cookie是存在内存里的，在硬盘里找不到，因此除非用户知道写cookie的那个页面并且察看其http头(同时还要向服务器发去维持本次会话的sessionID以防止密匙改变)，否则是无法解密的。由于向客户端发送cookie的页面可以随机(可以在加密页面出现之前的任意页面)，而且密匙甚至算法均可随机，找到密匙，算法，数据三者相对应的过程相当之繁琐，可以吓倒不少的人。

这种加密法是否可行还有待探讨，只是我一时想法而已，有空的时候我会试验一下，看看到底能不能用。

二、反攻击技术的核心问题

反攻击技术(入侵检测技术)的核心问题是如何截获所有的网络信息。目前主要是通过两种途径来获取信息，一种是通过网络侦听的途径(如Sniffer，Vpacket等程序)来获取所有的网络信息(数据包信息，网络流量信息、网络状态信息、网络管理信息等)，这既是黑客进行攻击的必然途径，也是进行反攻击的必要途径;另一种是通过对操作系统和应用程序的系统日志进行分析，来发现入侵行为和系统潜在的安全漏洞。