php5 安全 - 获取/发布参数 [英] php5 security - get/post parameters

查看:62
本文介绍了php5 安全 - 获取/发布参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

确保获取/发布参数不会提供任何安全漏洞的最有效方法是什么.

What is most efficient method to making sure that get/post parameters won't provide any security vulnerability.

我很熟悉防止javascript代码注入的htmlentities并添加斜杠以防止 sql 注入.

I am familior of htmlentities for javascript code injection prevention and addslashes to prevent sql injection.

所以……现在我在每个 get/post 参数上都使用它们.

so.. for now i'm using them both on each get/post parameter.

我可以使用其他任何功能来更好地防止这些漏洞,或者还有其他与我的 php 代码相关的安全问题吗?

are there any other functions i can use to prevent these vulnerabilities better or are there any other security issues that i should worry about related to my php code ?

推荐答案

htmlentities(或 htmlspecialchars)和 addslashes(或 mysql_real_escape_string 或其他适合数据库的转义函数;addslashes 总是错误的)与 GET/POST 参数无关.它们是传出转义函数,其输入可能来自参数,但同样可能来自其他地方,例如静态字符串或从数据库中获取的字符串.

htmlentities (or htmlspecialchars) and addslashes (or mysql_real_escape_string or other database-appropriate escaping function; addslashes is invariably the wrong thing) are nothing to do with GET/POST parameters. They are outgoing-escaping functions whose input might come from parameters, but might equally come from somewhere else, such as a static string or a string fetched from the database.

现在我在每个 get/post 参数上都使用它们.

for now i'm using them both on each get/post parameter.

不,那行不通.这是一个常见的错误,并且被许多完全可怕的 PHP 教程材料所延续.尝试将字符串转义问题拆分为一个小循环而不是散布在整个代码中听起来不错,但字符串转义在现实中并不像那样工作.每次将字符串放入另一个字符串时,您都需要应用正确的转义形式,并且仅应用正确的转义形式.你不能提前这样做.

No, that doesn't work. It's a common mistake, and one perpetuated by a lot of the totally dreadful PHP tutorial material out there. Trying to split off the problem of string escaping into one little loop instead of being spread all over the code sounds nice, but string escaping doesn't work like that in reality. You need to apply the right form of escaping, and only the right form of escaping, at each time you put a string inside another string. You cannot do that in advance.

不要试图清理"或过滤"所有传入参数以编码或删除诸如 \< 之类的字符.这将导致您的应用程序充满垃圾,如 \\\\\\\\\\\\\\\\\\\\\\\\&amp;amp;amp;amp;amp;amp;amp;.相反,您应该只对它们进行编码 — 与任何其他不是来自 GET/POST 的变量一起编码 — 在将它们吐到不同的文本上下文中时,例如 htmlspecialchars 用于 HTML 或 mysql_real_escape_string 用于 MySQL 字符串文字.不过,您通常最好使用参数化查询,这样可以避免 SQL 转义问题.

Don't try to ‘sanitise’ or ‘filter’ all the incoming parameters to encode or remove characters like \ or <. This will result in your application filling up with rubbish like \\\\\\\\\\\\\\\\\\\\\\\\\\ and &amp;amp;amp;amp;amp;amp;amp;. Instead, you should only encode them — along with any other varaibles that don't come from GET/POST — at the last minute when spitting them into a different context of text, like htmlspecialchars for HTML or mysql_real_escape_string for MySQL string literals. You are usually better off with parameterised queries though, which avoids the SQL escaping issues.

这并不是说您不应该检查传入的数据是否符合应用程序的要求.如果您有一个字段,您希望为其获取整数,请确保在使用它之前 intval 它.如果您有一个不希望包含换行符的纯单行文本字符串,请务必从字符串中过滤 \n 字符以及所有其他控制字符 [\x00-\x1F\x7F].但这些是应用程序要求,并不是您必须在所有输入中都能运行的要求.

That's not to say you shouldn't check your incoming data for conformance to your application's requirements. If you've got a field you expect to get an integer for, be sure to intval it before using it. If you've got a plain single-line text string which you don't expect to contain newlines, be sure to filter the \n character from the string, along with all other control characters [\x00-\x1F\x7F]. But these are application requirements, not something you can necessarily run across all your input.

这篇关于php5 安全 - 获取/发布参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