Я использовал продукт Перекрестного соединения Codeweavers для того, чтобы время от времени делать это.
http://www.codeweavers.com/products/cxmac/
Это - различная опция к виртуализации и дает Вам немного больше контроля, чем некоторые размещенные решения. Однако это основано на ВИНЕ, и таким образом, можно потенциально получить все проблемы и проблемы, которые идут с выполнением его тот путь. Однако для основного тестирования без плагинов, и т.д., это работает отлично.
я не на 100% уверен в поддержке IE8, необходимо было бы проверить это, но это определенно оказывает Вам собственную поддержку 6 и 7.
mysql_real_escape_string
используется при вставке в базу данныхhtmlentities ()
используется при выводе данных на веб-страницуhtmlspecialchars ()
используется, когда ?strip_tags ()
используется, когда?addlashes ()
используется, когда?
htmlspecialchars
примерно совпадает с htmlentities
. Разница: кодировки символов.
Оба кодируют управляющие символы, такие как <
, >
, &
и т. Д., Используемые для открытия тегов и т. Д. htmlentities
также кодируют символы из других языков, например умляуты, символы евро и т. Д. Если ваши веб-сайты используют UTF, используйте htmlspecialchars ()
, в противном случае используйте htmlentities ()
.
htmlspecialchars
/ объекты
кодируют специальные символы, поэтому они отображаются, но не интерпретируются . strip_tags
УДАЛЯЕТ их.
На практике это зависит от того, что вам нужно делать.
Пример: вы закодировали форум и дали пользователям текстовое поле, чтобы они могли отправлять сообщения. Вредоносные просто попробуйте:
pictures of <a href="javascript:void(window.setInterval(function () {window.open('http://evil.com');}, 1000));">kittens</a> here
Если вы ничего не сделаете, ссылка будет отображаться, и жертва, которая нажимает на ссылку, получает множество всплывающих окон.
Если вы htmlentity / htmlspecialchar выведите свой результат, текст будет будь там как есть. Если вы его strip_tag, он просто удалит теги и отобразит его:
pictures of kittens here
Иногда вам может понадобиться смесь, оставьте там несколько тегов, например
( strip_tags
может оставлять там определенные теги). Это тоже небезопасно, поэтому лучше использовать какую-нибудь полноценную библиотеку против XSS.
Цитата из старой версии руководства по PHP :
Возвращает строку с обратной косой чертой перед символами, которые нужны быть заключенными в кавычки в запросах к базе данных и т. д. Эти символы - одинарная кавычка ('), двойная кавычка ("), обратная косая черта () и NUL (байт NULL ).
Пример использования addlashes () - это когда вы вводите данные в базу данных. Например, чтобы вставить имя O'reilly в базу данных, вам нужно будет экранировать его. Настоятельно рекомендуется использовать СУБД специальная функция escape (например, mysqli_real_escape_string () для MySQL или pg_escape_string () для PostgreSQL), но если СУБД, которую вы используете, выполняет
Кодируйте данные только в том месте, где они попадают в систему, для которой они должны быть закодированы - в противном случае вы столкнетесь с ситуациями, когда вы захотите манипулировать реальными данными.
Для SQL-инъекции - используйте связанные переменные, как описано в Как я могу предотвратить SQL-инъекцию в PHP? (здесь говорится о подготовленных операторах, но именно привязка дает вам защиту, а не подготовка).
Для XSS - если вы пишете в HTML в точке, где указан HTML или текст. Используйте htmlentities в момент создания документа. Я бы избегал хранить данные в этой форме в базе данных (кроме случаев, когда это возможно в системе с редкой записью и частым чтением, где производительность процессора / время доступа к диску становились и возникали проблемы, тогда у меня были бы raw_ и html_ версия столбца … Или просто используйте memcached или подобное).
Вам нужно использовать mysql_escape_string () только при вставке в базу данных и htmlentites при отображении HTML. Этого достаточно, если вы хотите предотвратить простую атаку с помощью инъекций, но, несомненно, существует множество других проблем безопасности, о которых вам следует знать при разработке веб-приложения, еще одной важной из которых является подделка межсайтовых запросов.
Взгляните на этот сайт Консорциум безопасности PHP . Я обнаружил, что это хороший сайт для общего обзора безопасности PHP (включая внедрение SQL и XSS).
Я бы не стал использовать htmlentities () при вставке данных в базу данных или выполнении запросов к базе данных. Если данные в вашей базе данных хранятся как сущности, тогда эти данные будут полезны только для чего-то, что понимает сущности html.
Вы должны использовать разные механизмы экранирования для разных типов вывода, например SQL - mysql_real_escape_string () , HTML - htmlentities () или htmlspecialchars () , оболочка - escapeshellarg () . Это потому, что символы, которые являются «опасными», различны для каждого из них - нет волшебного способа сделать любые данные безопасными для любого носителя вывода.