Гостевая книга - поиск уязвимостей

Линукс тут при чём?

Линукс тут при чём?

Линукс при том, что сайт создавал с целью публикации статей о свободном ПО, исходных текстов своих программок. Ядро Линукс тоже является свободным ПО с открытым исходным текстом.

Как-то тухло. Да и без кода, или хотя бы рабочего примера, тебе едва ли чего скажут внятного.

надо было постить в соответствующий раздел - вебдевелопмент

Линукс при том, что сайт создавал с целью публикации статей о свободном ПО, исходных текстов своих программок.

Т.е. к твоему быдлокодингу - никакого отношения не имеет?

Исходный код гостевой книги

cp1251

Ok. fixed

Не занимайся ерундой. Ладно php, хотя зачем сейчас его учить? Но это еще можно понять. Но зачем текстовый файл? Это никому не нужно, знание работы с db, куда важней. Да и на голом php почти никто не едет, используй yii хотя бы. Ол-ло-ло большой не нужно, оверхед, но так раз он тебя познакомит с MVC, работой с базой (хоть и через ActiveRecord (вроде так называется?)), прочим ништякам.

Прокомментирована каждая строчка, семикратно(!) вложенный if, код перемешан с HTML-представлением - все в лучших традициях PHP :)

1) Надо SQLite
2) В жизни не поверю, что для PHP нет библиотек для валидации форм и удаления всяких подозрительных вещей
3) В конце концов, можно очень легко и просто подключить к вашему сайту disqus и не заморачиваться с хранением чужих личных данных
4) Взяли бы какой-нибудь небольшой фреймворк, действительно.

Я согласен, для самообразования делать сайт «ручками» очень интересно и всеми руками за, но все-то велосипеды, сколько их есть, изобретать не надо. У меня тоже есть подобный велосипед, но для работы с БД, форматирования текста и рендеринга страниц я взял готовые библиотеки, и написалось оно сравнительно быстро, и голова меньше болит, и в итоге получилось прикрутить больше нужных функций - всякую подсветку синтаксиса, теги и прочее по мелочи. Всё как у людей. :3

Да брость ты, школоло, первый код, а ты тут со своими yii да SQLами. Или ты когда начинал ынтерпрайзными хелловорлды писал? Вырастет, почитает книжки, тогда и будет что нормальное, а щас такая ерунда - эт самое то.

сырцы-то выкладывай...

