mysql_real_rescape_string()是否足以保护我免受黑客和SQL攻击?问问是因为我听说这些方法不能帮助您抵御所有攻击媒介?寻求专家的建议。
编辑:此外,怎么样的SQL攻击?
@查尔斯是非常正确的!
您面临多种 已知 SQL攻击的风险,包括您提到的
考虑一下:
$sql = "SELECT number FROM PhoneNumbers " .
"WHERE " . mysql_real_escape_string($field) . " = " . mysql_real_escape_string($value);
这样可以安全可靠地逃脱吗?没有!为什么?因为黑客很可能仍然可以这样做:
在我之后重复:
mysql_real_escape_string()
仅用于转义变量数据,而 不是 表名,列名,尤其是LIMIT字段。
LIKE漏洞:LIKE“ $ data%”,其中$ data可能是“%”,它将返回所有记录…这 很可能 是安全漏洞…只是想像一下信用卡最后四位数字的查找。糟糕!现在,黑客可能会收到您系统中的每个信用卡号!(顺便说一句:几乎不建议存储完整的信用卡!)
Charset Exploits:无论仇恨者怎么说,Internet Explorer 在2011年 仍然 容易受到Character Set Exploits的攻击,也就是说, 如果 您正确设计了HTML页面,等效于<meta name="charset" value="UTF-8"/>
!这些攻击非常讨厌,因为它们给黑客提供了与直接SQL注入一样多的控制权:例如完全攻击。
这是一些示例代码来演示所有这些:
// Contains class DBConfig; database information.
require_once('../.dbcreds');
$dblink = mysql_connect(DBConfig::$host, DBConfig::$user, DBConfig::$pass);
mysql_select_db(DBConfig::$db);
//print_r($argv);
$sql = sprintf("SELECT url FROM GrabbedURLs WHERE %s LIKE '%s%%' LIMIT %s",
mysql_real_escape_string($argv[1]),
mysql_real_escape_string($argv[2]),
mysql_real_escape_string($argv[3]));
echo "SQL: $sql\n";
$qq = mysql_query($sql);
while (($data = mysql_fetch_array($qq)))
{
print_r($data);
}
这是传递各种输入时此代码的结果:
$ php sql_exploits.php url http://www.reddit.com id
SQL generated: SELECT url FROM GrabbedURLs
WHERE url LIKE 'http://www.reddit.com%'
ORDER BY id;
Returns: Just URLs beginning w/ "http://www.reddit.com"
$ php sql_exploits.php url % id
SQL generated: SELECT url FROM GrabbedURLs
WHERE url LIKE '%%'
ORDER BY id;
Results: Returns every result Not what you programmed, ergo an exploit --
$ PHP sql_exploits.php 1 = 1 ‘
http://www.reddit.com ‘身份证结果:返回每列和每个结果。
然后有一些非常讨厌的LIMIT漏洞:
$ php sql_exploits.php url
> 'http://www.reddit.com'
> "UNION SELECT name FROM CachedDomains"
Generated SQL: SELECT url FROM GrabbedURLs
WHERE url LIKE 'http://reddit.com%'
LIMIT 1
UNION
SELECT name FROM CachedDomains;
Returns: An entirely unexpected, potentially (probably) unauthorized query
from another, completely different table.
无论您是否了解攻击中的SQL,都是不明智的。这表明,即使是最不成熟的黑客也 很容易
绕过mysql_real_escape_string()。那是因为它是一种反应式防御机制。它仅修复数据库中非常有限且已知的漏洞。
所有转义都永远不足以保护数据库。实际上,您可以显式地对每个已知的漏洞进行反应,并且将来,您的代码很可能会受到将来发现的攻击的攻击。
适当且唯一(实际上)的防御是一种主动:使用准备好的语句。对准备好的语句的设计要格外小心,以便仅执行有效的和已编程的SQL。这意味着,如果正确完成,则会大大降低执行意外SQL的可能性。
从理论上讲,可以很好地实现的预处理语句不会受到所有已知和未知的攻击,因为它们是一种SERVER SIDE技术,由DATABASE SERVERS
THEMSELVES和与编程语言接口的库处理。因此,始终保证您会受到最低限度的保护,免受任何已知的黑客攻击。
而且代码更少:
$pdo = new PDO($dsn);
$column = 'url';
$value = 'http://www.stackoverflow.com/';
$limit = 1;
$validColumns = array('url', 'last_fetched');
// Make sure to validate whether $column is a valid search parameter.
// Default to 'id' if it's an invalid column.
if (!in_array($column, $validColumns) { $column = 'id'; }
$statement = $pdo->prepare('SELECT url FROM GrabbedURLs ' .
'WHERE ' . $column . '=? ' .
'LIMIT ' . intval($limit));
$statement->execute(array($value));
while (($data = $statement->fetch())) { }
现在不是那么难吗?而且它的 代码减少了百分之四十七 (195个字符(PDO)对375个字符(mysql_),这就是我所说的“充满胜利”。
编辑:为了解决这个答案引起的所有争议,请允许我重申我已经说过的话:
使用准备好的语句使您可以利用SQL Server本身的保护措施,因此可以保护您免受SQL Server人们所了解的事情的影响。
由于这种额外的保护级别,无论多么彻底,您都比仅使用转义安全得多。
问题内容: 所以这是我们所有人都应该知道的事情,当我第一次看到它时就在我脑海中浮现。 我知道该版本从5.3开始弃用,但的实际区别是什么。 我以为那是完全一样的,除了需要为mysql资源提供第二个参数。 因此,我当时很好地认为,字符串的处理方式一定有所不同,因为不需要2个函数。 因此,我当时认为区别完全在于语言环境和字符编码。? 谁能为我解决这个问题? 问题答案: 不同之处在于,仅将字符串视为原始字
问题内容: 在PHP手册中,有一条注释: 注意:如果不使用此功能对数据进行转义,则该查询容易受到SQL注入攻击的攻击。 这足以进行反SQL注入吗?如果没有,您能举个例子和一个好的反SQL注入解决方案吗? 问题答案: 通常足以避免SQL注入。不过,这确实取决于它是否没有错误,即它 存在 脆弱性的可能性很小(但是这还没有在现实世界中体现出来)。准备好的语句是在概念上完全排除SQL注入的更好的替代方法。
问题内容: 我正在从头开始构建XML文件,并且需要知道htmlentities()是否会转换每个可能破坏XML文件(可能还有UTF-8数据)的字符? 这些值将来自twitter / flickr提要,因此我需要确保- 问题答案: 这不是 构建合法XML的保证方法。 如果您只担心这,请使用代替。如果您的数据表示形式与XML文档的编码形式之间存在编码不匹配的情况,则可以解决/覆盖它们(这样做会使XML
在这个问题中,确认了< code > _ _ builtin _ CPU _ supports(" av x2 ")不检查操作系统支持。从英特尔文档中,我知道除了检查CPUID位之外,我们还需要检查与x86-64指令< code>xgetbv相关的内容。上面链接的英特尔文档提供了用于检查的代码: 问题:这个检查加上CPUID检查是否足以保证AVX2指令不会使我的程序崩溃? 额外问题:这张支票到底在
问题内容: 有些人认为这样做存在一些缺陷,即使正确使用也无法保护您的查询。 带一些化石的物品作为证明。 因此,问题是:mysql [i] _real escape_string()完全不可接受吗? 还是仍然可以使用此功能来创建自己的预备语句? 请提供校对码。 问题答案: 从MySQL的C API函数描述 : 如果需要更改连接的字符集,则应使用函数而不是执行(或)语句。的工作方式类似,但也会影响所使
问题内容: 在http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat- sheet/?akst_action=share- this上 ,有一节声称您可以使用某些亚洲字符编码绕过mysql_real_escape_string 用BIG5或GBK绕过mysql_real_escape_string() “注入线” に关する追加情