выводить данные из базы данных с помощью htmlspecialchars(), которые были отфильтрованы с помощью filter_input()

Я использую filter_input() для фильтрации любых данных, поступающих от пользователя, перед вставкой в ​​database.

Это плохая практика. Не искажайте данные перед тем, как вставить их в базу данных. Это 2015 год; не дезинфицируйте, вместо этого используйте подготовленные операторы.

$db = new \PDO(
    'mysql:host=localhost;dbname=mydatabase;charset=UTF-8',
     $username,
     $password
);

// other stuff in between

$statement = $db->prepare(
    "INSERT INTO yourtable (email, username) VALUES (:email, :username);"
);
$success = $statement->execute([
    ':email'    => $_POST['email'],
    ':username' => $_POST['username']
]);

Подготовленные операторы устраняют необходимость в filter_input(). Делая это, вы не добавляете глубокую защиту, вы просто разрушаете целостность данных и создаете себе головную боль.

При обработке вывода, если вы хотите разрешить HTML, используйте HTML Purifier.

В противном случае используйте htmlspecialchars($output, ENT_QUOTES | ENT_HTML5, 'UTF-8') для достижения наилучших результатов.

Рекомендуемая литература: Безопасность веб-приложений Тейлора Хорнби.

Я думаю, что проблема с вашей стратегией.

Вам, конечно, нужно фильтровать входные и выходные данные, но вы накладываете их друг на друга - двойной экран.
Проблема в том, что ваш входной фильтр выполняет также работу выходного фильтра.

Поскольку я использовал filter_input() для фильтрации данных перед отправкой в ​​базу данных, безопасно ли выводить данные напрямую ($post=$posted_data;) из базы данных без использования htmlspecialchars?

Нет. Не доверяйте своей базе данных, по крайней мере, не всегда. Это не первый случай, когда SQL-инъекция вызвала огромный XSS.

Если мне нужно использовать htmlspecialchars для вывода данных, то как я могу это сделать в этом случае?

Как я уже сказал выше, прекратите использовать входной фильтр для фильтрации вывода. Ваш входной фильтр должен просто убедиться, что данные безопасны для внутреннего использования, чтобы защитить ваше приложение от операций без отступов. Таким образом, вам не нужно экранировать HTML перед вставкой в ​​базу данных, и в качестве бонуса вы сэкономите место.

С другой стороны, выходной фильтр заботится о конечном пользователе. Вы берете данные из БД и отправляете их пользователю. Мы говорим о htmlspecialchars, что хорошо с ENT_QUOTES, но, на мой взгляд, этого недостаточно. Вам также следует экранировать такие символы, как ( ) [ ] = + - \, так как в некоторых случаях вам не нужно открывать/закрывать любой тег или использовать кавычки для успешной атаки XSS. Например, когда вы выводите данные в onclick и т. д.

Я только что увидел, что htmlspecialchars имеет параметр double_encode, который в конечном итоге решит вашу проблему:

htmlspecialchars($string, ENT_QUOTES, "UTF-8", false);

Это всегда будет экранировать специальные символы HTML и не будет экранировать уже экранированные вещи.

Вы хотите пойти наоборот :) htmlspecialchars_decode()

Вам не нужно, когда вы кодируете их и сохраняете в БД, они будут отображаться на веб-странице (когда вы используете echo $result['message'];), как и должны. Браузеры автоматически декодируют их.

Я использую эту функцию для ввода данных:

function stripinput($text) {
    if (!is_array($text)) {
        $text = trim($text);
        $text = preg_replace("/(&)+(?=\#([0-9]{2,3});)/i", "&", $text);
        $search = array("&", "\"", "'", "\\", '\"', "\'", "<", ">", "&nbsp;");
        $replace = array("&amp;", "&quot;", "&#39;", "&#92;", "&quot;", "&#39;", "&lt;", "&gt;", " ");
        $text = str_replace($search, $replace, $text);
    }else{
        foreach ($text as $key => $value) {
            $text[$key] = stripinput($value);
        }
    }
    return $text;
}