我是老杨

志存高远,厚积薄发

编程的坏习惯之备份文件

有一些文本编辑器,比如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这样的逻辑,没有对其输入进行任何判断,至少我们应该看一下它是不是一个整数吧,可惜,我们没有。

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

为您推荐

  1. ZY说道:

    嘿嘿,学习了,继续写啊,这才是老大的风范,给我们铺平道路, :emotion525

    1. 老杨说道:

      呃,我现在一直在怀疑你们到底能不能理解

      1. ZY说道:

        哈哈,不听老人言,吃亏在眼前,理不理解吃过亏就知道了,别那么无奈啊,感觉我们那么不懂事,:emotion57

        1. 老杨说道:

          其实你们已经很懂事了

  2. 亦歌说道:

    不错,学习了,以前根本不太注意这个问题。

    1. 老杨说道:

      一般不会出问题的

  3. Hope说道:

    踩一下,嘿嘿……

  4. chanthon说道:

    可惜的是人人都有一定程度的上的侥幸心理。。

    你写的是编程的坏习惯,
    其实说的是生活中的坏习惯。

    1. 老杨说道:

      差不多,这些都是相通的

  5. 留个印儿说道:

    SVN啊SVN,备份的习惯,文档的习惯大家一定要注意啊~

    1. 老杨说道:

      你说的整个跟我这篇文章没什么关系吧

发表评论

电子邮件地址不会被公开。 必填项已用*标注