一个SQL Injection漏洞在SDL流程中的闯关历险记

原文出处：微信公众号网络安全生命周期

前言

众所周知，产生SQL注入漏洞的根本原因是SQL语句的拼接，如果SQL语句中的任何一部分（参数、字段名、搜索关键词、索引等）直接取自用户而未做校验，就可能存在注入漏洞。

攻击者通过构建特殊的输入作为参数传入服务器，导致原有业务逻辑中原有的SQL语句的语义被改变，或改变查询条件，或追加语句执行恶意操作，或调用存储过程等。

在公司没有实施SDL流程之前，

代码通常是这样写的（以互联网公司常用的PHP语言为例）：

$id=$_GET['id'];
$conn=mysql_connect($dbhost,$dbuser,$dbpassword) or die('Error: ' . mysql_error());
mysql_select_db("myDB");
$SQL="select * from myTable where id=".$id;
$result=mysql_query($SQL) or die('Error: ' . mysql_error());

很显然，大部分教科书也是类似这样编写的，将SQL指令和用户提交的参数拼接成一个字符串，然后提交查询。

开发完成后，经过简单的功能及性能测试，就直接上线了。

一般过不了多久，就会有漏洞报告过来。

但这绝对不是安全上的最佳实践。

让我们来看看实施SDL流程之后，是如何在每一个关卡拦截漏洞的。

需求阶段有将安全纳入需求的要求，但针对此例暂时略过不提；

方案/设计阶段，还没有开始编码，此漏洞暂不涉及，我们直接从开发阶段开始。

假设开发人员没有安全意识，是按照前面存在风险的拼接SQL的方法编码的，让我们来看看一个SQL注入漏洞将要如何闯过项目的各个关卡，存活到最后。