严格的数据验证，你的用户不全是“好”人

记得笔者和一个朋友在讨论数据验证的时候，他说了一句话：你不要把你用户个个都想得那么坏！但笔者想说的这个问题不该出现在我们开发情景中，我们要做的是严格验证控制数据流，哪怕10000万用户中有一个是坏用户也足以致命，再说好的用户也有时在数据input框无意输入中文的时，他已经不经意变“坏”了。

   2.1为了确保程序的安全性，健壮性，数据验证应该包括

(1)     关键数据是否存在。如删除数据id是否存在

(2)     数据类型是否正确。如删除数据id是否是整数

(3)     数据长度。如字段是char(10)类型则要strlen判断数据长度

(4)     数据是否有危险字符

数据验证有些人主张是把功能完成后再慢慢去写安全验证，也有些是边开发边写验证。笔者偏向后者，这两种笔者都试过，然后发现后者写的验证相对健壮些，主要原因是刚开发时想到的安全问题比较齐全，等开发完功能再写时有两个问题，一个phper急于完成指标草草完事，二是确实漏掉某些point。

2.2程序员容易漏掉point或者说需要注意的事项：

(1)     进库数据一定要安全验证，笔者在广州某家公司参与一个公司内部系统开发的时候，见过直接把$_POST数据传给类函数classFunctionName($_POST)，理由竟然是公司内部使用的，不用那么严格。暂且不说逻辑操作与数据操控耦合高低问题，连判断都没判断的操作是致命的。安全验证必须，没任何理由推脱。

(2)     数据长度问题，如数据库建表字段char(25)，大多phper考虑到是否为空、数据类型是否正确，却忽略字符长度，忽略还好更多是懒于再去判断长度。（这个更多出现在新手当中，笔者曾经也有这样的思想）

(3)     以为前端用js判断验证过了，后台不需要判断验证。这也是致命，要知道伪造一个表单就几分钟的事，js判断只是为了减少用户提交次数从而提高用户体验、减少http请求减少服务器压力，在安全情况下不能防“小人”，当然如果合法用户在js验证控制下是完美的，但作为phper我们不能只有js验证而抛弃再一次安全验证。

(4)     缺少对表单某些属性比如select、checkbox、radio、button等的验证，这些属性在web页面上开发者已经设置定其值和值域（白名单值），这些属性值在js验证方面一般不会验证，因为合法用户只有选择权没修改权，然后phper就在后端接受数据处理验证数据的时候不会验证这些数据，这是一个惯性思维，安全问题也就有了，小人一个伪表单足矣致命。

(5)     表单相应元素name和数据表的字段名一致，如用户表用户名的字段是user_name，然后表单中的用户名输入框也是user_name，这和暴库没什么区别。

(6)     过滤危险字符方面如防注入下面会独立讲解。