посмотрел... if{{{{{{{{{ расстраивает.

По теме, есть ведь такая штука как SQL, поверь, это намного проще, чем реализовывать свой велосипед из |палок| и прочего г-на. Кстати, вот тебе сцылка по-русски, чтоб не мучился: http://php.net/manual/ru/book.sqlite.php

Да брость ты, школоло, первый код, а ты тут со своими yii да SQLами.

веришь? он и сделал SQL самостоятельно. Только кривой и медленный.

Flat file database же. На самом деле мне бы такое усердие и аккуратность, чтобы каждую строчку комментировать и всё делать самостоятельно, это правда хорошо, но это не самодельный SQL даже близко.

Я не знаю, какой у автора бэкграунд, но предложил бы не справочник по sqlite, а что-нибудь попроще для начала, типа вот как Head First SQL. А потом уже всё остальное.

Так зачем каждую? Там много лишних комментариев, которые скорее замусоривают восприятия кода.

Flat file database же.

угу. Вот только в PHP имеются уже готовые костыли для sqlite(впрочем как и для других SQL), а вот для простого файла _всё_ нужно делать самостоятельно.

но это не самодельный SQL даже близко.

понятно, что это не SQL, но таки это СУБД. На лицо запросы в БД, и выдача ответов. Причём в ответе получаем выборку из таблицы сообщений, отсортированную по дате. Смысл изобретать свою СУБД, если имеется уже готовая?

а что-нибудь попроще для начала, типа вот как Head First SQL. А потом уже всё остальное.

на данном этапе ТС ИМХО нужно-то всего освоить синтаксис простейшего SELECT'а и простейшего INSERT'а. Вот и всё. ИМХО из 100 строк получится 10.

Ну как, комментируешь всё новое и незнакомое, если незнакомое и новое совсем всё, то получается, комментируешь каждую строчку.

Вот только в PHP имеются уже готовые костыли для sqlite(впрочем как и для других SQL), а вот для простого файла _всё_ нужно делать самостоятельно.

По-любому для yaml и json есть решения.

Смысл изобретать свою СУБД, если имеется уже готовая?

Чтобы быть благодарным авторам (Р)СУБД и ценить их труд же. :)

на данном этапе ТС ИМХО нужно-то всего освоить синтаксис простейшего SELECT'а и простейшего INSERT'а. Вот и всё. ИМХО из 100 строк получится 10

Книжка неспеша читается за неделю, а там даже есть такие полезные вещи, как простые JOIN'ы, самые простые сведения о проектировании и рекомендации, что делать, если не заложил сразу при проектировании лишний столбец. Это _использоваться_ будут два селекта и три инсерта, а _знать_ таки придётся немножко побольше (но немножко).

Чтобы быть благодарным авторам (Р)СУБД и ценить их труд же. :)

тогда надо писать на сишечке (возможно с плюсами), осилив предварительно Кнута с его деревьями.

Книжка неспеша читается за неделю, а там даже есть такие полезные вещи, как простые JOIN'ы

и зачем они в гостевой?

самые простые сведения о проектировании и рекомендации, что делать, если не заложил сразу при проектировании лишний столбец.

ТС это сам поймёт, как и то, что весь его код надо выкидывать на помойку, и писать заново ;)

Но не сейчас.

В гостевой - незачем, но туда же можно (и нужно) положить же все статьи!

1) Надо SQLite

Не установлена на хостинге

3) В конце концов, можно очень легко и просто подключить к вашему сайту disqus и не заморачиваться с хранением чужих личных данных

Disqus работает медленновато, мой вариант быстрее

4) Взяли бы какой-нибудь небольшой фреймворк, действительно.

Да, вариант. Только в фреймворке имеются дополнительные не выявленные уязвимости.

По теме, есть ведь такая штука как SQL

Про SQL знаю и использую с 2004 года.

Считаю, что для моей простейшей гостевой книги достаточно текстового файла. В случае большего количества полей и записей в базе однозначно сделал бы на основе реляционной СУБД MySQL.

В текстовом файле есть и свои плюсы: не подвержен SQL-инъекциям и падению СУБД при большом количестве одновременных INSERT'ов.

он и сделал SQL самостоятельно. Только кривой и медленный.

// Наибольшее допустимое количество строк, которые могут быть прочитаны из файла
$read_limit = 50;

В гостевой книге предусмотрено не более 50 записей, чтение из файла производится последовательно, строка за строкой, поэтому работает достаточно быстро.

Только в фреймворке имеются дополнительные не выявленные уязвимости.

Ну тогда не надо фреймворка, конечно.

простейшей гостевой книги

Та да. Только где они остались-то в наши дни и для чего они нужны? Комментарии в них писать неудобно, связываться лучше по почте.

Flat file database же. На самом деле мне бы такое усердие и аккуратность, чтобы каждую строчку комментировать и всё делать самостоятельно, это правда хорошо.

Спасибо за позитивную оценку моего усердия и аккуратности.

но это не самодельный SQL даже близко.

конечно же :)

на данном этапе ТС ИМХО нужно-то всего освоить синтаксис простейшего SELECT'а и простейшего INSERT'а. Вот и всё. ИМХО из 100 строк получится 10.

В основном согласен. При этом дополнительно придется добавлять код для защиты СУБД от SQL-инъекций и запросов, поступающих с высокой частотой.

В случае использования обычного текстового файла необходимость в написании данного дополнительного кода по защите СУБД отсутствует.

Ну как, комментируешь всё новое и незнакомое, если незнакомое и новое совсем всё, то получается, комментируешь каждую строчку.

Комментарии писал для более быстрого ознакомления посетителей ЛОРа с кодом.
Чтобы сэкономить ваше время, товарищи ;)

ТС это сам поймёт, как и то, что весь его код надо выкидывать на помойку, и писать заново ;)

