编程的坏习惯之备份文件

有一些文本编辑器，比如Editplus，Ultraedit等，默认有保存备份文件的功能，就是保存一个和原文件同名的.bak文件，出发点是好的，可以避免文件的误删，可是在做B/S系统时，这种方法却能造成很大的安全隐患。这篇文章我用一个例子进行Sql注入破坏数据库来演示这种安全隐患。

1. 当然这里我要假设Editplus的自动备份功能并没有取消，而是自动生成了.bak文件，而我们没有意识到这种文件的危害，把这个文件一起拷贝到了我们的项目文件夹下（这种情况经常发生），假如说这个文件叫做insertuser.jsp，那么备份文件叫做insert.jsp.bak，我们把这两个文件放在同一个文件夹下，这时候你输入insert.jsp的地址，要保证这个文件能被访问；
2. 如果我是一个黑客，我现在不按照套路出牌，我并不输入insert.jsp这个文件的地址，而是使用insert.jsp.bak这个地址来代替，那么我们可以看到，浏览器告诉我，我可以下载这个.bak文件；可能你会说：谁会想到要输入这个地址啊？可是这是安全隐患，你不会输入并不代表黑客也不会输入，所有的安全隐患都是很隐蔽的，但是仍然被黑客们发现，所以，不要存在侥幸心理；
3. 好了，我下载下载回来这个文件了，我使用文本编辑器打开，这时候我能够看到这个文件的全部内容，如果你的sql语句也是写在这个jsp页面的话，那么很可能是这样的：insert into userdata (……)  values (……)，如果是这样的话，那好了，我就可以知道，你现在的这个数据库是用userdata这个表来存储用户的数据；
4. 我们继续，如果你的系统同样提供了删除用户的功能，那么大概是这样子的deleteuser.jsp?id=3；这时候进入页面，然后你的sql语句这样写：delete from userdata where userid=3，相信我：绝大多数人都是这么写的；
5. 最后我们来进行sql注入，在使用deleteuser.jsp?id=3来使用的，这时候我仍然不按照常理出牌，我手动进行输入，输入的格式如下：deleteuser.jsp?id=3 drop table userdata；我们来看一下最后的sql语句变成了什么：“delete from userdata where userid=3 drop table userdata”，在删除一个用户的同时，我把userdata这个表删除了！这是最基本的sql注入攻击，简单但是对于安全级别低的系统绝对适用，别的不说，我可以使用这个方法把我们从前做的大多数系统摧毁！

我们来看造成这种情况的条件（所有我列出的都是应该避免的）：

1. .bak文件，这个可以说是罪魁祸首，这个文件的下载直接导致了数据库的结构暴漏了，至少暴漏了很多重要的信息；（这个很容易避免）
2. 把sql语句写在前台，我们在使用MVC之前一直这么做，这也是我们要把业务逻辑隐藏在bean里面的原因之一：安全！（在php中比较困难）
3. 对于delete这样的逻辑，没有对其输入进行任何判断，至少我们应该看一下它是不是一个整数吧，可惜，我们没有。

因此我们要避免上述的情况，减少安全隐患。