安全？安全！安全！！
在某日下班后，回家的路上，一个人走，走着走着，忽然我的手碰到了另一支手，艳遇？扭头！发现一新疆美男在左顾右盼。然而我背的包已经被拉开了一半。好险，我的kindle，钱包都在包里。
年关将近，是该注意安全了。特别是回家的路上，请各位兄弟照顾好贵重物品和老婆，防火防盗啊！
好吧，言归正转。我们还是说说我们在开发中的安全问题吧。
这里我们从一次PHP请求过程来说明一些常见的安全问题。
【从客户端到服务器应用层】
每次用户的请求都会先通过客户端发起请求，然后服务器接收请求并处理这个请求。
如果我们在客户端有验证（如必须输入用户名之类的），此时我们除了在客户端验证外，更重要的是在服务器的应用层进行验证（所有的验证必须在服务器有一份）。这些验证包括不能为空，输入内容的长度，输入内容的类型等。如果确定为数字型，可以考虑将其转化为数字类型后使用。
为什么要这样做呢？因为我们不相信客户端，也不相信客户端的验证。在某些情况下，对于用户输入的数据，我们不仅仅是过滤，在必要的时候可能需要直接提示用户输入错误。
如果我们在实际项目中要做类似于投票的功能，需要对用户进行限制，常规的，ip,验证码等。除此之外，如果是基于某个已有应用，并且这个应用是有账号这个概念的，那么我们可以加入基于账号的验证；如果整个投票活动是基于某个活动流程，那么我们也可以加入流程验证。
【从应用层到数据层】
在应用层接收到客户端的数据后，如果此时我们需要查询后台的数据进行相关计算，那么我们需要调用数据层获取数据，当把参数传给数据层后，数据层应该不相信应用层的数据，它需要按照自己的逻辑进行类型等的验证，然后再将查询的条件传给数据库。
这样也许可以减少一些SQL注入漏洞。
【从服务器应用层到客户端展示】
当应用层从数据层获取数据处理完后，需要在前台展示，此时会将计算结果返回给客户端。
在显示计算结果之前我们需要将计算结果进行过滤。因为我们不相信服务器（或者说数据层）返回给我们的信息。对，不相信他们。
这样也许可以减少一些存储式跨站脚本漏洞。
【服务器本身的问题】
就PHP本身而言，一些必要的参数，安全模式的开启。比如php.ini中的open_basedir参数。
或者在开发机器经常看到可以浏览整个目录的情况。
或者PHP中的打开register_globals（新的版本默认为关闭）
所有的说到底就一个原则：不要相信任何人!
此时想起了面向对象中的迪米特法则：不要和陌生人说话。
也许没有什么关联，只是在某些点上，大道相通。