Такого продвинутого уровня программирования, когда «весь код надо выкидывать помойку, и писать заново», пока не достиг ;)

Считаю, что для моей простейшей гостевой книги достаточно текстового файла.

достаточно. Действительно, вам в таком примитивном варианте достаточно сотни строк, что-бы превратить файл в БД. Однако, я-бы предпочёл 10 строк, а не 100.

В текстовом файле есть и свои плюсы: не подвержен SQL-инъекциям

Щаз! Подвержен. В данном случае достаточно вставить | в код, что-бы поломать ваш текстовый файл. Конечно, вы постоянно меняете во ВСЕХ полях | на html сущность, однако, разве-ли не является это типичной защитой от инъекций? Другое дело, что в php УЖЕ есть функции, которые экранируют спец-символы опасные для СУБД, а в вашем случае их нужно писать самостоятельно. Пока вам ещё удаётся использовать str_replace для защиты, но чуть усложнить, просто ввести скажем смайлы - и ВСЁ. Полезут preg_replace'ы, которые с лёгкостью убиваются utf-8 несимволами. Или которые ничерта не работают по-русски. Все эти проблемы (о которых вы несомненно и не слышали) давно и успешно решены в php, для любой известной СУБД, а для вашего файла вам это решать самостоятельно.

и падению СУБД при большом количестве одновременных INSERT'ов.

ага. У вас не упадёт. У вас просто убьётся ваша БД напрочь, если два клиента _одновременно_ туда что-то запишут. Многозадачность у вас не предусмотрена, блокировки не предусмотрены, средство создания бекапа не отключая сервер не предусмотрены, средства восстановления не предусмотрены. Ну я понимаю, ещё Over9000 строк - и всё будет ОК, но ЗАЧЕМ?

все в лучших традициях PHP :)

Из перечисленного «в лучших традициях» только последнее :) Остальное — общечеловеческие ценности^W^W как и всюду :)

блокировки не предусмотрены

В сорцы не заглядывал, но если так, то это самые первые грабли, на которые наступит автор :)

Такого продвинутого уровня программирования, когда «весь код надо выкидывать помойку, и писать заново», пока не достиг ;)

ту сотню ваших строк, что вы тут показали, можно смело переписывать с нуля ;)

В гостевой - незачем, но туда же можно (и нужно) положить же все статьи!

Поясню по истории развития моего сайта.

1) Изначально статьи хранились в MySQL и извлекались PHP скриптом для отдачи клиенту. У сайта была простейшая админка.

2) Потом решил сделать предварительную генерацию веб-страничек с сохранением в статичные файлы HTML, т.к. обновление имеющихся статей производил редко.

3) В последствии оставил статьи в обычных файлах HTML.

В сорцы не заглядывал, но если так, то это самые первые грабли, на которые наступит автор :)

ну я по диагонали просмотрел, не заметил никаких блокировок. ИМХО даже нагрузку «я и моя кошка» не выдержит :)

2) Потом решил сделать предварительную генерацию веб-страничек с сохранением в статичные файлы HTML, т.к. обновление имеющихся статей производил редко.

just for fun? Или действительно СУБД не справлялась? В статичных поиск не сделать нормальный.

только последнее

Ну да. Волею судьбы пришлось погрузиться в увлекательный мир PHP. Больше всего напрягает именно эта «традиция».

В данном случае достаточно вставить | в код, что-бы поломать ваш текстовый файл.

// Выполнить замену символа "|" кодом "|" в составе переменных $name, $mail, $message в связи с сохранением в файле
$name = str_replace( '|', '|', $name );
$mail = str_replace( '|', '|', $mail );
$message = str_replace( '|', '|', $message );

Все эти проблемы (о которых вы несомненно и не слышали) давно и успешно решены в php, для любой известной СУБД, а для вашего файла вам это решать самостоятельно.

Уважаемый «drBatty», убедительно прошу воздержаться от неплодотворных споров и придерживаться основной темы обсуждения. Жду ответа на вопросы изложенные в моем первом сообщении.

