Каковы меры, необходимые для предотвращения или прекращения инъекций JavaScript в веб-приложении PHP, чтобы конфиденциальная информация не выдавалась (лучшие практики в PHP, HTML/XHTML и JavaScript)?Предотвращение JavaScript-инъекций в веб-приложении PHP
Хорошим первым шагом является применение методов, перечисленных в question Gert G linked. Это подробно рассмотрен целый ряд функций, которые могут быть использованы в различных ситуациях, чтобы очистить вход, в том числе mysql_real_escape_string, htmlentities(), htmlspecialchars(), strip_tags() и addslashes()
лучший путь, когда это возможно, чтобы избежать вставки пользовательского ввода непосредственно в базу данных , Используйте whitelist input validation: в любой ситуации, когда у вас есть только ограниченный диапазон опций, выберите из жестко заданных значений для вставки, вместо того, чтобы вводить данные из любой формы, обращенной к стороне клиента. В принципе, это означает наличие только определенных значений, которые вы принимаете, вместо того, чтобы пытаться устранить/противодействовать злобному/неправильному образу/вредоносному вводу.
Например: Если у вас есть форма с выпадающим списком элементов, не используйте ввод из этого раскрывающегося списка для вставки. Помните, что вредоносный клиент может редактировать информацию, отправленную с помощью формы, даже если вы считаете, что у них ограниченные возможности. Вместо этого, выпадающий список ссылается на индекс в массиве в вашем серверном коде. Затем используйте этот массив, чтобы выбрать, что нужно вставить. Таким образом, даже если злоумышленник пытается отправить вам вредоносный код, он никогда не попадает в вашу базу данных.
Очевидно, что это не работает для приложений свободной формы, таких как форумы или блоги. Для этих целей вам придется отказаться от техники «первого шага». Тем не менее, существует широкий спектр опций, которые можно улучшить с помощью проверки входных данных в белый список.
Вы также можете использовать parameterized queries (также подготовленные операторы с переменными связывания) для ваших взаимодействий sql, где это возможно. Это скажет серверу базы данных, что все входные данные являются просто значением, поэтому он смягчает множество потенциальных проблем от инъекционных атак. Во многих ситуациях это может даже охватывать приложения свободной формы.
Если не пропуская ничего, что должно быть отформатирован как HTML, то используйте:
strip_tags() <- Eliminates any suspicious html
, а затем выполнить следующую команду, чтобы очистить перед сохранением в БД
mysql_real_escape_string()
Если Аякса экономит пользователь вводил html через текстовое поле или wysiwyg, а затем просматривал с помощью HTMLPurifier, чтобы вырезать javascript, но разрешать теги html.
Предположим, что в моем файле csv у меня есть столбец, в который я положил значение столбца, например , то как я могу удалить это значение столбца и сделать его null –
Рассчитайте любое значение, которое вы выводите на html, с htmlspecialchars() по по умолчанию.
Только извините, что не использовал htmlspecialchars(), когда вам нужно вывести на html строку, содержащую html. В этом случае вы должны быть уверены, что эта строка из полностью безопасного источника. Если у вас нет такой уверенности, вы должны передать его через whitelist html filter, который позволяет использовать только ограниченный набор тегов, атрибутов и значений атрибутов. Вы должны особенно внимательно относиться к значениям атрибутов. Вы никогда не должны допускать, чтобы все передавалось как значение атрибута, особенно для таких атрибутов, как src, hef, style.
Вы должны знать все места в своем webapp, где вы выводите что-либо в html без использования htmspeciachars(), убедитесь, что вам действительно нужны эти места, и имейте в виду, что, несмотря на всю вашу уверенность, эти места являются потенциальными уязвимостями.
Если вы думаете, что это слишком осторожно: «Зачем мне нужна htmlspecialchar() эта переменная, которую я знаю, она содержит только целое число и освобождает все драгоценные циклы процессора?»
Помните об этом: вы не знаете, вы только думаете, что знаете, что циклы процессора являются самой дешевой вещью в мире, и почти все они будут потрачены впустую, ожидая базы данных или файловой системы или даже доступа к памяти.
Также не используйте фильтры черного списка html. Youtube совершил эту ошибку, и кто-то вдруг обнаружил, что только первый <script> удален, и если вы введете второй в комментарии, вы можете ввести любой Javascript в браузер посетителей.
Аналогично, чтобы избежать SQL-инъекций, обработайте с помощью mysql_real_escape_string() все значения, которые вы приклеиваете к SQL-запросу, или еще лучше используете инструкции PDO Prepared.
Я не согласен полностью с другими предоставленными ответами, поэтому опубликую свои рекомендации.
Рекомендуемая литература XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
Html Injection: Всякий раз, когда отображение любой представленный пользовательский контент, он должен быть надлежащим образом очищены с htmlspecialchars или htmlentities при указании ENT_QUOTES, если используется внутри одинарных кавычек. Я бы рекомендовал никогда не инкапсулировать в одинарные кавычки и всегда инкапсулировать ваши атрибуты в двойные кавычки (не опускайте их). Это относится к вещам, таким как:
<input value="<?php echo htmlspecialchars($var); ?>" />
<textarea><?php echo htmlspecialchars($var); ?></textarea>
<p><?php echo htmlspecialchars($var); ?></p>
<img width="<?php echo htmlspecialchars($var); ?>" />
Javascript Injection: Это лучшая практика (но не всегда практично), чтобы никогда не эхо пользовательского контента в события и JavaScript. Однако, если вы это сделаете, есть некоторые вещи, которые можно сделать для снижения риска. Только передать целочисленные id. Если вам требуется что-то вроде спецификатора типа, то перед выдачей используйте белый список и/или условную проверку. Возможно, принудительное включение пользовательского контента в буквенно-цифровой формат только тогда, когда это необходимо; preg_replace("/[^A-Za-z0-9]/", '', $string);, но будьте очень осторожны, что вы разрешите здесь. Включите только контент, когда он заключен в кавычки, и обратите внимание, что htmlspecialchars/htmlentities не защищает вас здесь. Он будет интерпретироваться во время выполнения, даже если он был переведен в html-объекты. Это относится к вещам, таким как:
<a href="www.stackoverlow.com/?id=<?php echo (int)$id; ?>">Click</a>
href, src, style, onClick, etc.
Не эхо любого пользовательского контента в других областях, таких как тело сценария теги и т.д., если он не был вынужден к междунар или какой-то другой очень ограниченного набора символов (если вы знаете, что делаете).
SQL Injection: Использование Prepared statements, связать пользовательский контент для них, и никогда напрямую вставить пользовательский контент в запросе. Я бы рекомендовал создать класс для подготовленных операторов с вспомогательными функциями для разных базовых типов инструкций (и, в то время как по теме, функционализировать все ваши заявления базы данных). Если вы решите не использовать подготовленные заявления, используйте mysql_real_escape_string() или аналогичные (not addslashes()). Проверять содержимое по возможности перед сохранением в базе данных, например, форсировать/проверять тип целочисленных данных, условные проверки типов и т. Д. Использовать соответствующие типы столбцов базы данных и длины. Помните, что главная цель здесь - предотвратить внедрение sql, но здесь вы также можете сделать защиту от html/javascript.
Другие ресурсы Я провел некоторое исследование в Интернете в надежде найти простое решение, уже общедоступное. Я нашел OWASP ESAPI, но, похоже, довольно устарел. Ссылки на версию php разбиты на несколько мест. Кажется, я нашел его здесь; ESAPI PHP, но снова он довольно устарел и не так прост, как я надеялся. Однако вы можете найти это полезным.
В общем, никогда не предполагайте, что вы защищены, например, используя htmlentities в атрибуте onClick. Вы должны использовать правильный инструмент в нужном месте и избегать действий в неправильном месте.
Возможный дубликат [Как предотвратить атаки инъекций кода в PHP?] (Http://stackoverflow.com/questions/1205889/how-to-prevent-code-injection-attacks-in-php) –
@Gert G : Я считаю, что этот вопрос касается инъекций SQL и XSS ... а не инъекций JavaScript. – Alerty
Неполное перекрытие - эти методы применяются, но существуют другие меры, не охватываемые пунктами, предложенными в этом вопросе. Смотри ниже. –