一个简单的例子：计算借书的天数,根据每天的日期进行计算。
(1) 有数据库的情况
MSSQL可以使用触发器!用专门计算日期差的函数datediff()便可。
MYSQL那就用两个日期字段的差值计算的计算结果保存在另一个数值型字段中!用时调用便可。
(2)没有数据库的情况
使用php的时间日期函数。
例:计算1998年5月3日到1999-6-5的天数:
<? $startdate=mktime("0","0","0","5","3","1998");
$enddate=mktime("0","0","0","6","5","1999");
//所得到的值为从1970-1-1到参数时间的总秒数:是整数.
$days=round(($enddate-$startdate)/3600/24) ;
echo $days;
//days为得到的天数;
若mktime()中的参数缺省,则使用当前日期。
一、 注入式攻击
当脚本正在执行一个SELECT指令，攻击者便可以强迫显示一个表格中的每一行记录-通过把一个例如"1=1"这样的条件注入到WHERE子句中，如下所示：
这本身可能是很有用的信息，因为它揭示了该表格的一般结构(这是一条普通的记录所不能实现的)，以及潜在地显示包含机密信息的记录。
一条更新指令潜在地具有更直接的威胁。通过把其它属性放到SET子句中，一名攻击者可以修改当前被更新的记录中的任何字段，例如下面的例子：
通过把一个例如1=1这样的恒真条件添加到一条更新指令的WHERE子句中，这种修改范围可以扩展到每一条记录，例如下面的例子：
最危险的指令可能是DELETE-这是不难想像的。其注入技术与我们已经看到的相同-通过修改WHERE子句来扩展受影响的记录的范围，例如下面的例子：
二、 多个查询注入
多个查询注入将会加剧一个攻击者可能引起的潜在的损坏-通过允许多条破坏性指令包括在一个查询中。在使用MySQL数据库时，攻击者通过把一个出乎意料之外的终止符插入到查询中即可很容易实现这一点-此时一个注入的引号(单引号或双引号)标记期望变量的结尾；然后使用一个分号终止该指令。现在，一个另外的攻击指令可能被添加到现在终止的原始指令的结尾。最终的破坏性查询可能看起来如下所示：
这个注入将创建一个新的用户BadGuy并赋予其网络特权（在所有的表格上具有所有的特权）；其中，还有一个"不祥"的口令被加入到这个简单的 SELECT语句中。如果你遵循我们在以前文章中的建议－严格限制该过程用户的特权，那么，这应该无法工作，因为Web服务器守护程序不再拥有你撤回的 GRANT特权。但是从理论上讲，这样的一个攻击可能给予BadGuy自由权力来实现他对你的数据库的任何操作。
至于这样的一个多查询是否会被MySQL服务器处理，结论并不唯一。这其中的一些原因可能是由于不同版本的MySQL所致，但是大多数情况却是由于多查询存在的方式所致。 MySQL的监视程序完全允许这样的一个查询。常用的MySQL GUI-phpMyAdmin，在最终查询之前会复制出以前所有的内容，并且仅仅这样做。
但是，大多数的在一个注入上下文中的多查询都是由PHP的mysql扩展负责管理的。幸好，默认情况下，它是不允许在一个查询中执行多个指令的；试图执行两个指令(例如上面所示的注入)将会简单地导致失败-不设置任何错误，并且没有生成任何输出信息。在这种情况下，尽管PHP也只是"规规矩矩"地实现其缺省行为，但是确实能够保护你免于大多数简单的注入式攻击。
PHP5中的新的mysqli扩展(参考http://php.net/mysqli)，就象mysql一样，内在地也不支持多个查询，不过却提供了一个mysqli_multi_query()函数以支持你实现多查询-如果你确实想这样做的话。
然而，对于SQLite-与PHP5绑定到一起的可嵌入的SQL数据库引擎(参考http://sqlite.org/和http: //php.net/sqlite)情况更为可怕，由于其易于使用而吸引了大量用户的关注。在有些情况下，SQLite缺省地允许这样的多指令查询，因为该数据库可以优化批查询，特别是非常有效的批INSERT语句处理。然而，如果查询的结果为你的脚本所使用的话（例如在使用一个SELECT语句检索记录的情况下），sqlite_query()函数却不会允许执行多个查询。
三、 INVISION Power BOARD SQL注入脆弱性
下面是一个著名的论坛系统在登录代码中发现的一处SQL注入脆弱性。
这个登录查询如下所示：
其中，成员ID变量$mid和口令ID变量$pid被使用下面两行代码从my_cookie()函数中检索出：
在此，my_cookie()函数使用下列语句从cookie中检索要求的变量：
注意：从该cookie返回的值根本没有被处理。尽管$mid在使用于查询之前被强制转换成一个整数，但是$pid却保持不变。因此，它很容易遭受我们前面所讨论的注入类型的攻击。
因此，通过以如下方式修改my_cookie()函数，这种脆弱性就会暴露出来：
{
return $this->clean_value(urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]));
}
else
{
return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
}
经过以上修改后，其中的关键变量在"通过"全局clean_value()函数后被返回，而其它变量却未进行检查。
function uh($str)
{
$farr = array(
"/s+/", //过滤多余的空白
"/<(/?)(script|i?frame|style|html|body|title|link|meta|?|%)([^>]*?)>/isU", //过滤 <script 等可能引入恶意内容或恶意改变显示布局的代码,如果不需要插入flash等,还可以加入<object的过滤
"/(<[^>]*)on[a-zA-Z]+s*=([^>]*>)/isU", //过滤javascript的on事件
);
$tarr = array(
" ",
"<\1\2\3>", //如果要直接清除不安全的标签，这里可以留空
"\1\2",
);
$str = preg_replace( $farr,$tarr,$str);
return $str;
}
您可能感兴趣的文章：
PHP安全过滤代码(360提供 安全系数高)
PHP过滤post,get敏感数据的实例代码
php 过滤非法与特殊字符串的方法
php 防注入的一段代码(过滤参数)
php实现过滤IP黑白名单的方法
很好用的php防止sql注入漏洞过滤函数的代码
php防止sql注入正则过滤一例