现在越来越多的网站是架构在数据库上的，而且使用微软的SQL Server数据库的占很大比例，而数据库的安全也是常常被管理员忽略的。下面我们要说的，并不是SQL Server存在的漏洞，而只是一些安全缺陷，存在的一些问题，当然这些问题是SQL Server一产生的时候就存在的。

　　1、MS SQL Server的Frethem/index.htm" target="_blank" style='text-decoration: underline;color: #0000FF'>密码明文传输缺陷

　　 很倒霉，我没有在微软发布SQL Server的时候做下面的分析。当我吃惊地发现SQL Server竟然是使用明文进行密码传输的时候，我就马上去查阅是否有这些资料。可惜已经早早有人提出能够用sniffer获取SQL Server的密码了。不过，既然微软这么大胆，我们还是去看看，分析分析这个缺陷。

　　当然，SQL Server的连接过程还是先进行TCP连接的三次握手，同服务器建立连接过后，然后进行TDS（tabular data stream）协议的数据交流，可惜的是我一直没有找到TDS协议的具体描述，只有一些片段，所以，都只能一点点地对着数据报分析。

　　直接到login包吧，你会发现，你的用户名完全是明文的，而密码还不是。当你改变密码的时候，你可以看出，相同字符的编码是一样的，密码字符之间用一个相同的字符作为分隔“a5”。呵呵。所以，最傻的办法就是我做的这样，一个字符一个字符地改变密码，然后得到所有字符的对应编码（我不会解密）。

　　我使用的是SQL Server 2000 。我这里列举得到的对应编码。大家可以根据我的笨方法很容易得到完整的字符编码。

　　a —— 0xb3 A —— 0xb1

　　b —— 0x83 B —— 0x81

　　c —— 0x93 C —— 0x91

　　d —— 0xe3 D —— 0xe1

　　e —— 0xf3 E —— 0xf1

　　f —— 0xc3 F —— 0xc1

　　g —— 0xd3 G —— 0xd1

　　h —— 0x23 H —— 0x21

　　i —— 0x33 I —— 0x31

　　j —— 0x03 J —— 0x01

　　k —— 0x13 K —— 0x11

　　l —— 0x63 L —— 0x61

　　m —— 0x73 M —— 0x71

　　n —— 0x43 N —— 0x41

　　o —— 0x53 O —— 0x51

　　p —— 0xa2 P —— 0xa0

　　q —— 0xb2 Q —— 0xb0

　　r —— 0x82 R —— 0x80

　　s —— 0x92 S —— 0x90

　　t —— 0xe2 T —— 0xe0

　　u —— 0xf2 U —— 0xf0

　　v —— 0xc2 V —— 0xc0

　　w —— 0xd2 W —— 0xd0

　　x —— 0x22 X —— 0x20

　　y —— 0x32 Y —— 0x30

　　z —— 0x02 Z —— 0x00

　　` —— 0xa3 ~ —— 0x42

　　1 —— 0xb6 ! —— 0xb7

　　2 —— 0x86 @ —— 0xa1

　　3 —— 0x96 # —— 0x97

　　4 —— 0xe6 $ —— 0xe7

　　[iduba_page]

　　5 —— 0xf6 % —— 0xf7

　　6 —— 0xc6 ^ —— 0x40

　　7 —— 0xd6 & —— 0xc7

　　8 —— 0x26 * —— 0x07

　　9 —— 0x36 ( —— 0x27

　　0 —— 0xa6 ) —— 0x37

　　- —— 0x77 _ —— 0x50

　　= —— 0x76 + —— 0x17

　　 —— 0x60 | —— 0x62

　　[ —— 0x10 { —— 0x12

　　] —— 0x70 } —— 0x72

　　’ —— 0xd7 " —— 0x87

　　, —— 0x67 < —— 0x66

　　. —— 0x47 > —— 0x46

　　/ —— 0x57 ? —— 0x56

　　 : —— 0x06

　　 对了，在SQL Server中不支持用 ; 符号作为密码，如果你在用这些字符作为密码的话，那就糟糕了，你永远也登陆不上了，除非更改密码。

　　 在TDS数据报的头中规定了一个字节来表示数据报类型，我探测到的是0x10，而我得到的资料说是用0x02来表示Login的数据报，可能是MS SQL Server在协议上有一些改动，因为Sybase也是使用的TDS协议的，那么Sybase可能也是使用的明文传输吧，我手里没有Sybase。

　　不过MS对SQL Server的传输还是提供加密办法的，你可以使用SSL来加密。于是我也试了试，可以在实例属性的网络配置里面选择强制协议加密，然后要求你重新启动SQL Server，呵呵，然后呢，你启动起来了么？哈哈，我可是吃了亏的。因为没有SSL证书，所以，你一启动就错误，事件日志中说明是没有提供有效的证书。重新安装吧。该死的MS也不在我选择的时候提醒一下。

　　 嗅探得到数据库帐号意味着什么？如果能够得到SA帐号呢？哈哈，有兴趣可以看看我前些天写的《从IIS转到SQL数据库安全》。

　　2、明文的数据传输缺陷

　　 如果没有使用加密的协议的话，那么整个数据库的网络数据都是没有加密的，而且是明文传输。无论是从客户端发送命令还是从服务器端得到结果，都是明文传输的。看来，如果你用加密的协议，微软是不会为你做任何安全防护的。我想，目前国内使用的SQL Server数据库差不多都是没有使用SSL来加密，看来在网络上能得到不少东西。

　　3、神秘的1434端口和服务器信息明文传输缺陷

　　对于SQL Server2000来说，打开SQL Server客户端准备连接，当拉开服务器列表的时候，整个局域网所有的SQL Server服务器都被列出来了。于是我发现，从我自己的机器(192.168.0.1)上从1434端口广播(192.168.0.255)了这个UDP包，然后，整个局域网中的SQL Server服务器都开始响应这个UDP数据包，这时，我的客户端能够得到所有服务器信息。

　　这就是客户端进行连接的过程：当客户端连接到服务器时，应用程序请求连接远端计算机，Dbnetlib.dll 将打开到连接中所指