一次恶心而诡异的SQL拒绝服务攻击

已经很久没有在这圈里转悠了，有点开始脱节了，也不知道有没有人用过相同的方法（估计也没我这么恶心的人），如果有请首创者多多见谅。 　　事情是这样，前几天去巴黎，约一个兄弟酒馆吹牛，他刚给学院设计了一个PHP+MySQL的公告板系统，号称在Web层面上是无懈可击的。这算是个Challenge吧，我就拿了他的源代码过来读，在针对XSS和SQL Injection方面的功夫算是做足了，一个典型的瓶颈设计：所有的查询经过 "db" 类的 "query()" 函数，query函数调用sec_check对所有的用户输入进行安全检查，确认无误后再执行mysql_query。 　　sec_check函数进行类型检查,编码检查,敏感字符过滤一堆一堆的项目，反正是为了安全豁出效率去了，至少在我的水平层面上已经看不出有什么破绽。不过他的一段“发布帖子”功能设计让我觉得很有趣（示范代码片断）：     //此处省略一堆代码     $columns = $values = ""; 　　foreach($_GET as $key=>$value)     {          sec_check($key);    //对键进行安全检查          sec_check(%value);  //对值进行安全检查           $columns .= $key.",";  //要插入的字段列表          $values .= $value.","; //要插入的值列表     }     //这里trim掉最后的","　省略...     mysql_query("INSET INTO posts( {$columns} ) VALUES( {$values} )"); 　　他为了省事，也怕需要构造太长的查询语句而遍历所有$_GET数组的元素，用键名和值自动构造查询语句进行修改记录的操作，同样的代码也出现在 “注册会员”功能中。这貌似没什么可玩的，因为sec_check已经把安全检查做到了位，不过……嘿嘿，我再三确定，只要我能有效地破坏他的程序，今天的酒钱他得来付，他说任何"攻击"都可以，只要在web层面。 　　那就别怪我恶心了。通过观察数据库的表结构，发现'id'是一个自增唯一编号主键，类型为MEDIUMINT 为了简单起见我们就假设他是TINYINT 反正原理都一样, 这个类型的取值范围是1-255(好像不会从0开始编号, 习惯了C没...)。而且SQL有一个特性, 主键不允许重复, 自增列会根据最大的那个ID继续++进行编号。 　　哪有什么用呢? ID一般不会被大家考虑在可利用的字段内。但是，因为这个程序的逻辑设计问，如果我们提交了一个名为id的字段，那个插入的新纪录的id字段就是我们制定的值了。那么我们构造URL:  localhost/newpost.php?id=255&title=something.....  这样一个新的帖子的ID就是255。 　　255已经到达TINYINT类型的上限, 如果再有人要发帖子, SQL就会出错. 成功D.O.S了该系统! 　  不仅仅是INSERT, 继续读代码, 同样逻辑还出现在“编辑用户资料”功能中，但是这次他的UPDATE语句是这样的：      UPDATE SET {$key} = {$value} WHERE id = {$_SESSION['ID']}    还好是session （也是做法）要是直接从表单取ID值倒直接可以改任意用户密码了（好像2006年的时候一个论坛就出过这种漏洞）。 同样的方法构造一个 id=上限 的查询，新用户也就别想注册了（把id放在查询的最后一项, 不然前面的查询也出错了）。 　　　我这凌晨2:43 从巴黎折腾回来没多久, 要是写的有什么纰漏 请大家指正