PHP代码安全性的规范.docx

PHP代码安全性的规范1、 SQL注入1.1 概念所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。1.2 危害 查询数据库中敏感信息。 绕过认证。 添加、删除、修改服务器数据。 拒绝服务。?id=(BENCHMARK(100000000, MD5(RAND();1.3 原因 php 配置文件 php.ini 中的 magic_quotes_gpc选项没有打开，被置为 off 开发者没有对数据类型进行检查和转义第二点最为重要？因为如果没有第二点的保证，magic_quotes_gpc 选项，不论为 on，还是为 off，都有可能引发 SQL 注入攻击。1.4 例子 magic_quotes_gpc = Off 时的注入攻击magic_quotes_gpc = Off是 php 中一种非常不安全的选项。新版本的 php 已经将默认的值改为了 On。但仍有相当多的服务器的选项为 off。当magic_quotes_gpc = On时，它会将提交的变量中所有的 (单引号)、(双号号)、(反斜线)、空白字符，都为在前面自动加上 。下面是 php 的官方说明：magic_quotes_gpc booleanSets the magic_quotes state for GPC (Get/Post/Cookie) operations. When magic_quotes are on, all (single-quote), (double quote), (backslash) and NULs are escaped with a backslash automatically如果没有转义，即 off 情况下，就会让攻击者有机可乘。当用户输入正常的用户名和密码，假设值分别为 zhang3、abc123，则提交的 SQL 语句如下：SELECT * FROM tbl_usersWHERE username=zhang3 AND password = abc123 LIMIT 0,1 如果攻击者在 username 字段中输入：zhang3 OR 1=1 #，在 password 输入 abc123，则提交的 SQL 语句变成如下：SELECT * FROM tbl_usersWHERE username=zhang3 OR 1=1 # AND password = abc123 LIMIT 0,1由于 # 是 mysql中的注释符, #之后的语句不被执行，实现上这行语句就成了：SELECT * FROM tbl_usersWHERE username=zhang3 OR 1=1这样攻击者就可以绕过认证了。如果攻击者知道数据库结构，那么它构建一个 UNION SELECT，那就更危险了：假设在 username 中输入：zhang3 OR 1 =1 UNION select cola, colb,cold FROM tbl_b #在password 输入: abc123，则提交的 SQL 语句变成：SELECT * FROM tbl_usersWHERE username=zhang3 OR 1 =1 UNION select cola, colb,cold FROM tbl_b # AND password = abc123 LIMIT 0,1这样就相当危险了。 magic_quotes_gpc = On 时的注入攻击当 magic_quotes_gpc = On 时，攻击者无法对字符型的字段进行 SQL 注入。这并不代表这就安全了。这时，可以通过数值型的字段进行SQL注入。在最新版的 MYSQL 5.x 中，已经严格了数据类型的输入，已默认关闭自动类型转换。数值型的字段，不能是引号标记的字符型。也就是说，假设 uid 是数值型的，在以前的 mysql 版本中，这样的语句是合法的：INSERT INTO tbl_user SET uid=1;SELECT * FROM tbl_user WHERE uid=1;在最新的 MYSQL 5.x 中，上面的语句不是合法的，必须写成这样：INSERT INTO tbl_user SET uid=1;SELECT * FROM tbl_user WHERE uid=1;那么攻击者在 magic_quotes_gpc = On 时，他们怎么攻击呢？很简单，就是对数值型的字段进行 SQL 注入。一个正常的语句，用户输入 1001和abc123，提交的 sql 语句如下：SELECT * FROM tbl_users WHERE userid=1001 AND password = abc123 LIMIT 0,1如果攻击者在 userid 处，输入：1001 OR 1 =1 #，则注入的sql语句如下：SELECT * FROM tbl_users WHERE userid=1001 OR 1 =1 # AND password = abc123 LIMIT 0,1攻击者达到了目的。1.5 解决方法如何防止 php sql 注入攻击？我认为最重要的一点，就是要对数据类型进行检查和转义。总结的几点规则如下：1）、php.ini 中的 display_errors 选项，应该设为display_errors = off。这样 php 脚本出错之后，不会在 web 页面输出错误，以免让攻击者分析出有作的信息。调用 mysql_query 等 mysql 函数时，前面应该加上 ，即 mysql_query(.)，这样 mysql 错误不会被输出。同理以免让攻击者分析出有用的信息。2）、SQL组装的时候，对外部变量以及所有变量都进行过滤：define(XH_PARAM_INT,0);define(XH_PARAM_TXT,1);function PAPI_GetSafeParam($pi_strName, $pi_Def = , $pi_iType = XH_PARAM_TXT)if ( isset($_GET$pi_strName) )$t_Val = trim($_GET$pi_strName);else if ( isset($_POST$pi_strName)$t_Val = trim($_POST$pi_strName);elsereturn $pi_Def;/ INTif ( XH_PARAM_INT = $pi_iType)if (is_numeric($t_Val)return $t_Val;elsereturn $pi_Def;/ String$t_Val = str_replace(&, &,$t_Val);$t_Val = str_replace(, >,$t_Val);if ( get_magic_quotes_gpc() )$t_Val = str_replace(, ",$t_Val);$t_Val = str_replace(, ',$t_Val);else$t_Val = str_replace(, ",$t_Val);$t_Val = str_replace(, ',$t_Val);return $t_Val;3）、php可用于防注入的一些函数 addslashes和stripslashesAddslashes给这些“”、“”、“”,“NULL”添加斜杆“”、“”、“”,“NULL”, stripslashes则相反，这里要注意的是php.ini是否开启了magic_quotes_gpc=ON，开启若使用addslashes会出现重复。所以使用的时候要先get_magic_quotes_gpc()检查一般代码类似：1. if(!get_magic_quotes_gpc()2. 3. $abc=addslashes($abc);4. mysql_escape_string()和mysql_ real _escape_string()mysql_real_escape_string必须在(PHP 4 = 4.3.0, PHP 5)的情况下才能使用。否则只能用mysql_escape_string1. if(PHP_VERSION=4.3)2. 3. $string=mysql_real_escape_string($string);4. else5. 6. $string=mysql_escape_string($string);7. mysql_escape_string()和mysql_ real _escape_string()却别在于后者会判断当前数据库连接字符集，换句话说在没有连接数据库的前提下会出现类似错误：Warning: mysql_real_escape_string() function.mysql-real-escape-string: Access denied for user ODBClocalhost (using password: NO) in E:webphptest.php on line 11 字符代替函数和匹配函数str_replace()、perg_replace()这些函数之所以也在这里提是因为这些函数可以用于过滤或替代一些敏感、致命的字符。 防注入字符优先级防注入则要先知道有哪些注入字符或关键字，常见的mysql注入字符有字符界定符号如“”、“”；逻辑关键字如“and”、“or”；mysql注悉字符如“#”，“-”，“/*/”；mysql通配符“%”，“_”；mysql关键字“select|insert|update|delete|*|union|join|into|load_file|outfile”A、 防注入优先级最高的是空格” ” ，空格字符的变种有：“%20”，“n”，“r”，“rn”，“nr”，“chr(32)”这也是为什么mysql_escape_string()和mysql_real_escape_string()两个函数转义“n”，“r”。B、 “and”，“or”，“”，“#”，“-”。 逻辑关键可以组合很多注入代码；mysql注悉则把固有sql代码后面的字符全部给注悉掉从而让注入后的sql语句能正常运行；“”也是能组合很多注入字符x00,x1a。sql解析“#”，“-”是大多数mysql防注入代码没有考虑到的，也是很多phper忽略。还有因为一些phper给参数赋值的时候会有用“-”来隔开，所以笔者建议不要这样写参数，当然也可以再过滤参数的时候“-”（注意有空格的，没空格不解析为注悉）当一个整体过滤而不是过滤“-”，这样就避免过多过滤参数。C、 “null”，“%”，“_”。 这几个不能独立，都不要在特定情况下，比如通配字符“%，_”都要在mysql like子句的前提下。所以“%”，“_”的过滤一般在搜索相关才过滤，不能把它们纳入通常过滤队列，因为有些如邮箱就可以有”_”字符D、 关键字“select|insert|update|delete|*|union|join|into|load_file|outfile”。 也许你会问怎么这些重要关键字却优先级这么低。笔者想说的是因为这些关键字在没有“”,“”，“”，“and”，“or”等情况下购不成伤害。换句话说这些关键字不够“独立”，“依赖性”特别大。当然优先级低，不代表不要过滤。2、XML注入2.1 概念XML是存储数据的地方，如果在查询或修改时，如果没有做转义，直接输入或输出数据，都将导致XML注入漏洞。攻击者可以修改XML数据格式，增加新的XML节点，对数据处理流程产生影响。2.2 危害 攻击者可以新增XML节点 破坏原来的XML结构，影响业务流程，甚至产生严重的错误。2.3 例子$xml = “ . $_GETname . “ . $_GETemail . ;需要得到的XML结构：恶意代码：意外的XML文档：2.4 解决方法 对php处理XML文档的时候，进行标签过滤 尽量减少直接被外部访问到xml文档，可以采用文件名用散列方法等。3、XSS跨站脚本3.1 概念跨站脚本攻击（Cross Site Scripting）是指攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。为了与层叠样式表（Cascading Style Sheets）的缩写CSS区分开，跨站脚本攻击通常简写为XSS。3.2 危害 盗取用户COOKIE信息。 跳转到钓鱼网站。 操作受害者的浏览器，查看受害者网页浏览信息等。 蠕虫攻击。3.3 例子 反射型XSS跨站脚本攻击该类型只是简单地将用户输入的数据直接或未经过完善的安全过滤就在浏览器中进行输出，导致输出的数据中存在可被浏览器执行的代码数据。由于此种类型的跨站代码存在于URL中，所以黑客通常需要通过诱骗或加密变形等方式，将存在恶意代码的链接发给用户，只有用户点击以后才能使得攻击成功实施。下面这个页面的主要作用是获取用户输入的参数作为用户名，并在页面中显示“欢迎您，XXX”的形式，具体代码如下：?php$username = $_GETname;echo 欢迎您, .$username.!;?正常情况下，用户会在URL中提交参数name的值为自己的姓名，然后该数据内容会通过以上代码在页面中展示，如用户提交姓名为“张三”，完整的URL地址如下：http:/localhost/test.php?name=张三在浏览器中访问时，会显示如下图1所示内容：此时，因为用户输入的数据信息为正常数据信息，经过脚本处理以后页面反馈的源码内容为欢迎您, 张三!。但是如果用户提交的数据中包含有可能被浏览器执行的代码的话，会是一种什么情况呢？我们继续提交name的值为alert(/我的名字是张三/),即完整的URL地址为http:/localhost/test.php?name=alert(/我的名字是张三/)在浏览器中访问时，我们发现会有弹窗提示，如下图2所示：图2那么此时页面的源码又是什么情况呢？源码变成了“欢迎您, alert(/我的名字是张三/)!”，从源代码中我们发现，用户输入的数据中，与标签中的代码被浏览器执行了，而这并不是网页脚本程序想要的结果。 存储型XSS跨站脚本攻击存储型XSS脚本攻击是指Web应用程序会将用户输入的数据信息保存在服务端的数据库或其他文件形式中，网页进行数据查询展示时，会从数据库中获取数据内容，并将数据内容在网页中进行输出展示，因此存储型XSS具有较强的稳定性。存储型XSS脚本攻击最为常见的场景就是在博客或新闻发布系统中，黑客将包含有恶意代码的数据信息直接写入文章或文章评论中，所有浏览文章或评论的用户，都会在他们客户端浏览器环境中执行插入的恶意代码。如流行的Bo-Blog程序的早期版本中存在对用户提交评论数据过滤不严导致的XSS跨站脚本攻击漏洞，黑客可以在文章评论中提交插入恶意数据的UBB代码，提交后，Bo-Blog程序会将数据保存至数据库中，当用户浏览该日志时，就会执行插入的恶意代码，如图所示。基于DOM的XSS跨站脚本攻击基于DOM的XSS跨站脚本攻击是通过修改页面DOM节点数据信息而形成的XSS跨站脚本攻击。不同于反射型XSS和存储型XSS，基于DOM的XSS跨站脚本攻击往往需要针对具体的javascript DOM代码进行分析，并根据实际情况进行XSS跨站脚本攻击的利用。让我们来针对如下代码进行详细分析：DOM Based XSS Demofunction xsstest()var str = document.getElementById(input).value;document.getElementById(output).innerHTML = ;以上代码的作用是提交一个图片的URL地址以后，程序会将图片在页面中进行展示，如我们提交百度LOGO图片的地址/img/baidu_sylogo1.gif，那么在页面中展示结果如下图4所示。图4当用户输入完百度LOGO的地址，点击“提交”按钮后，“提交”按钮的onclick事件会调用xsstest()函数。而xsstest()函数会获取用户提交的地址，通过innerHTML将页面的DOM节点进行修改，把用户提交的数据以HTML代码的形式写入页面中并进行展示。以上例子中输出的HTML代码为“”。以上情况为正常的用户输入情况，那黑客又是怎么利用该种类型代码实现XSS跨站脚本攻击的呢？黑客可以通过构造如下数据，输入“# onerror=javascript:alert(/DOM Based XSS Test/)”，在浏览器中提交后，发现代码果然被执行，出现了弹窗提示，如下图5所示。3.4 解决方法1）、完善输入输出检查A.防范反射型XSS和存储型XSS输入检查在大多数的时候都是对可信字符的检查或输入数据格式的检查，如用户输入的注册账号信息中只允许包括字母、数字、下划线和汉字等，对于输入的一切非白名单内的字符均认为是非法输入。数据格式如输入的IP地址、电话号码、邮件地址、日期等数据都具有一定的格式规范，只有符合数据规范的输入信息才允许通过检查。输出检查主要是针对数据展示过程中，应该对数据信息进行HTML编码处理，将可能存在导致XSS跨站脚本攻击的恶意字符进行编码，在不影响正常数据显示的前提条件下，过滤恶意字符。常见的可能造成XSS跨站脚本攻击的字符及其HTML编码如下：“"'& >除了常用的编码外，任何字符都可以使用其ASCII码进行HTML编码，如%%**B.防范基于DOM的XSS从基于DOM的XSS的定义及其触发方式我们发现，当基于DOM的XSS跨站脚本攻击发生时，恶意数据的格式与传统的XSS跨站脚本攻击数据格式有一定的差异，甚至可以在不经过服务器端的处理和相应的情况下，直接对客户端实施攻击行为，因此上述我们应用于防范反射型XSS和存储型XSS的方法并不适用于防范基于DOM的XSS跨站脚本攻击。针对基于DOM的XSS防范的输入检查方法，我们发现在客户端部署相应的安全检测代码的过滤效果要比在服务器端检测的效果更加明显。例如，我们可以通过如下客户端检测代码来保证用户输入的数据只包含字母、数字和空格，代码如下：var str = document.URL;str = str.substring(str.indexOf(username=)+9, str.length);str = unescape(str);var regex=/(A-Za-z0-9+s)*$/;if (regex.test(str)document.write(str);同样，我们也可以通过在服务端实现类似上述数据检查的功能，如在服务器端检测URL参数是否为预定的参数username,并对username参数的内容进行检测，确认数据内容是否为只包含数字、字母和空格符，实现服务端的数据过滤。但是，由于客户端数据的可控性，这种服务端检测的效果要明显弱于客户端检测。基于DOM的XSS输出检查与反射型XSS漏洞输出检查的方法相似，在将用户可控的DOM数据内容插入到文档之前，Web应用程序应对提交的数据进行HTML编码处理，将用户提交的数据中可能存在的各种危险字符和表达式进行过滤以安全的方式插入到文档中进行展现，如可以通过如下函数实现在客户端javascript中执行HTML编码处理。function jsEncode(str)var d = document.createElement(div);d.appendChild(document.createTextNode(str);return d.innerHTML;4、CSRF跨站攻击4.1 概念CSRF跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。4.2 原理(1)A登录Site1（如现在网民常上的淘宝、微博、QQ等），产生一些信息，session、cookies等等，且一直保持没退出。(2)A再登录Site2（如一些成人网等，至于怎么跑到Site2，多数是Site通过些手段，邮件欺骗等），打开site2的浏览器和打开site1的一样，否则无效(3)Site2站中伪造了Site1的http请求（如修改密码，买东西，转账等），Site1的服务器误以为A在site1的正常操作（因为同浏览器且A还没登出），然后就运行了请求，那么csrf已成功操作。4.3 危害强迫受害者的浏览器向一个易受攻击的Web应用程序发送请求,最后达到攻击者所需要的操作行为。4.4 例子1）. 上面是一个图片的html标签，但是src中是一个添加id为123好友的新增好友链接。2）. 恶意用户可以将这段代码植入其它网站网页上面，甚至可以img设置为0,0，让用户不知不觉中点击这个链接，达到用户并不像加这个人好友，但是添加的目的。3）. 当很多人都无意加了id为123这个人为好友的时候，id为123的恶意用户就有权限来查看这些人的信息，甚至可以发送很多恶意的信息，达到恶意用户的目的。解决方法：1）. /addfriend.php?id=123 使用POST方法会相对安全一点。2）. 采用类似随即码或者令牌的形式，让用户操作唯一性。 （每次用户登录网站随机生成一个token，存放在cookie中，用户的所有操作中都需要经过token验证）4.5 解决方法(1)严密操控执行入口执行一些敏感操作比如改密码这些操作前判断请求来源，只有本站服务器发的请求才可以执行。判断方法可以判断ip来源。非本站服务器ip不会执行。(2)本站有外链的话做些必要操作一般site2的hacker会在site1（比如论坛里）里发欺骗链接，因为在site1诱骗的相关人员一般都登录site1了，满足csrf气体条件之一。如当你点击QQ邮件里面的长外链时候，回跳转到一个页面提示“有风险”之类，这样不仅可以减低跳出率，一些不懂的人看到这样的提示，若不是非必要而是处于好奇点击的连接一般不会继续点击访问；还有是QQ邮件正文里的图片在加载内容时是不加载图片的，要点击“显示图片”按钮才显示图片，这里一个原因之一就是避免攻击。当然对于用户体验来说这是不可取的，可以优化的是判断到一些网址（如QQ本身网址）是安全直接可以显示（不用提示），而可疑的才提示或禁止。5、URL跳转漏洞5.1 概念Web应用程序接收到用户提交的URL参数后，没有对参数做”可信任URL”的验证，就向用户浏览器返回跳转到该URL的指令。5.2 危害钓鱼网站5.3 例子/log.php?c=web&u=5.4 解决方法对跳转的php函数进行进一步优化，使页面跳转可以在可信任的范围内。 例如可以有跳转域名白名单方法，这个访问各大公司使用比较多6、文件系统跨越漏洞6.1 概念对文件目录参数没有进行过滤，导致恶意用户可以通过在参数中输入一些执行命令，或者跨越访问的行为，来超出用户的访问权限。6.2 危害非法获取服务器权限6.3 例子通过一个或多个./跨越目录限制$fp = fopen(image/$_GETfilename, r);Getfile?filename=././././etc/passwd6.4 解决方法1). 对文本操作的时候一定要谨慎，不可信任2). 严格使用安全类库函数，控制路径的访问权限3). 不要开启服务器的目录浏览权限7、文件上传下载漏洞7.1 概念Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，或者没检测文件内容的合法性，就把文件保存在服务器上，甚至上传脚本木马到web服务器上，直接控制web服务器。7.2 例子1. 未限制扩展名2. 未检查文件内容3. 病毒文件7.3 解决方法1、文件上传的解决方法 使用安全的，可信任的上传组件。 检查文件扩展名，保证文件的类型正确。 检查文件内容，保证用户不伪造文件类型。2、文件下载的解决方法 Apache虚拟目录指向 Java/PHP读取文件8、权限控制漏洞8.1 概念属于业务逻辑上的安全管理。访问控制：1. 水平访问：Web应用程序接收到用户请求，修改某条数据时，没有判断数据的所属人，或判断数据所属人时，从用户提交的request参数（用户可控数据）中，获取了数据所属人id，导致恶意攻击者可以通过变换数据ID，或变换所属人id，修改不属于自己的数据。2. 垂直访问：由于web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升目的。存在情况：1URL级别的。（例如论坛需要操作评分的时候，有一个提交的URL地址，该地址提交过去，如果不做权限判断，那么恶意用户就可以随意的拿这个URL地址来进行恶意行为）2 菜单级别。（会员中心或者后台管理中心，会有菜单，管理员可以看到多个功能，普通管理员只能看到一部分功能。但是如果你对管理员操作的功能区不做权限判断，那么普通管理员只要猜测或者获取管理区的URL，就可以进行管理员操作了）8.2 危害属于业务逻辑的漏洞，这些危害性是巨大的，可以让普通用户就可能获取管理员的权限，对网站进行恶意破坏或者做非法行为。8.3 解决方法1). 项目先期，做一份详细的权限规划文档。2). 在开发中严格按照权限文档的要求去做权限。3). 后期测试需要覆盖权限这一块功能区。4). 程序员需要经常注意这些方面的要求。9、其他方面漏洞9.1 cookie安全设置cookie httponly flag ：在用到用户名登陆密码之类的安全性比较高的cookie的时候，可以在cookie中设置httponly属性，该属性只允许php等访问cookie，而不允许js访问。cookie secure flag ： 在涉及到https这样的情况，需要对cookie加密传输，那么可以设置这个属性9.2 session安全 SESSION是保存在服务器端的，具有比COOKIE一定的安全性。 使用COOKIE的时候，如果长时间没有动作，可以设置一个时间值，来对COOKIE进行过期。 尽量让用户每次的cookie值都是不同的，这样可以保证cookie被盗取也不能长期使用的问题9.3 flash安全问题9.4 php的一些安全配置 关闭php提示错误功能在php.ini中把display_errors改成1. display_errors=OFF或在php文件前加入1. error_reporting(0)1)使用error_reporting(0);失败的例子：A文件代码：1. 错误：Parse error: parse error, expecting , or ; in E:webphp2.php on line 42)使用error_reporting(0);成功的例子：a文件代码：1. b文件代码：1. 这是很多phper说用error_reporting(0)不起作用。第一个例子A.php里面有致命错误，导致不能执行，不能执行服务器则不知有这个功能，所以一样报错。第二个例子中a.php成功执行，那么服务器知道有抑制错误功能，所以就算b.php有错误也抑制了。 关闭magic quotes功能在php.ini把magic_quotes_gpc = OFF 避免和addslashes等重复转义 关闭register_globals = Off在php.ini把register_globals = OFF在register_globals = ON的情况下地址栏目：http:?bloger=benwin1. 这种情况下会导致一些未初始化的变量很容易被修改，这也许是致命的。所以把register_globals = OFF关掉10、ThinkPHP框架安全10.1 表单令牌ThinkPHP内置了表单令牌验证功能，可以有效防止表单的重复提交等安全防护。表单令牌验证相关的配置参数有：1. TOKEN_ON=true,/是否开启令牌验证2. TOKEN_NAME=_hash_,/令牌验证的表单隐藏字段名称3. TOKEN_TYPE=md5,/令牌哈希验证规则默认为MD54. TOKEN_RESET=true,/令牌验证出错后是否重置令牌默认为true如果开启表单令牌验证功能，系统会自动在带有表单的模板文件里面自动生成以TOKEN_NAME为名称的隐藏域，其值则是TOKEN_TYPE方式生成的哈希字符串，用于实现表单的自动令牌验证。自动生成的隐藏域位于表单Form结束标志之前，如果希望自己控制隐藏域的位置，可以手动在表单页面添加 标识，系统会在输出模板的时候自动替换。如果页面中存在多个表单，建议添加标识，并确保只有一个表单需要令牌验证。如果个别页面输出不希望进行表单令牌验证，可以在控制器中的输出方法之前动态关闭表单令牌验证，例如：1. C(TOKEN_ON,false);2. $this-display();模型类在创建数据对象的同时会自动进行表单令牌验证操作，如果你没有使用create方法创建数据对象的话，则需要手动调用模型的autoCheckToken方法进行表单令牌验证。如果返回false，则表示表单令牌验证错误。例如：1. $User=M(User);/实例化User对象2. /手动进行令牌验证3. if(!$User-autoCheckToken($_POST)4. /令牌验证错误5. 10.2 字段类型验证新版的ThinkPHP具有字段类型检测，对于不合法的字段数据会进行强制转换。字段类型检测可以用于数据写入和数据查询操作。需要启用字段类型检测的话，需要在配置文件中开启DB_FIELDTYPE_CHECK参数：1. DB_FIELDTYPE_CHECK=true,/开启字段类型验证如果在非调试模式下面开启字段类型检测后，请清空字段缓存目录（位于Runtime/Data/_fields/），重新生成字段缓存的时候，会在缓存文件中记录字段的类型信息。这是后面进行字段类型检测的前提。字段类型检测主要在两个阶段会自动处理：一、在数据写入到数据库之前例如：1. $User=M(User);/实例化User对象2. /然后直接给数据对象赋值3. $User-name=ThinkPHP;4. $User-score=2ThinkPHP;5. /把数据对象添加到数据库6. $User-add();由于用户表的score设计的是数字类型，所以实际写入数据库之前，score属性的值已经被强制进行intval转换了，模型的save方法也会同样进行字段类型检查。虽然在很多情况下，数据库本身也会进行数据转换，但是对于某些数据库要求严格检查数据类型的情况会有帮助。10.3 防止SQL注入对于WEB应用来说，SQL注入攻击无疑是首要防范的安全问题，系统底层对于数据安全方面本身进行了很多的处理和相应的防范机制，例如：1. $User=M(User);/实例化User对象2. $User-find($_GETid);即便用户输入了一些恶意的id参数，系统也会强制转换成整型，避免恶意注入。这是因为，系统会对数据进行强制的数据类型检测，并且对数据来源进行数据格式转换。而且，对于字符串类型的数据，ThinkPHP都会进行escape_string处理(real_escape_string,mysql_escape_string)。通常的安全隐患在于你的查询条件使用了字符串参数，然后其中一些变量又依赖由客户端的用户输入，要有效的防止SQL注入问题，我们建议： 查询条件尽量使用数组方式，这是更为安全的方式； 如果不得已必须使用字符串查询条件，使用预处理机制（3.1版本新增特性）； 开启数据字段类型验证，可以对数值数据类型做强制转换；（3.1版本开始已经强制进行字段类型验证了） 使用自动验证和自动完成机制进行针对应用的自定义过滤； 字段类型检查、自动验证和自动完成机制我们在相关部分已经有详细的描述。查询条件预处理where方法使用字符串条件的时候，支持预处理（安全过滤），并支持两种方式传入预处理参数，例如：1. $Model-where(id=%dandusername=%sandxx=%f,array($id,$username,$xx)-select();或者1. $Model-where(id=%dandusername=%sandxx=%f,$id,$username,$xx)-select();模型的query和execute方法 同样支持预处理机制，例如：1. $model-query(select*fromuserwhereid=%dandstatus=%d,$id,$status);或者1. $model-query(select*fromuserwhereid=%dandstatus=%d,array($id,$status);execute方法用法同query方法。10.4 输入过滤永远不要相信客户端提交的数据，所以对于输入数据的过滤势在必行，我们建议： 开启令牌验证避免数据的重复提交； 使用自动验证和自动完成机制进行初步过滤； 使用系统Action类提供的_get _post _cookie等方法获取数据； 对用户输入的数据进行有效（根据你的应用）的过滤，常见的安全过滤函数包括stripslashes、htmlentities、htmlspecialchars等，官方的扩展类库中的ORG.Util.Input类则提供了更好的解决方法；1系统变量的全局过滤系统变量的全局过滤功能，采用VAR_FILTERS 定义，默认为空，表示不进行任何过滤。如果设置了VAR_FILTERS参数，对GET POST系统变量会进行过滤，例如：1. VAR_FILTERS=htmlspecialchars也可以支持多个方法过滤，例如：1. VAR_FILTERS=stripslashes,strip_tags注意如果系统变量存在多维数组的情况，设置的过滤方法要能够很好的支持多维数组过滤。3表单数据合法性检测使用create方法创建数据对象的时候，可以使用数据的合法性检测，有两种方式：一、可以配置insertFields 和 updateFields属性可以分别为新增和编辑表单设置insertFields 和 updateFields属性使用create方法创建数据对象的时候，不在定义范围内的属性将直接丢弃，避免表单提交非法数据。insertFields 和 updateFields属性的设置采用字符串（逗号分割多个字段）或者数组的方式。设置的字段应该是实际的数据表字段，而不受字段映射的影响。例如：1. classUserModelextendsModel2. protected$insertFields=array(account,password,nickname,email);3. protected$updateFields=array(nickname,email);4. 定义后，调用add方法写入用户数据的时候，只能写入account,password,nickname,email 这几个字段，编辑的时候只能更新nickname,email两个字段。在使用的时候，我们调用create方法的时候，会根据提交类型自动识别insertFields和updateFields属性：1. D(User)-create();二、直接调用field方法如果不想定义insertFields和updateFields属性，可以在调用create方法之前直接调用field方法，例如，实现和上面的例子同样的作用：在新增用户数据的时候，使用：1. M(User)-field(account,password,nickname,em