照顾XSS

在进入的过程中,HTML转义显然是错误的,但在用适当的代码替换代码之前,这可能是一个临时的修复。从长远来看,它将是不可维护的,并且在开始跨&编码字符执行子字符串操作(包括数据库可能自动执行的截断操作)的任何位置都会出现大量奇怪的应用程序级错误。这不太可能导致安全漏洞,但如果不仔细查看应用程序就无法判断。

如果您每次在$_会话中开始编码,您将很快得到长字符串(如&A)的乘法编码。

我认为人们只能攻击自己

或者,另一个网页上的攻击者可以重定向或iframe到您的网站,注入足够的脚本以显示一个与您的网站类似的假登录框,获取用户名和密码或自动删除其帐户。像那样的东西。不是很好。

建议这样做:echo htmlentities($post[input_]、ent quotes、_ utf-8_);

不需要HTMLEntities和所有这些参数-使用HTMLSpecialChars。

您可以通过以下方式保存一些按键:

function h($s) { echo(htmlspecialchars($s)); }
...
<?php h($POST['input']) ?>

真的没那么多麻烦。

盲目地转义前端的所有输入意味着处理该输入的程序的任何部分都必须处理<、>、&等的HTML转义版本。如果要将数据存储在数据库中,则会将HTML转义数据存储在数据库中。如果您在非HTML上下文中使用数据(如发送电子邮件),人们将看到<而不是<,等等。

你可能只是想在输出时逃跑。

上面的代码不起作用,但是这样做:

$_POST = clean_input($_POST);
$_GET = clean_input($_GET);
$_COOKIE = clean_input($_COOKIE);
$_SESSION = clean_input($_SESSION);

function clean_input($array){
    if(count($array)){
        foreach ($array as $key => $value) {
            $array[$key]=htmlentities($value, ENT_QUOTES, 'UTF-8');
        }
    }
    return $array;
}

我只是想弄清楚这里可能出什么问题。

我最初的回答是建议您首先确保将表示逻辑与业务逻辑等分开处理。

如果表示逻辑确实是独立的,那么您需要评估当前如何输出到屏幕。您是否可以通过相同的函数调用运行每个输出,从而将所有输出转义到屏幕?

例如,当您转到实际输出到屏幕时调用clean_output,但我不会在数据库操作或对数据进行业务逻辑操作之前调用clean_output,因为很有可能您将逃避本应保留的内容。