Все мы, так или иначе, хотели бы быть уверенны в том, что наш сайт или блог никто не сможет взломать. Но увы, реальность такова, что любая система уязвима, как бы сильна она не была бы защищена. Все упирается лишь в ресурсы и в упорство взломщика… Хм… Что то меня не туда потянуло… Будем считать это предисловием =)
Не так давно я писал о том как . Но допустим вы взяли уже готовую CMS и не знаете, как там реализованна загрузка, да и вобще вся защита. Конечно, особо пытливые и грамотные разработчики изучат код этой цмс прежде чем поставят на свой сайт. Но что делать тем у кого нет столько времени?
Хорошо, или допустим вы из тех кто считает что безопасность и правильная настройка сервера лишней не бывает? Если так то добро пожаловать под кат.
Нет, в статье вы не найдете какой-то супер пупер плагин, фильтрующий все данные, который нужно приинклудить ко всем файлам. Моя идея заключается в использовании директивы auto_prepend_file и постройки списка разрешенных файлов… Но в общем читайте сами…
Данная идея у меня давно сидела в голове, но наконец у меня дошли руки, хоть ничего сложного тут и нету, и я смог эту систему реализовать и написать статью =)
Как я уже говорил выше, система основанна на работе директивы auto_prepend_file в php.ini . Отвечает она за установку скрипта, который будет выполнятся ПЕРЕД выполнением основного.
К примеру вы открыли index.php, а перед его выполнением запускается файл, указанный в auto_prepend_file . Суть в том, что в этом скрипте мы сможем контролировать дальнейшую работу остальных скриптов. Грубо говоря, продолжить работу и запустить запрошенный скрипт, или завершиться сразу (die() ).
К примеру ситуация — злоумышленник залил на ваш сайт шелл через какую нибудь уязвимость и пытается его открыть в браузере. А вместо его шелла, ему, без всяких на то причин, отдается, вот такая вот ошибка:
Меня бы подобное ввело бы в ступор…
Для работы мой системы, нужен список разрешенных файлов, доступ к файлам, отсутствующим же в этом списке будет блокироваться.
(Не знаю нужна ли эта диаграмма, вроде бы и так все должно быть понятно…)
Конечно составлять такой список вручную — дело не благородное, поэтому я пришел к выводу, что имеет смысл реализовать так называемый «режим обучения». Режим в котором все обращения ко всем скриптам будут заносится в список разрешенных файлов автоматически.
Что это дает? Вы можете запустить эту систему в режиме обучения и продолжить пользоваться своим сайтом. По мере того как вы будете им пользоваться, ваша база будет пополнятся теми страницами, которыми вы пользуетесь (простите за каламбур). И допустим через месяц — другой у вас в списке будут содержаться все файлы которые имеют отношение к вашему сайту (к которым вы непосредственно обращались).
Причем заметьте, в списке будут содержаться только те файлы, с которыми вы непосредственно будете работать. Обычный среднестатистический движок сайта имеет кучу подключаемых файлов (с классами, с функциями, библиотеки, модули и прочее), эти файлы в этот список не попадут, и доступ к ним в дальнейшем будет блокироваться на уровне нашей защиты (конечно среднестатистические движки имеют защиту от прямого запуска, но вдруг гдето эта защита пропущенна).
Что умеемТак как это концепт, то и умеем мы не много.
- Блокирование неразрешенных скриптов (собственно основная функция). Но опять же это настраиваемо, можно не блокировать соединение, а только лишь уведомлять админа по email
- Уведомление о нелегитимных запросах администратору по email (краткий отчет или полный отчет, последний включает заголовки пакета и данные POST запроса если таковые имеются)
- Можно указать IP администратора, который будет иметь доступ к любым скриптам, т.е. данная система его затрагивать не будет (эти IP не будут участвовать в режиме обучения). К примеру теперь не надо закрывать .htaccess -ом софтины типа PhpMyAdmin, SupexDumper и прочие системные утилиты.
- Ксати Ip адреса поддерживают простенькие маски=)
- Полностью прокомментированный код, и подробно описанна каждая директива конфигурации
- Хз что еще…
Теперь о том как встроить эту защиту в ваш сайт…
Для этого вам необходим доступ к файлу php.ini
auto_prepend_file=[путь до распакованного файла main.php]
Многовато шагов, конечно, но с этим, как мне кажется, справится даже ребенок.
Если вам необходимо переобучить систему (с нуля или дополнить), то вам необходимо:
Лукавить я не буду, и теперь расскажу о недостатках.
- Пожалуй главный недостаток по сравнению с которым меркнут все остальные, это то, что эту систему можно обойти. Вы спросите: как же так? Все очень просто, директиву auto_prepend_file
можно указать и в .htaccess
. И если подойти трезво то если злоумышленник вдруг смог залить шелл, то наверняка он сможет залить и свой .htaccess
в котором он может отключить оригинальную директиву.
Это работает только под apache , но к примеру под nginx этот трюк не выйдет (у nginx нет файлов.htaccess). НО! Под Nginx можно вообще залить . - Злоумышленник может отредактировать «разрешенный» скрипт если есть допустимые права на это, и с этим наша система ничего, к сожалению, сделать не сможет. Разве что необходимо устанавливать правильные права на все исполнемые файлы
- Помимо PHP есть еще всякие perl, cgi и прочее… с ними данная система не работает.
- Дополнительная нагрузка. Но вртяли эта нагрузка будет ощутима.
Именно поэтому, казалось бы такая оригинальная система, не может называться идеальной. Но она вполне подойдет в качестве простой превентивной меры, которая остановит не самых упоротых упертых взломщиков. По крайней мере данная система сможет отнять время у взломщика на проведение атаки. К примеру, система уведомит администратора о попытке взлома, дав тем самым администратору возможность устранить уязвимость до тех пор пока злоумышленник разберется с причиной его неудач.
ЗаключениеВсе же, так или иначе, это концепт, может быть вы сможете придумать на ее основе что то лучшее. А может быть вас устроит моя система.
На мой взгляд разумной защиты много не бывает. Использовать что-либо подобное или нет, у вас на сайтах решать вам.
Фуф. Ну и написал я, почти целый день ушел. Простите если описал несколько сумбурно. В общем задавайте ваши вопросы в комментариях, я постараюсь ответить.
PS: хоть я и кодил максимально адекватно, скрипт может иметь баги. Тестировалось на win/apache/php 5.2 — все было ок.
Во всем мире в аэропортах можно найти лозунг "Security is not a joking matter" (Безопасность - прежде всего). Такой же лозунг каждый системный администратор должен был бы закрепить рядом со своим сервером PHP. А любой, кто подключается к серверу, находящемуся в Интернете, должен принимать надлежащие меры защиты или рисковать потерей данных и даже денег из-за того, что злонамеренные взломщики программного обеспечения сумеют нанести ущерб, пользуясь клавиатурой своего компьютера.
Разработчик сайта, озабоченный проблемами защиты, обязан постоянно повторять: "Не доверяйте сети". Если вы беспокоитесь о защите своего сайта, повторяйте это высказывание, разрабатывая код будущих страниц сайта. Любая информация, передаваемая на сервер по сети (будь то URL, данные из формы HTML или данные, поступающие через какой-то другой сетевой порт), должна рассматриваться как потенциально опасная. В настоящей статье предложено несколько методов, позволяющих обезопасить поступающую информацию. Необходимо не только применять эти методы, но и уделять определенное время для того, чтобы обнаружить другие потенциальные опасности и найти способы их предотвращения.
Вторым эмпирическим правилом создания защищенного сайта является следующее: "Минимизируйте ущерб". Что будет, если написанная вами программа, которая, по вашему мнению, является вполне надежной, фактически окажется уязвимой? Даже просто для того, чтобы оставаться в полной безопасности, ограничивайте ущерб, который мог бы нанести нарушитель, воспользовавшись этой уязвимостью.
Когда на ваш сайт приходят посетители, они надеются, что сайт содержит действительную информацию, которая не нанесет вреда ни им, ни компьютерам, и что предоставленная ими информация будет обрабатываться должным образом. Для посетителя всегда имеется определенный риск нарушения защиты при взаимодействии с любым сайтом, независимо от того, развлекательный ли это сайт, информационный или электронной коммерции. Обязанности по защите посетителей от таких рисков возложены на проектировщика сайта. Это означает, что вы обязаны не только надежно хранить на своем сервере информацию, предоставленную посетителями, но и принять меры по защите предоставляемой информации во время ее передачи с компьютеров посетителей на ваш сервер.
Но все эти соображения не должны препятствовать вашим намерениям, например, касающимся вывода своего сайта электронной коммерции в оперативный режим.
Возможные нападенияПодключение сервера к Интернету можно сравнить с открытием магазина на оживленной улице. Вы хотели бы иметь много посетителей, но, не принимая мер предосторожности, можете столкнуться с тем, что вашей беспечностью воспользуются не обычные посетители, а весьма нежелательные гости.
Обычно хакерами называют тех, кого было бы правильнее назвать взломщиками программной защиты . В компьютерном сообществе взломщиками защиты называют специалистов, которые, пользуясь удачным стечением обстоятельств или своими навыками, преодолевают защиту компьютерных систем и наносят ущерб. А хакеры - это программисты, умеющие виртуозно составлять программы и способные не только разбираться в сложном коде, но и самостоятельно писать эффективный (и часто недоступный для понимания посторонних) код на многих языках. Для программиста приобретение звания хакера является честью, а звание взломщика программного обеспечения, по-видимому, означает, что его владелец должен следить за заметками в рубрике "Разыскивается".
Не понимая того, насколько унизительным является звание взломщика программного обеспечения, многие начинающие программисты вступают на эту стезю, прибегая к использованию инструментальных средств и сценариев, которые они находят в веб. Таких начинающих взломщиков называют script-kiddie или по нашему кулхацкерами. Эти люди часто сами почти не понимают, что они делают. Обычно именно такая категория нарушителей стоит за примитивными атаками, такими как компрометация сайта, XSS и SQL-инъекции.
Компрометация сайта и атаки XSSСлучаи компрометации сайта, которые чаще бывают в большей степени неприятными, чем действительно вредными, довольно распространены, поскольку многие сайты открывают для взломщика программной защиты возможность объявить всему миру о том, что он сумел добиться своей цели. Для компрометации неправильно спроектированного веб-сайта иногда достаточно воспользоваться одним лишь веб-браузером. Рассмотрим, например, следующую программу:
Страница с простой формой добавления комментариев Основы PHPЭта программа реализует систему комментариев в очень примитивной форме (если вы изучаете мое руководство по PHP с начала, то возможно вы еще не знакомы с операциями работы с базами данных; если это так, то рекомендую вам вернуться к этой статье после ознакомления с соответствующим материалом по MySQL).
Читая этот код, опытный программист начинает чувствовать себя не совсем уверенно (помните - "Не доверяйте сети"). Такая программа принимает данные формы, которые, согласно ожиданиям, должны содержать текст комментария. Этот текст присваивается переменной $comment и сохраняется в базе данных для отображения перед следующими посетителями. Если введенные данные будут такими, какие мы ожидаем, то проблемы не возникнут.
А теперь поставьте себя на мгновение на место кулхацкера и представьте, что произойдет, если во входных данных будут содержаться дескрипторы HTML. Эта простая программа механически вставит такие дескрипторы в формируемую страницу, и эта искаженная страница будет разворачиваться в браузерах других посетителей вместо обычной. Одним из дескрипторов, которые могут оказаться особенно опасными с точки зрения защиты данных, является дескриптор . Взломщик программной защиты может вставить такой комментарий:
Внедрение вредоносного JavaScript-кода
Подобная атака известна как межсайтинговый скриптинг или XSS . После закрытия и открытия этой страницы, браузер получит такой дескриптор и немедленно приступит к загрузке страницы фиктивного сайта, а не страницы взломанного сайта. Проявив небольшую изобретательность, взломщик программной защиты после этого сможет пользоваться доверием посетителей к вашему сайту, чтобы извлекать такую персональную информацию, как пароли или номера кредитных карточек (с помощью фишинга - подделки дизайна и структуры вредоносного сайта под взломанный сайт).
Решение подобной проблемы состоит в том, что входные данные следует предварительно обрабатывать в целях обеспечения безопасности. В данном случае необходимо преобразовать в какую-то безопасную форму любые символы, имеющие особый смысл для браузера. К счастью, в языке PHP предусмотрен способ выполнения именно такого преобразования. Функция htmlentities()
преобразует символы , " и & в представления этих символов в виде так называемых символьных сущностей HTML (такие как
Загрузка...