允许断点再传的ftp服务器程序，都必须支持一个“Rest的命令，如果这个命令是用在上传命令前（send命令）， 是告诉ftp服务器我要上传的文件会是从ftp服务器中存在的那个文件的什么位置中开始写。
例子：
假设ftp服务器中存在一个文件Readme.txt，文件大小为1000 bytes，连接上这个ftp服务器（假设我有写权限，ftp服务器是支持断点再传的），我本地中也有一个叫Readme.txt的文件，文件大小为500 bytes。好了，我开始做坏事。
1、连接上这个ftp服务器（用系统自带的 ftp：//ftp.exe/，在内网的可能无法使用，因为 ftp：//ftp.exe/用的是port模式）
2、dir（查看Readme.txt大小，确定了是1000 bytes）
3、quote rest 1000（告诉ftp服务器我将要传送的文件是从文件位置1000开始）
4、send Readme.txt
5、dir（再次查看Readme.txt大小，现在Readme。txt变成1500 bytes了）
为什么Readme.txt会变大了?很简单，因为我本地的那个Readme.txt的500字节上传成功，并写入到ftp服务器中存在的那个1000 bytes的Readme.txt文件中了。问题是出在第二条命令，如果没有第二条命令，我的第4个命令（Send Readme.txt），就会得到一个Permission Deny的错误，第二条命令是让ftp服务器信任我们将要进行一个断点再传的操作，如果没有第二条命令，ftp服务器将以为我们进行的是一个复盖原文件的操作（复盖原文件操作需要另外的权限才可以进行）。
说到这里，大家应该明白了主题的意思了吧，通过很简单的操作，任何具有写权限的用户，都可以改动其它用户上传的文件，单是这一点，就存在很大的安全漏洞了。如果上传的是重要文件，随意的修改可以令文件完全破坏了;如果是可执行文件或一些zip或rar文件，会不会有些熟悉各种文件结构的天才疯子，将一些恶意代码也加到那些文件，令执行者系统受到破坏或者执行了他们的后门代码或其它，由于本身对于这些文件结构并不熟悉，我只说这是一个未知之数。
但在电脑的世界中，很多不可能的事最后都被创造成可能，所以我无法下定论。但单是能破坏到文件这一点，已是很具破坏性了，想想一个500M的影视文件，被人多加了字节进去的话，估计是无法再被观看的了，播放这些文件的程序一般都会说不是合法的影视文件，无法播放等等。至于zip，rar等文件，winzip或winrar肯定会说压缩文件已遭到破坏，crc检验码不对等等的错误。
这个问题只是在允许断点再传的FTP服务中存在，但现在90%的FTP服务程序都是允许断点再传的，所以这问题在普遍的FTP服务器都会存在。
防范方法：
如果一定需要给用户上传权限的话，最好的防范方法是每个用户都给他建立一个目录，将那个用户的权限完全锁在这个目录内，那么用户就没有权限可以查看其它用户的目录，也就是说无法造成以上所说的破坏。
以上所说的在Serv-U V4.0中测试过，测试平台是Win 2K Server。如果其它ftp服务程序不存在这种问题，那不在此文章讨论范围内。 现在windows系统中架设ftp服务器，用得最多最流行的还是Serv-U，所以管理员们要多留心了。这文章并不是要教人做坏事，如果你用这种方法去破坏ftp服务器的文件，唯一要负责任的人是你。引用一句古龙小说中的话：“刀本身并没有错，错的是拿它的手。