У вас просто убьётся ваша БД напрочь, если два клиента _одновременно_ туда что-то запишут.

Не согласен в данном вопросе.

// Подготовить файл списка сообщений к добавлению записи
$file = @fopen( $file_name, 'a' );

Если дескриптор handle был открыт функцией fopen() в режиме «записи в конец», то вызовы fwrite() будут атомарными (за исключением случая, если string размер блока файловой системы, на некоторых платформах, и пока файл хранится на локальной файловой системе). Т.е. нет необходимости блокировать ресурс с помощью flock() перед вызовом fwrite() - все данные будут записаны без прерываний.

Пруфлинк

Многозадачность у вас не предусмотрена.

Не до конца уяснил для себя, с какой целью требуется предусматривать многозадачность в обсуждаемой веб-программе?

Средство создания бекапа не отключая сервер не предусмотрены, средства восстановления не предусмотрены.

Администрированием сервера занимается хостинговая компания.

ту сотню ваших строк, что вы тут показали, можно смело переписывать с нуля ;)

Не вижу смысла продолжать обсуждение по данному вопросу

$name = str_replace( '|', '|', $name );

вообще-то это и есть «защита от SQL инъекций». Разница лишь в том, что в PHP уже есть такая защита для популярных СУБД, что позволяет обойтись без велосипедов. Опасностей тут две:

1. вы можете ввести новое поле, и забыть про защиту. Ну например капчу прикрутите. Уж поверьте мне, программисты постоянно забывают о том, что в поле, где имеют смысл только цифры, злоумышленник может ввести НЕ ТОЛЬКО цифры.

2. может изменится формат СУБД, может изменится кодировка, могут изменится настройки сервера. Это приведёт к необходимости изменения ваших велосипедов. ВСЕХ. Уверен - что-то вы забудете.

Впрочем - дело ваше.

Уважаемый «drBatty»

кавычки зачем?

Жду ответа на вопросы изложенные в моем первом сообщении.

Может ли потенциальный злоумышленник «украсть» текстовый файл, в котором хранятся сообщения посетителей с указанием e-mail'ов?

может конечно. Надейся на лучшее, рассчитывай на худшее. Хотя в таком простом коде ошибок я не наблюдаю. Вот только и пользы в нём нет никакой, без доработки. А любая фича - это потенциальная дыра, особенно если делать всё с нуля, как вы.

Если может, то как предотвратить такую утечку информации?

очевидно, следует максимально использовать чужие, проверенные наработки. Про SQL инъекции мы знаем очень много, про уязвимости Вашей СУБД мы не знаем ничего.

Возможно ли внедрить в сообщение теги, спецсимволы HTML наподобие ©, код JavaScript, либо PHP с целью отображения у остальных посетителей, исполнения на сервере? Если возможно, то как это предотвратить? Подразумевается возможность выполнения атак «Cross-site Scripting» (XSS) и «PHP Injection».

на данном этапе скорее всего нельзя. Но ведь вам захочется ввести хотя-бы смайлы, а может и ещё что-то. Во всяком случае, следует хотя-бы отказаться от замшелой вендовой 1251, в пользу UTF-8.

Какие, по вашему мнению, еще могут быть недочеты у гостевой книги в плане защищенности от «взлома», нарушения работы?

ну мне потребуется пару минут, что-бы забить вашу гостевуху чёрным властелином... На данном этапе вытащить список мыла будет проблематично, однако, у вас там всё равно 3.5 невалидных адреса, т.ч. ловить нечего. Когда будет 100500, то и дыры появятся...

(за исключением случая, если string размер блока файловой системы, на некоторых платформах, и пока файл хранится на локальной файловой системе)

файл хранится на локальной ФС, размер блока вам не известен. В моём Linux'е _гарантировано_ размер блока не менее 512байт. Могут-ли сообщения быть больше 512и байт? Могут. У вас до 1000. Что произойдёт, если одно сообщение вклинится в другое? Правильно - второе сообщение и все его поля(в т.ч. мыло) будут видны в первом, ибо читаете вы fgets'ом, до первого \n, а его и нет... А потом будет хвост, который интерпретируется как имя сл. юзера...

