Насколько безопасный мой веб-сайт?
Как начинающий веб-разработчик, я стараюсь изо всех сил очищать все вводы данных пользователем посредством проверок и что нет. Однако сегодня я узнал, что мой веб-сайт был взломан (я совместно использую их веб-сайт по запросу), и он действительно сделал мое удивление, как они делали это. Я нахожусь в процессе возвращения моего веб-сайта вместе. Что я должен сделать для предотвращения этих вещей? Есть ли люди, с которыми я должен говорить и спросить, насколько безопасный мой веб-сайт? К чему я могу сделать бережно хранить мой веб-сайт? Я записал свой веб-сайт в PHP и MySQL.
Обновление: Наконец восстановленный задние взлеты. Я использую $_GET["name"] в моем сценарии, и я предполагаю, что это - то, как они вошли в мой веб-сайт. Во-первых, они смогли поместить index.html/index.php файл в Каждую папку на моем сервере. Кто-либо знает, как я могу противостоять этому?
Обновление: Это на самом деле не был мой веб-сайт, который был взломан, все же хост. Пароль SSH был взломан, и он установил новый индексный файл в каждой папке.
6 ответов
Это чрезвычайно широкий вопрос, поэтому ответы, которые вы получите, одинаково широки.
Чтобы проверить свой веб-сайт на безопасность, вы можете выполнить тестирование на проникновение . Есть компании, которые сделают это за вас. Вы также можете посмотреть Google Skipfish .
Что вы можете сделать, чтобы обеспечить безопасность своего веб-сайта? Вы можете:
- Очистить и проверить все входные данные - также файлы cookie, они могут быть изменены, как и все остальное, что отправляется клиентом.
- Поддерживайте актуальность ОС и фреймворков с помощью последних исправлений безопасности. Если вы используете CMS, убедитесь, что у вас установлена последняя версия.
- Никогда не отправляйте обратно текст, отправленный пользователем, если вы сначала не закодировали его в HTML.
- Используйте параметризованные SQL-запросы, чтобы предотвратить атаки SQL-инъекций.
- В общем, Используйте защитный код .
Хотя он не охватывает все, вы можете рассмотреть возможность просмотра OWASP. Их Top ten за 2010 год был недавно выпущен и дает разумный обзор общих недостатков безопасности.
Предотвращение SQL-инъекций. Используйте надежные пароли. И всегда проверяйте вводимые пользователем данные (например, переменные _GET и _POST в php).
Две важные вещи, которые нужно проверить, - это SQL-инъекция и удаленное выполнение кода .
SQL-инъекция происходит, когда вы берете ввод из какого-то ненадежного источника (например, весь долбанный мир! ) и используете его как SQL-запрос. Исправление состоит в том, чтобы прекратить использование подстановки строк для построения запросов и обновлений и строго придерживаться параметризованных запросов / обновлений. Обратите внимание, что использование магических кавычек - гораздо худший подход к решению этой проблемы, поскольку гораздо легче ошибиться; « всегда параметризовать каждый запрос» - это более простой способ, который легче контролировать. (Да, вам действительно нужно проверить здесь весь свой код. Извините за это.)
Удаленное выполнение кода - это когда у вас есть какой-либо механизм, позволяющий клиенту веб-сайта запрашивать веб-сайт для запуска PHP, который не работает. t предварительно загружен на веб-сайт в каталог, в который веб-сервер не может писать. Да, это удобно, но крайне опасно, потому что хитрый взломщик может попросить веб-сервер загрузить руткит или другое гнусное содержимое. Раньше мы часто получали это с нашим основным веб-сервером на работе, поэтому теперь мы запускаем его в файловой системе строго только для чтения (с удаленным ведением журнала) с удаленным выполнением кода PHP (или, действительно, открытием любого другого подключения к не -белый сервер) категорически запрещено.Это ужасно расстраивает различные внешние консультанты по веб-дизайну, которых продолжают нанимать, но это потому, что они слишком часто не очень профессиональны во всем бизнесе по управлению безопасной системой, и это действительно означает, что весь этот класс атак заблокирован. .
(Также следует остерегаться XSS , хотя это не точно атака на ваш сайт. Это происходит, когда вы не цитируете ненадежный контент, исходящий из вашей базы данных правильно, позволяя выводить с вашего сайта отвратительный контент без его фактического взлома как таковой . Защита вашего сайта от получения таких вещей важна, но вы должны решить более серьезную проблему. сначала серьезные угрозы, чтобы ваш сайт больше не был токсичным зомби.)
- убедитесь, что ваша собственная машина не заражена. Существует множество троянов, собирающих пароли FTP. Кроме того, никогда не используйте FTP через незашифрованное беспроводное соединение - также существуют трояны, которые заставляют зараженный компьютер прослушивать беспроводную связь и красть пароли. По возможности используйте SFTP.
- найти достойного хозяина. Некоторые дешевые хостинг-провайдеры не препятствуют тому, чтобы сайт изменял файлы другого сайта, поэтому независимо от того, что вы делаете, ваш сайт может быть взломан через уязвимость другой веб-страницы, размещенной на том же сервере.
- всегда избегают ненадежного ввода в запросах SQL. Еще лучше использовать параметризованные запросы.
- всегда избегают ненадежного ввода (включая текущий URL, ссылку, пользовательский агент браузера, заголовки HTTP и т. Д.) Перед отображением его на веб-странице. Это на удивление сложно (см. http://ha.ckers.org/xss.html для некоторых неочевидных атак), используйте хорошую библиотеку, такую как HTML Purifier , вместо того, чтобы пытаться напишите свой.
Дриис дал хороший ответ. Я хотел бы просто добавить, что использование хранимых процедур также может быть очень полезным.