我最近对我工作的其中一个站点进行了安全审计.这是通过Acunetix Web漏洞扫描程序完成的.这回来了一堆我正在整理的结果.
很多关于XSS的点击率都出现了,但我不确定它们是否是误报.
代码如:
if(isset($_GET['variableNameX'])) $var_to_use_in_app = mysql_escape_string(trim($_GET['variableNameX']));
回来对XSS开放.任何带有查询字符串的页面都会回来,因为它可能对XSS开放,或者它是否足够聪明,知道我正在处理这个服务器端?
谢谢您的帮助.
如果有传入querystring参数的HTML,你会在页面上显示它吗?如果是这样,那不是误报.
换句话说,如果你通过了类似的东西:http: //www.example.com/?myVar = Test
并且您在页面上显示myVar的结果而不测试HTML/Script,然后有人可能会将其更改为:http://www.example.com/?myVar = Test b> ;
或者类似的东西:http://www.example.com/?myVar =
$ var_to_use_in_app = mysql_escape_string(trim($ _ GET ['variableNameX']));
这通常是错误的做法.应用程序内部使用的字符串应始终为纯文本版本.那么你可以肯定的是,你的字符串操作都不会破坏它,并且你不会输出错误的东西到页面.
例如,如果您有提交的字符串:
O'Reilly
mysql_escape_string会将其转义为:
O\'Reilly
当你将该字符串输出到HTML页面时,它看起来很傻.如果你把它输出到一个然后再提交的表格字段,你会得到另一个反斜杠,它会变成两个黑色斜线,如果再次编辑就会变成四个,八个......而且不久你就会得到由数百个反斜杠组成的字符串.这是一个常见的问题,在写得不好的CMS和服务器上启用了恶魔magic_quotes功能.
如果您想要将名称的前两个字母放入数据库查询中,则需要剪切子字符串:
O\
然后将其连接到查询中:
SELECT * FROM users WHERE namefirst2='O\';
哎呀,语法错误,该字符串现在未终止.预转义字符串上的字符串处理变体可以很容易地让您陷入安全问题.
除了最终输出阶段,您将字符串作为SQL或HTML中的分隔文字连接在一起,而不是这种方法,将您的字符串保持为应用程序中的简单非转义文本字符串.对于SQL:
"SELECT * FROM users WHERE name='".mysql_real_escape_string($name)."';"
注意'真实'函数名称 - 普通的mysql_escape_string对于某些极端情况(例如东亚字符集和具有ANSI SQL_MODE集的连接/数据库)失败,因此通常应始终使用"真实"版本.
您可以定义一个与mysql_real_escape_string相同但具有较短名称(例如m())的函数,以使其稍微不那么难看.或者,更好的是,查看mysqli的参数化查询.
对于HTML,应使用htmlspecialchars()函数完成转义:
Hello, Mr. !
您可以定义一个执行echo(htmlspecialchars())但具有较短名称(例如h())的函数,以使其稍微不那么难看.
如果你错过了对htmlspecialchars的调用,那么你的扫描仪绝对正确地告诉你你的站点容易受到XSS攻击.但是不要觉得太糟糕,几乎所有其他PHP程序员都会犯同样的错误.
mysql_ [real_] escape_string在这里根本没有帮助,因为在HTML中突破文本的字符是'&','<',在属性中,'''.这些在SQL字符串中都不是特殊的文字,所以mysql_escape_string根本不接触它们.恶意:
只有逃到:
就安全而言,这对任何事都没有帮助.