隐藏在程序旮旯中的“安全问题”

--作为一个真正的程序员，必须有高度的“安全意识”，因为我们作出的软件运行在复杂的环境中，不能把不该有异常抛给用户，更不能把漏洞留给“黑客”，当然也不能把“操作失误”作为系统出错的理由。

    那么我们应该如何才能写出一个“安全”的软件呢？其实问题就在我们的程序旮旯中，看你是否用心去看哪些所有可能引起问题的代码。下面列举一例说明，我们的数据同步程序需要在目标数据库执行一点点（就一点点，你看下面的代码就知道）SQL语句，按照原来的设计，这是不允许的，因为可能引起安全问题，但是现在既然“开了一扇窗”，就要“增加十层网”，我们来看看应该怎么样架起这个防火墙：

 1 PWMIS.DataProvider.Data .AdoHelper db= this.GetDbHelper();
 2 if (tableName == "TB_SYS_SQL")
 3 {
 4    foreach (EntityBase entity in entitys)
 5    {
 6       object obj = entity.PropertyList("sqlstr");
 7       if (obj != null) //@1
 8       {
 9            string sqlstr = obj as string ;//@2
10            if (!string.IsNullOrEmpty(sqlstr)) //@3
11            {
12                  //目前只执行该条类型的SQL语句
13                  if (sqlstr.ToLower().StartsWith ("delete from jjzb"))  //@4
14                  {
15                      int count = db.ExecuteNonQuery(sqlstr.Split (';')[0]);
16 //@5,过滤；号后的其它语句，避免SQL注入
17                      this.Talk(string.Format("执行SQL语句{0} ，{1}行记录受影响。 ", sqlstr, count));
18                  }
19            }
20      }
21   }
22 }
23 
24 

我们来仔细分析上面的代码是怎么遵循“安全意识”的，

@1，先判断 obj 是否为空，如果不判断，下面的代码就可能出错；

@2，将 变量 obj 转换成一个字符串对象，如果使用下面的方式转换，有可能出现错误：

string sqlstr=(string)obj;

当然还有其它安全的转换方式，大家可以去找找看；

@3，转换可能不成功，需要再此判断字符串对象是否为空引用或者空字符串，否则下面的查询会出错；

@4，sqlstr.ToLower()，确保它可以和后面的字符串比较，避免大小写问题；

@5，sqlstr.Split(';') 这句将输入的SQL字符串进行拆分，为什么要这样做？我们看看加入它的值是下面的 SQL语句会在呢么样：

delete from jjzb where jjdm='KF001' ;drop table tb_user--

如果有人哪天输入了这样的一条语句，那DBA或者系统管理员就该哭死了，sqlstr.Split(';')[0] 确保程序只会执行分号前面的SQL语句（该语句在步骤4已经确保安全了），从而不会有SQL注入的问题。

    也许有人说了，这些SQL语句是我用后台管理工具输入的，很安全，可以确保没有问题，不用这么麻烦来判断吧？也许你只输入了一个空格，也许你的数据在传输过程中被黑客截获... ...

    也许，你也会说，加一个 try{...}catch{...} 不就好了吗？这只是掩盖了问题当并没有解决问题。

“不要相信别人给你的任何输入”，谁知道这是仙女还是魔鬼呢？

安全问题无处不在，仔细检查一下你的程序旮旯，不要放过它，否则，你就可能后悔，“成功近在咫尺”却又“檫肩而过”。