隐藏在程序旮旯中的“安全问题”
作为一个真正的程序员,必须有高度的“安全意识”,因为我们作出的软件运行在复杂的环境中,不能把不该有异常抛给用户,更不能把漏洞留给“黑客”,当然也不能把“操作失误”作为系统出错的理由。
那么我们应该如何才能写出一个“安全”的软件呢?其实问题就在我们的程序旮旯中,看你是否用心去看哪些所有可能引起问题的代码。下面列举一例说明,我们的数据同步程序需要在目标数据库执行一点点(就一点点,你看下面的代码就知道)SQL语句,按照原来的设计,这是不允许的,因为可能引起安全问题,但是现在既然“开了一扇窗”,就要“增加十层网”,我们来看看应该怎么样架起这个防火墙:
PWMIS.DataProvider.Data .AdoHelper db= this.GetDbHelper();
if (tableName == "TB_SYS_SQL")
{
foreach (EntityBase entity in entitys)
{
object obj = entity.PropertyList("sqlstr");
if (obj != null) //@1
{
string sqlstr = obj as string ;//@2
if (!string.IsNullOrEmpty(sqlstr)) //@3
{
//目前只执行该条类型的SQL语句
if (sqlstr.ToLower().StartsWith ("delete from jjzb")) //@4
{
int count = db.ExecuteNonQuery(sqlstr.Split (';')[0]);
//@5,过滤;号后的其它语句,避免SQL注入
this.Talk(string.Format("执行SQL语句{0} ,{1}行记录受影响。 ", sqlstr, count));
}
}
}
}
}
--------------------
我们来仔细分析上面的代码是怎么遵循“安全意识”的,
@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{...} 不就好了吗?这只是掩盖了问题当并没有解决问题。
“不要相信别人给你的任何输入”,谁知道这是仙女还是魔鬼呢?
安全问题无处不在,仔细检查一下你的程序旮旯,不要放过它,否则,你就可能后悔,“成功近在咫尺”却又“檫肩而过”。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构