BTW:
Ажно с августа :)
И еще:
Блин, давайте ему на хостинг скинемся, свой человек же, интернетчег! :)
Буф дело говорит :)
Кстати,
el_aspect, в вебе в большинстве случаев "дыра" заключается в недостаточной обработке данных, пришедших от пользователя. Наиболее распространенные варианты описаны тута. На мой взгляд, реальную опасность представляют:
- SQL инъекция: данные копируются в SQL-запрос без обработки, злоумышленник может выполнить произвольный запрос
- XSS: в форму комментария вставляют, например, JS-код, отправляющий куку SESSID на мыло злоумышленника, так можно заполучить доступ к админскому аккаунту
Как реализовать защиту - есть много вариантов. Внимательно следите за теми частями кода, где данные извлекаются из $_REQUEST/$_SESSION, постарайтесь написать набор методов для обработки данных пользователя, и, по возможности, вызывать их автоматически/неявно.
От остальных видов уязвимостей, описанных в Wiki, вполне можно застраховаться, не используя некоторый функционал (не использовать eval(), не вызывать внешние программы через exec(), не подключать файлы динамически и т.д. - без всего этого вполне можно жить).
Если отклониться от сабжа, могу дать такой совет: думайте в первую очередь не о безопасности системы, а о ее гибкости, расширяемости и удобстве использования. Если у Вас есть хороший, логичный код, будет не слишком сложно модифицировать его, чтоб он стал защищенным. Рассматривайте защиту как частный случай модификации, и просто делайте легкий в поддержке код.
Кроме того, перед началом использования системы, дайте исходные коды на ревизию нескольким толковым разработчикам. Чтоб найти большую часть потенциальных уязвимостей, достаточно внимательно прочитать код.
Во-первых, это чревато получением штрафа по ст. 4.9 (Вы, понятное дело, ни к чему не призываете, но провоцируете на нарушение того, кто Вам скажет "ничего не будет, юзай ломаный"). Надеюсь до того не дойдет, пока - устное внушение.
Во-вторых, конкретно про Битрикс ничего сказать не могу, но в целом у крякнутого софта проблемы с поддержкой (можете остаться без обновлений, в т.ч. фиксов уязвимостей), кроме того, были случаи встраивания бэкдоров и шеллов в крякнутый софт, поищите. Т.е. в один прекрасный день Вы можете остаться без данных, без сервера, или, например, без сайта в индексе ПС.
В-третьих, вообще не уверен, что Битрикс Вам подойдет. На мой взгляд, система дорогая не только в плане лицензии, но и в плане внедрения и поддержки. Хорошие специалисты по Битриксу обойдутся дорого (если таковые вообще согласятся работать), а задешево Вам сделают фигню (учитывая специфику Битрикса, "фигню" на нем сделать гораздо проще, чем на многих других системах - ну да ладно, это мое ИМХО, не люблю я его).
Если подытожить. Использовать крякнутый - категорически не рекомендую. Либо закладывайте бюджет на лицензию + внедрение + поддержку, либо посмотрите на более дешевые или бесплатные варианты.
jobex, в .htaccess можно прописать, чтоб при запросе урла /param-1.htm сервер обрабатывал его как /index.php?param=1 - ищите по слову mod_rewrite. А вот чтоб все ссылки на сайте имели правильный вид - придется делать вручную.
Советую пользоваться базой данных :)
В 99% случаев нет никаких причин от нее отказываться.
Дык ребята с пафосом зарядили UTF :) Правда, например, превьюшки для новостей стругаются обычным substr, для английского языка это не проблема, а на других им тестить лениво было, видимо )
Ввиду того, что ТС, вместо опубликования своего творчества, решил отстаивать честь (с нарушением п.4.13 правил форума), считаю дальнейшее обсуждение бессмысленным и закрываю тему.
А в спецуху глянуть религия не позволяет? :)
http://www.w3.org/TR/CSS2/visudet.html#min-max-widths
Кстати говоря, rel=nofollow вполне соответствует стандарту
$text=preg_replace("/{(\d*)\:(\d*)\:(\d*)}/", "my_code", $text);
2. Ваш вариант найдет и подстроку типа {::} - не совсем то.
Я бы предложил скорее так:
$text=preg_replace("/{\d+:\d+:\d+}/", "my_code", $text);
