Форум PHP

Возможно вопрос мой слишком пространный, обширный, но прошу всех, кто пробовал создавать CMS (content managment system) поделиться опытом, как мне избежать ошибок, полезные приемы.
Хотелось бы, чтобы можно его изменять легко, чтобы он не был сложным...

> как мне избежать ошибок, полезные приемы.
Набирайтесь бесценного опыта, читайте книги, Посмотрите коды уже реализованных вариантов... А вообще вопрос слишком широкий, У создателей этого форума есть рукописный труд под названием "PHP5 Правктика создания Веб-сайтов" - для начала самое то....

CMS - это не стандартное приложение и может принимать самые разнообразные формы, в первую очередь вы должны сами себе ответить, что вы от него ожидаете?

Для этого цмс нужно:
Страницы целиком должны лежать в базе отформатированными в html в базе данных + название + ключевые слова;
Независимые стили оформления;
Возможность создания блоков (вертикальных и горизонтальных) и размещение их в любом месте на сайте и страницах.
+Возможность добавления модулей.

Все существующие CMS не подходят по этим параметрам. :(

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

Самый главный вопрос, который меня интересует - как сделать CMS - который нельзя взломать: украсть пароли, стереть базу и файлы с хостинга, заменить содержимое. Вопрос безопасности!
Я правильно понимаю что взлом можно осуществить ТОЛЬКО через ФОРМЫ и адресную строку?

"CMS - который нельзя взломать" такую сделать нельзя ... просто старайтесь проверять все что юзер вам отправляет, храните пароли в закрытом виде и т.п.

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

сломать можно все
Вы судите по своему горькому опыту что ли?

если топор считать ресурсом - тогда, конечно.

> как сделать CMS - который нельзя взломать
Никак.
> Я правильно понимаю?
Нет, не правильно)

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

Дело может быть и не в самой гостевой... вот, например, залить тебе шелл и непробиваемая гостевая тут уже не поможет :)

если гостевая позволяет залить через нее шелл разве что администратору сервера - это непробиваемая гостевая.
Иначе в рассматриваемом контексте шелл от топора мало чем отличается.

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

>Я лишь хотел указать на то, что если нет дыр в гостевой, то с сайтом не обязательно все будет хорошо.

И какие методы решения указанной Вами проблемы Вы предлагаете?

Я слышал про SQL инъекции - как от них защититься?

Не допускать формирования операторов SQL-кода непосредственно из входных параметров скрипта.
Корректно формировать литеральные константы. (mysql_escape_string())
Передавать соответствующие числовые параметры через приведение к числовому типу.($id_int = intval($id_str))
Опять же см. задачи 11 и 21 одноименного раздела
http://softtime.ru/forum/read.php?id_forum=7&id_theme=14039
http://softtime.ru/forum/read.php?id_forum=7&id_theme=37909

"Залить шел" это запустить скрипт? Если да, то как от этого можно подстраховаться?

Тщательно контролировать файлы, которые загружает пользователь на сервер, лучше в директорию в такими файлами поместить конфигурационный файл .htaccess следующего содержания

RemoveHandler .php .phtml .pl AddType text/html .php .phtm .htm .html .phtml .pl

Файлы, которые загружает пользователь на сервер, ни при каких обстоятельствах не должны быть видны через apache извне, поскольку это позволит атаки через SSI и XSS.
Так что AddType text/html .php .phtm .htm .html .phtml .pl здесь, на мой взгляд, неуместна.

RemoveHandler .php .phtml .pl  order deny,allow  deny from all

(2-я стока нужна, если ниже следует список администрирующих хостов, откуда доступ все же разрешен. Если таких нет - строку order можно убрать)
А кроме того надо не забыть закрыть доступ к самому .htaccess, запретив запись в него. chmod 444

>Файлы, которые загружает пользователь на сервер, ни при каких обстоятельствах не должны
>быть видны через apache
Аттачи на форуме запретить? :))) Файлы не для того загружаются, чтобы их никто не видел.

Игорь, можно подумать, Вы на форуме выдаете аттачи с заголовком Content-Type: text/html
Ну ведь нет же?

Для файлов .php .phtm .phtml, если де случайно окажутся в директории files не Content-Type: application/x-httpd-php же выдавать :)))?

нет, конечно.

application/octet-stream
application/force-download
text/plain на худой конец (худой - потому как старый ie их всё еще html-рендерит)

Да, надо на text/plain заменить - всё-таки информация для просмотра.

а каким же должен быть файл .htaccess
?

RemoveHandler .php .phtml .pl  AddType text/plain .php .phtm .htm .html .phtml .pl