Защита сайта от взлома [закрыт]

Создал, наконец, свой первый проект. Начитался кучу информации по защите сайта (sql-инъекции и т.д., и т.п.). Но я понимаю, что в сети не рассматриваются все нюансы по защите, поэтому я создал шуточный клон сайта, залил на сервер и пытаюсь найти дыры в безопасности. Пока безуспешно - стоит строгая проверка на url-адрес, админка скрыта в таинственной папке)))
Вопрос очевиден - я хочу понять, есть ли возможность взломать сайт, открыть структуру папок и попасть в админку.
Уважаемые программисты, помогите, пожалуйста! Я прописал в .htaccess вывод любых предупреждений и ошибок, поэтому буду премного благодарен за взлом собственного сайта! Фишка в том, что весь проект написан собственноручно в Коделобстере без использования готовых шаблонов.
P.S. Для админ-части аутентификация написана собственноручно, пожалуйста, взломайте и ее. Попыток входа - 3. Сейчас я увеличу до 20.
Псевдосайт - http://mars.fh38095o.bget.ru/
P.P.S. Кто действительно заинтересуется и покажет, что невозможно найти ссылку на админку, я скину url в личку.

Ответ

Я не знаю, что такое "коделобстер" но, судя по всему, 'то какая-то платформа для создания уязвимых сайтов. Выкладывать на проверку код со столь хрестоматийной SQL инъекцией должно быть стыдно.
Ну и просить протестировать на безопасность игрушечный сайт, в котором всего 5 таблиц (block_pages,category,feedback,simple_pages,temple) и нет практически никакой информации - это как бы смешно. Ты бы еще выложил программу Hello world и попросил ее взломать. Что там ломать? Зачем? Кому нужен этот сайт? Если бы, скажем, сайт хранил номера кредиток, то они бы уже уплыли, как эти глубокомысленные вопросы из таблицы feedback:
alert('hello'); hello ddddddd dddd ddddddddddd dddddddddddddddd dd dddd ddddddddd ddd dddddddd dd dddddd dddddddddddd ddddddddd ddddddddddd dd dddd dddddddddddd dd ddd ddddddd dddddddddd dddddddddddd ddd dd dddd dddddddd dddd ddddd dddd ddddddd d dddd dddddddd ра дывал п у дм жчсдялыпыа adfasdf asadf adf asdf asdf adf asdfasdfasfdasdfagfsdghsdbcxasdf
Опять же, интерфейса к этой таблице на сайте нет. То есть, в последний момент автор забоялся, и прикрутил вместо нее к сайту Disqus. Очень, очень остроумный способ тестирования.
Судя по тому, что в комментариях автор путает XSS с SQL инъекцией (собираясь защищаться от первой с помощью "stmt"), а "скрытая админка" почитается им как верх хитроумия в защите сайта, то ему просто рано выклыдывать что-либо на тестирование.
По поводу намека на дыры. Дело в том, что никакие намеки здесь не нужны. Все, что тебе нужно знать - это то, что была SQL инъекция. Ну так об этом было сказано безо всяких намеков, открытым текстом. А вот какая конкретно - для защиты знать не нужно, от слова "совсем". Фишка в том, что для обеспечения защиты про дыры знать не нужно. Защита от атак иррелевантна самим атакам. Про то что нужно для защиты - написано было во всех учебниках (ну, кроме устаревших): надо, чтобы любые переменные попадали в запрос не напрямую, а через плейсхолдеры. Вот это и надо было делать. Ты об этом знал (как следует из твоих комментариев, когда ты собрался XSS лечить через "stmt"), но не придавал значения. Вот теперь, после того как ты закрыл эту дыру, надеюсь, будешь придавать.
И опять же, сам видишь - чтобы закрыть дыру тебе не понадобилось узнавать, как был произведен взлом. Чтобы строить защиту, надо уметь строить, а не ломать. "Намекать на дыры" бесполезно. Здесь смысл не в том, чтобы залатать одну конкретную, а в том, чтобы все запросы без исключения выполнялись по единому безопасному принципу. И тогда хакер пусть хоть в лепешку разобьётся, но ни одной дыры не найдёт.
По поводу XSS. Ситуация довольно забавная. Действительно, где-то в недрах сайта режется, почему-то, прямой слеш. Но, разумеется, это не может помещать, и XSS можно внедрить и без слеша. Но тут уже, увы, на твою защиту встают браузеры, которые научились отфильтровывать такие явные XSS-через-запрос за горе-программистов.
Но опять же, надеяться на браузер - это значит гарантированно налететь на инъекцию. Такие вещи надо делать самому. Причем делать, опять же, не "как бог на душу положит", а сис-те-ма-ти-чес-ки!
Вот ты вырезал теги в фидбеке и успокоился. А в идентификаторе страницы - нет. А здесь должна быть та же система, что и с SQL инъекциями - не надо сидеть и думать, где знадо защищаться, а где не надо. Защищаться надо везде!
В защите от XSS аналогом плейсхолдеров в SQL может являться шаблонизатор с автоискейпингом. То есть, мы можем считать себя в безопасности, если
Любой, абсолютно любой вывод производится только через шаблонизатор. По умолчанию шаблонизатор форматирует ВСЕ выводимые переменные. И только те, для которых указано явно, что они должны выводиться как есть - выводятся как есть.
Таким шаблонизатором, в частности, является Twig
Да, и еще одно замечание. Код
or die("Ошибка в запросе $zapros");
это просто подарок взломщику. Скажем, если бы его не было, то я бы просто не взялся ломать - это потребовало бы куда больше времени, а время - деньги.
Судя по всему, ты прямо в коде обращаешься к функциям mysqli. Этого делать тоже не надо, но к безопасности это отношения не имеет, а для практики сойдёт. Но эти свои чудовищные or die() постирай все до единого. Вместо этого перед коннектом к mysql напиши одну строчку,
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);