Не до конца уяснил для себя, с какой целью требуется предусматривать многозадачность в обсуждаемой веб-программе?

разве невозможен случай, когда второй юзер добавляет сообщение в момент добавления сообщения первым юзером?

Администрированием сервера занимается хостинговая компания.

вашей хостинговой компании абсолютно всё равно до файла, в котором хранятся все ваши данные. Если он испортится, копии его у вас НЕ будет.

Не вижу смысла продолжать обсуждение по данному вопросу

не надо обижаться. Вы просили критику, а не дифирамбы.

поиск уязвимостей

Вайп ниграми^Wпонями выдерживает?

Кажется, из почты теги не вырезаются.

Спасибо за развернутый, подробный ответ, drBatty!

вы можете ввести новое поле, и забыть про защиту.

Действительно, могу забыть. Лично мне приятнее осознавать, что вероятное вскрытие сайта произойдет в результате моей собственной ошибки, а не ошибки разработчиков MySQL.

Может ли потенциальный злоумышленник «украсть» текстовый файл, в котором хранятся сообщения посетителей с указанием e-mail'ов?
может конечно. Надейся на лучшее, рассчитывай на худшее.

Моя страница расположена на виртуальном хостинге, рядом с сайтами на основе Джумлы, Вордпресса, которые злоумышленнику проще вскрыть, а затем, например, перейти к взлому моего ресурса.

очевидно, следует максимально использовать чужие, проверенные наработки.

Ключевое слово проверенные. Вот интересная цитата Максима Чиркова, создателя ресурса Opennet.ru, по поводу использования чужих наработок, скриптов:

Аспекты безопасности при написании CGI-скриптов

Полностью исключить использование типовых бесплатных скриптов. Лучше все писать самостоятельно, если написание затруднено - обязателен полный аудит кода чужих скриптов.

Источник цитаты

Но ведь вам захочется ввести хотя-бы смайлы, а может и ещё что-то.

Честно говоря, вряд ли. Почему-то вспоминается нежелание руководства ЛОРа добавить смайлики к сообщениям. Думаю, это правильно.

файл хранится на локальной ФС, размер блока вам не известен. Что произойдёт, если одно сообщение вклинится в другое?

Надо будет проверить возможность такого вклинивания на практике путем создания одновременных запросов на запись в файл.

вашей хостинговой компании абсолютно всё равно до файла, в котором хранятся все ваши данные. Если он испортится, копии его у вас НЕ будет.

Делать резервную копию обычного текстового файла с сообщениями, на мой взгляд, проще, чем базы MySQL.

P.S. Для создания собственной домашней странички решил отказаться от использования _типовых бесплатных скриптов_, т.к. они сравнительно медленно работают, и содержат немало уязвимостей. Поэтому пишу динамическую часть сайта самостоятельно.

Кажется, из почты теги не вырезаются.

Совершенно верно. Вот строка из файла «messages.txt»:

User249|15 августа 2012, 21:50|Десятьбукв|<b>Ololo@trololo.com</b>|ip-адрес

Теги из почты не вырезал, т.к. название почтового ящика не выводится на веб-страницу, а просто хранится в текстовом файле.

Действительно, могу забыть. Лично мне приятнее осознавать, что вероятное вскрытие сайта произойдет в результате моей собственной ошибки, а не ошибки разработчиков MySQL.

неприятно будет, когда кто-то другой будет годами юзать вашу дыру, а вы об этом и не узнаете. С MySQL вероятность этого меньше (круг юзеров шире на 5 порядков минимум).

Моя страница расположена на виртуальном хостинге, рядом с сайтами на основе Джумлы, Вордпресса, которые злоумышленнику проще вскрыть, а затем, например, перейти к взлому моего ресурса.

ну и что? мы тут не рассматриваем дыры в вордпрессе.

Ключевое слово проверенные. Вот интересная цитата Максима Чиркова, создателя ресурса Opennet.ru, по поводу использования чужих наработок, скриптов:

Аспекты безопасности при написании CGI-скриптов

Полностью исключить использование типовых бесплатных скриптов. Лучше все писать самостоятельно, если написание затруднено - обязателен полный аудит кода чужих скриптов.

Ключевое слово - скрипты. Действительно, в скриптах «из гугла» часто полно эпичных дыр. Обычно это связано даже не с квалификацией авторов, а с тем, что очень часто автор просто иллюстрирует свою идею кодом, совершенно не озабочиваясь вопросами надёжности и безопасности. И это вполне нормально - зачем загромождать код ненужными деталями, которые и так очевидны. Как например мне очевидно, что писать @foo() можно только в примерах, в рабочем коде тут должна быть проверка на ошибку. Очевидно, что объём и сложность этих проверок часто больше, чем объём и сложность основного кода, ну и что? Php в этом смысле вообще очень опасный ЯП, если программа на C скорее всего тупо не соберётся, ну или рухнет в сегфолт, то программа на php будет даже работать. В тестах. На практике она тоже будет работать, вот только совсем не так, как вы задумали.

Совсем другая ситуация, если речь идёт не о скрипте, а о встроенной функции PHP. С большей долей вероятности можно утверждать, что защитные функции php будут защищать вас не только от сегодняшних, но и от _завтрашних_ атак, о которых вы даже не догадываетесь. Очевидно, ни ваши, ни тем более чужие скрипты от этого вас не уберегут.

Честно говоря, вряд ли. Почему-то вспоминается нежелание руководства ЛОРа добавить смайлики к сообщениям. Думаю, это правильно.

ЛОР тут не причём. И конкретно смайлы - тоже. К тому же, смайлы ЕМНИП были на 1ое апреля. Но что более важно, в контексте ЛОРа смайлы не нужны. Как например не нужны они в контексте UFO (они там есть, но отключены в моём профиле. Тут более удобно - отключать не нужно). Имелись ввиду разные другие полезные фичи. Откуда мне знать - какие.

Надо будет проверить возможность такого вклинивания на практике путем создания одновременных запросов на запись в файл.

Именно это я и называю «маздайный подход». ИЧСХ, в контексте маздая он даже работает - маздай везде одинаковый. Чего не скажешь про *NIX'ы. Можете не трудиться, скорее всего размер блока будет 65536 байт, причём скорее всего он будет только увеличиваться. Вот только надеяться на это === делать на отъ*бись. В стандарте сказано 512, значит 512. А на практике да, обычно получается 65536 байт. Тут ещё следует учесть, что 65536 оно в синтетических тестах. Что будет IRL я просто не знаю, могу лишь предполагать.

В любом случае, лично я предпочитаю переложить эти вопросы на создателей SQLite или другой СУБД, зачем мне лишняя головная боль? У меня есть интерфейс, и он работает одинаково и в Windows и в Linux, и в FreeBSD, зачем мне ломать голову?

Делать резервную копию обычного текстового файла с сообщениями, на мой взгляд, проще, чем базы MySQL.

это заблуждение. Проблема в том, что этот файл постоянно _меняется_. В MySQL имеются методы, которые учитывают это изменения, причём оптимальным способом для данной конкретной ОС и ФС, а у вашего велосипеда таких методов очевидно нет.

Для создания собственной домашней странички решил отказаться от использования _типовых бесплатных скриптов_, т.к. они сравнительно медленно работают, и содержат немало уязвимостей. Поэтому пишу динамическую часть сайта самостоятельно.

если вы внимательно прочитаете мои посты, то увидите, что я и не призывал к использованию чужих _скриптов_. Что касается скорости, дык если вы возьмёте скрипт, который на 100% удовлетворяет ваши запросы, то 90% из его функционала будет вам не нужна. Что очевидно. ИМХО действительно, проще самому написать 10%, чем тащить 90% ненужного мусора.

В своем последнем сообщении вы, в основном, пересказываете очевидные вещи, которые понятны всем посетителям и без разъяснений.

а просто хранится в текстовом файле.

Полезное применение.

Полезное применение.

Полезное применение заключается в возможности установить обратную связь с автором поста.