Леонид Каганов: дневник

Называется binoniq.net Пока накатил туда нынешний движок, но вскоре начну строить многопользовательский для раздачи аккаунтов.
Вопрос пока что такой.
Задача: пользователю надо разрешить вводить html. В заметках (да и в комментариях неплохо бы тоже), в темплейтах, а также редактировать *.css (дизайн свой делать). При этом необходимо из пользовательского html удалять все вредоносные элементы, способные запустить или подгрузить скрипты. Собственно, <script...>, <object...>, <style...>, <iframe...>, <a onclick=...> и прочее. И еще есть какие-то свои уязвимости для файлов *.css. Но весь «не опасный» html надо оставить. Задача видится ебанической, но сделать ее необходимо, другого пути нет. Пусть лохи сосут свои bb-коды, а нам нужно дать пользователю полноценный инструмент дизайна.
Я конечно со своей стороны постараюсь что-нибудь намудрить с авторизацией, чтобы красть куки или делать операции помимо воли пользователя было не так просто. Но html нужен.
Вопрос: нет ли у кого готовой процедуры на php? Или идей и знаний в этой области?
<< предыдущая заметка
следующая заметка >>
пожаловаться на эту публикацию администрации портала
архив понравившихся мне ссылок
Оставить комментарий
2010-11-13 05:06
Linux Safari Chrome
whois
0
0
 vvzvlad
а что означает имя?
2010-11-13 05:34
Nokia-E90 Safari
 Москва
2
0
 Леонит Каганофф
Оно означает вот этот проект. Не брать же для нового проекта поношенное имя в словарном сэконд-хэнде?
2010-11-13 05:43
Windows Safari Chrome
whois
6
1
 alexeybobkov
Название что-то уж очень похоже на этот безумный "бинардик" (который ещё "дешкомпьютер")
2010-11-22 11:55
Windows Firefox
whois
0
0
 dimmik
Убик?
2010-11-13 06:09
Linux Windows Firefox
whois
0
0
 oreolek
Чтобы движок не ругался, выделяю теги не угловыми скобками, а воображаемыми.
Есть библиотека HTMLPurifier: http://htmlpurifier.org/
Слышал, что в Опере можно через атрибут style превратить любой b в iframe, но подтвердить не удалось.
Я когда-то выкорчёвывал из одного ооочень бажного блогодвижка на Perl "фильтрацию" HTML (на самом деле, там было всего лишь название; любой iframe спокойно проходил в комментах), так проще только оставить десятку разрешённых тегов, а все остальные - под снос (например, так делает LiveJournal). И запретить любые атрибуты, кроме href и title, а потом фильтровать их на javascript.
2010-11-13 15:02
Linux Firefox
 Москва
0
0
 LLeo
Спасибо за ссылку!

К сожалению, выделить список "разрешенных" тэгов нельзя, поскольку речь не о пользовательских комментариях, а о работе владельца аккаунта над своими заметками и дизайном своего раздела. Но при этом он не должен представлять угрозу для остальных.
2010-11-13 15:31
Windows Firefox
whois
0
0
 Сергей Яковлев
Посмотри функцию preg_replace. Когда требуется повырезать некоторые теги, я делаю так:

preg_replace(array('/&lt;[^&gt;]*&gt;/', '/&nbsp;/', '/"/'), array('', ' ', '&quot;')

По такому же принципу можно вырезать не все теги в угловых скобках, а только ненужные.

Update: &lt; и &gt; надо заменить на угловые скобки, блог не разрешил их использовать напрямую.
2010-11-13 16:35
Linux Firefox
whois
0
0
 LLeo
Вопрос не в том, чтоб вырезать тэги, а в том, чтобы удалить уязвимости. Уязвимость в виде отдельного тэга - это лишь самый примитивный случай.
2010-11-14 04:28
whois
1
0
 {name}
Тогда уж проще strip_tags() задействовать. Но Ллео это не подойдёт, нужно ведь ещё и некоторые атрибуты отфильтровать. А для style -- выбрасывать не полностью, а смотреть внутрь и вырезать только некоторые свойства css.
2010-11-13 06:16
Windows Opera
whois
0
0
 Wot
Берем WordPress и смотрим в wp-includes/kses.php
2010-11-13 15:05
Linux Firefox
 Москва
0
0
 LLeo
Вордпресс не производит впечатления вдумчиво спроектированной системы. Вы уверены, что там по-настоящему профессиональные процедуры чистки html?
2010-11-18 16:48
Mac Safari
whois
1
0
 Dmitrii 'Mamut' Dimandt
Вне зависимости от впечатлений, инсталляций Wordpress'а — миллионы, и ломать их наверняка пытаются и через комменты/контент тоже. 

Пренебрегать их опытом по фильтрации контента только потому что что-то кажется, как минимум, глупо.

«Настоящих профессиональных процедур чистки html» в мире не существует. Тем более, что совет посмотреть на решение Wordpress'а полностью соответствует заданному вопросу: «нет ли у кого готовой процедуры на php? Или идей и знаний в этой области?»
2010-11-18 17:42
Linux Firefox
 Москва
0
0
 LLeo
Думаю, вы правы.
2010-11-13 10:56
whois
1
0
 {name}
Несимметрично как-то. Лучше бы biuoniq или binouiq.
2010-11-13 15:04
Linux Firefox
 Москва
1
0
 LLeo
Поучите деда кашлять.
2010-11-14 04:21
whois
0
0
 {name}
Кхе-кхе-кхе.
2010-11-13 11:12
whois
1
0
 {name}
А посмотрите-ка код Livejournal. Там наконец-то научились резать правильные вещи. Неплохо бы результат пропускать через tidy.

В любом случае хотелось бы два режима ввода текста -- в готовом html и в чём-то вроде markdown. Обычно разные подвыверты с html не нужны (особенно в комментариях), а вот ненапряжно выделить текст (как в *фидо*), разбить на абзацы (пустая строка, как мы обычно делаем в письмах), перечислить пункты списка (* в начале строки), не вводя тучи тегов -- очень желанно. Не говоря уже о возможности ввести меньше/больше без уродских &lt;/&gt;. Ну вот что мешает вам сейчас, когда никакого html нет, разрешить символы меньше/больше?
2010-11-13 13:41
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Речь не о комментариях сейчас.
2010-11-13 14:24
whois
0
0
 {name}
(да и в комментариях неплохо бы тоже)

А что, авторы заметок не люди? Им тоже удобства хочется.
2010-11-13 15:03
Linux Firefox
 Москва
0
0
 LLeo
Многие авторы комментариев - пустые пиздоболы. Не нужны им дополнительные сервисы.
2010-11-15 13:49
whois
0
0
 {name}
Да, процитировать пример кода, чтобы показать как можно сделать или указать на ошибку -- самое пустое пиздобольство. Это вам не фото своего пальца вставить.
2010-11-13 15:01
Windows Safari Chrome
whois
0
0
 antarx
Леонид, технически, Вам достаточно отфильтровывать порядка 10 ключевых слов, типа script, iframe, onclick, onmouseover итп. Более того, можно даже не удалять, а просто заменять на &# коды (скажем, банальные 10 preg_match'ей). Таблицу перевода можно взять, например, здесь:
http://www.december.com/html/spec/codes.html
Мне кажется, от скриптов должно гарантированно избавить (при сохранении адекватного внешнего вида), и решение будет довольно быстрым.

Есть совершенно другая проблема: посредством position: absolute (или fixed/relative) можно подменить поля ввода логина-пароля и прочий такого рода интерфейс (например, подменить навигацию и ссылаться на свой сервер с похожим внешним видом). В принципе, можно так же фильтровать слово position, но это не слишком гуманно.
2010-11-13 15:12
Linux Firefox
 Москва
0
0
 LLeo
Так кажется только на первый взгляд. На самом деле список уязвимостей гораздо шире, там и всякие типа img src='DATA:BASE64:a45FzdZg235sf353==' и проч.

Что касается подмены полей логина-пароля - мне кажется (поправьте, если я ошибаюсь), что такой проблемы у нашем движке не будет, поскольку один из его базовых принципов - мегадинамичность страниц. Это значит, что все элементы интерфейса (и поля ввода логина, разумеется) не содержатся в статическом коде у клиента, а появляются по командам от сервера во всплывающих окнах.
2010-11-13 15:20
Windows Safari Chrome
whois
0
1
 antarx
Проблемы стоит решать по мере их поступления. Такого рода фильтр достаточно надёжно и быстро делает необрабатываемыми все кажущиеся лишними вещи (список которых легко пополнить).

В данном случае не очень понятна проблема, поскольку нормальным браузерам не важно, какие картинки скармливать (да и запрещать внешние изображения не слишком правильно), а IE6-7 всё равно не понимают DATA как изображение.

Что же касается подмены, можно подменить навигацию (например, кнопки "предыдущая/следующая заметка"), отправляя на свой сервер, где уже можно без особых трудностей вытянуть у пользователя логин-пароль.
2010-11-13 16:33
Linux Firefox
whois
0
0
 LLeo
Некоторые проблемы решать "по мере поступления" поздно. Если у тебя база 1000 пользователей, и в один день их авторизация уплыла на сторону... Нет уж, я лучше запущу сервис на полгода позже, чем решать такие проблемы на ходу ;)

Проблема с кнопками "предыдущая" не кажется мне важной. Обосновать пока не могу, но думаю, что это работать на практике не будет.
2010-11-13 15:31
Windows Safari Chrome
whois
0
0
 antarx
Вообще, я не совсем понимаю, зачем нужно фильтровать &lt;style, поскольку там в реальности наблюдается только 2 проблемы: перекрытие css не принадлежащих пользователю данных, и подгрузка .htc файликов (которые, к слову, начала поддерживать Firefox посредством moz-behavior). Это фильтровать сложнее, но в принципе тоже реально (кроме того, не факт, что нужно серьёзно этим заморачиваться, поскольку тот же жж задавать стиль журнала посредством своего css, а сопутствующих проблем лично я не помню).

PS Да, само собой, в корневом сообщении имелось ввиду preg_replace. Кроме того, метод хорош тем, что можно не различать теги и не теги, что значительно ускоряет работу и избавляет от хитрых методов обхода.
2010-11-13 16:37
Linux Firefox
whois
0
0
 LLeo
Насколько я знаю, в css позволяется запускать некоторые скриптовые выражения и даже подгружать файлы js.
2010-11-13 17:05
Windows Safari Chrome
whois
0
0
 antarx
Насколько я знаю, скрипты в css можно подгружать только в виде .htc файлов посредством behavior, moz-behavior и ms-behavior. Соответственно, фильтр слова behavior должен спасти.

Что касается кнопки "предыдущая" - подойдёт любая нескриптовая навигация. Безусловно, проблема не самая важная, но посредством этого действительно можно перенаправить пользователя на свой сервер (работать оно должно, просто расходы на реализацию клона заметно выше). Как надёжная альтернатива - можно заменить все ссылки наружу на страничку с фразой "это ссылка наружу, уверены ли Вы, что хотите этого...", как это делает, например, вконтакте:
vkontakte.ru/away.php?to=http://lleo.aha.ru/

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

PS Леонид, ко мне перестали приходить уведомления о Ваших ответных комментариях, несмотря на настройки профиля (комментарии - присылать). Что делать?
PPS Как-то злобно пересылать всех, кто указал в комментарии на "сайт символического направления", на этот сайт, без публикации сообщения.
2010-11-14 00:08
Windows Firefox
whois
1
0
 zencd
Функция strip_tags выкусывает неправильные теги:

http://php.net/manual/en/function.strip-tags.php

Требует список разрешённых тегов, а не наоборот. Но оно и правильно - нормальных пацанских тегов раз два и обчёлся.
2010-11-14 00:12
Windows Firefox
whois
0
0
 zencd
Ещё неплохо бы вырезать некоторые (или все) "on"-аттрибуты:

[img onload="javascript: ..."]
2010-11-14 01:05
Linux Firefox
 Москва
0
0
 LLeo
Ага. И еще неплохо бы устранить остальные 140 уязвимостей. А так ничо.
2010-11-15 11:38
Windows Safari Chrome
whois
0
0
 antarx
Леонид, если не секрет, откуда Вы взяли число "140 уязвимостей"?
2010-11-15 11:55
Linux Firefox
 Москва
0
0
 LLeo
Ну, есть справочник XSS, там что-то около того. Ссылку сейчас не вспомню.
2010-11-15 12:59
Windows Safari Chrome
whois
0
0
 antarx
Погуглил, немного потестил. Проверил ещё раз, что большинство уязвимостей на текущий момент (ie7+, последние версии прочих десктопных браузеров) не работают. В частности, любые символы внутри слов типа script, замена части кода на &# символы и прочие методы пряток от регулярных выражений приводят к неработоспособности кода.

Так что, с учётом неработоспособности движка в ie6, и безумной редкости старых версий прочих браузеров, указанного в моём посте фильтра должно быть достаточно (хотя, наверное, стоит дополнительно потестить мобильные браузеры).

PS Пишут про альтернативы вида обработать входящие данные как xml, и обрезать всё подозрительное:
http://habrahabr.ru/blogs/webdev/70795/
тут обилие готовых решений.
2010-11-15 13:03
Linux Firefox
 Москва
0
0
 LLeo
"я потестил, большинство уязвимостей не работают" - очень смешная фраза.

Достаточно одной.
2010-11-15 13:15
Windows Safari Chrome
whois
0
0
 antarx
На самом деле, я просто взял:
http://ha.ckers.org/xss.html
и протестил основные. Прошло (из нефильтруемого сразу) только moz-binding (который deprecated в 4-ке) и AllowScriptAccess в embed. Также, из красивого и неизвестного для меня - вставки SSI инструкций. (в Вашем случае, я полагаю, добавляются Ваши внутренние {__} инструкции движка, которыми можно что-нибудь скрыть)

Впрочем, возможно, в ie7 таки часть уязвимостей работает, поскольку эмуляция ie7 в ie8 неполноценна.

Безусловно, достаточно одной уязвимости, и именно поэтому нужны подробные тесты.
2010-11-15 14:10
Linux Firefox
 Москва
0
0
 LLeo
Еще раз. Какой смысл в выражении "основные уязвимости"? Значит, для взлома используют неосновную.

Вообще я не очень понимаю, о чем говорить с человеком, который взял официальный список существующих уязвимостей, "протестировал" их (зачем?! уличить авторов во лжи?!) и "выяснил", что в ЕГО БРАУЗЕРЕ сработали из них не все. И теперь рассуждает в духе "ничего особо страшного, основные не работают".

Вот скажите, как дальше беседовать с таким человеком о проблемах безопасности? Я объясняю это только спецификой Виндоус-пользователя, который настолько органично привыкает к мысли о первородной уязвимости своей системы, что начинает делить опасности на "основные" и "маловероятные".
2010-11-15 15:04
Windows Safari Chrome
whois
0
0
 antarx
Не совсем. Речь о том, что уязвимости делятся на типы, и из одного типа можно тестировать только одну уязвимость. Кроме того, часть уязвимостей легко фильтруются указанным методом, или не являются уязвимостями в общем смысле. С учётом этого протестированы все уязвимости.

Что касается "моего браузера", я просто взял все установленные у себя (Firefox, Opera, IE8, IE8 как IE7, Safari, Chrome) и целенаправленно проверил, как там ведут себя те или иные "уязвимости". Если исключить нердов с доисторическим не-IE (которые ССЗБ, и которых исключительно мало), пользователей IE6 (и мб IE7), и пользователей мобильных браузеров, этой проверки достаточно.

Так что суть не в разделение вероятных-невероятных уязвимостей, а в разумном ускорении тестирования.
2010-11-14 14:33
Linux Opera
whois
0
0
 Алексей
Да просто все...
Я вот хотел сюда код написать, а мне движок отвечает, что html - нельзя.
Не умно. Напишу сейчас на мейл.
2010-11-15 01:39
Linux Safari Chrome
whois
1
1
 Сергей
Для фильтрации тегов идеальное решение - XSLT. Можно настроить какие теги выводить, какие нет. То же самое и с атрибутами. Какие атрибуты выводить, какие нет, для какого тега. Можно действовать в зависимости от содержимого тега/атрибута (например &lt;a href="javascript:..." банить а &lt;a href="http://javascript.ru" пропускать). Можно заменять одни теги другими (например &lt;quot&gt; на &lt;blockquote&gt;)
Еще плюс - гарантированно не получите битую разметку (незакрытые теги и т.п.). Единственный минус - придется все же изучить XSLT, но думаю не пожалеете потом.
2010-11-15 01:50
Nokia-E90 Safari
 Москва
0
4
 Леонит Каганофф
Я не знаю, что это такое. Но если это "надо изучить" - то это точно не для меня. Мне проще написать самому, чем что-то изучить.
2010-11-15 11:27
Windows Safari Chrome
whois
1
0
 antarx
Вы всерьёз считаете, что получите от злоумышленника корректный xml документ (без которого xslt ведёт себя несколько странно, да и браузеры довольно либеральны к некорректному коду)? И что сможете учесть все нюансы типа behavior в стилях?

Зачем забивать гвозди гвоздодёром? XSLT - прекрасный метод шаблонизации заведомо корректных данных, за то и ценим.
2010-11-17 00:57
Linux Safari Chrome
whois
0
0
 Сергей
Некорректный XML можно править если на сервере то TIDY если на клиенте - то загружать HTML в DOM объект и на него натравливать XSLT. При загрузке не совсем валидного HTML браузер умеет его выправлять
2010-11-15 13:56
whois
0
0
 {name}
Во-первых, html -- не xml. Во-вторых, писать ли xslt для всех случаев, иди правила для специального инструмента -- то на то выходит, только второе может быть удобнее. В-третих, некоторые атрибуты (вроде style) нельзя выбрасывать целиком, придётся вручную парсить, учитывая внутренний синтаксис.
2010-11-15 14:04
Windows Firefox
whois
0
0
 Иван
Лео, скажи, а фразы типа "мне было явление ангела",
"биноник это 10е100 гулов" и "птица, которая заставляет вить своё гнездо насекомых" -- оно выдается в зависимости от айпишника?
Хотелось бы посмотреть весь список ;)
2010-11-15 14:12
Linux Firefox
 Москва
0
0
 LLeo
Меняйте IP :)
2010-11-15 18:26
Windows Firefox
whois
1
0
 Иван
Ой, а откуда у меня там форма регистрации выпала?
Впрочем я решил сперва зарегистриться... но тем не менее вопрос -- это оно так и надо?


2010-11-16 17:30
Mac Safari
whois
0
0
 kukutz
Я делал такую библиотеку, даже в PEAR её запостил.

http://pear.php.net/package/HTML_Safe

Большинство комментариев выше от совершенных, извините, ламеров.
2010-11-17 20:21
Linux Firefox
 Москва
0
0
 LLeo
Вау! Спасибо, буду изучать.

А что там за require_once 'XML/HTMLSax3.php'; ?
Шо это и зачем?! Можно без него?
2010-11-18 09:29
Windows Safari Chrome
whois
0
0
 antarx
Самоочевидно, он явно используется для парсинга кода - без него нельзя. Оттуда есть ссылка:
http://pear.php.net/package/XML_HTMLSax3/
В портах фряхи лежит htmlsax2, так что придётся скачивать. htmlsax нужен для работы с говном на входе как с более-менее валидным xml, ну и даёт определённый api.

SafeHTML - штука довольно старая и известная, и позиционируется как универсальное решение, таковым не являясь. В частности, (по меньшей мере по умолчанию) вставлять видео из всяческих ютубов не получится, и уязвимости, связанные с серверным кодом, попросту игнорируются (в частности, SSI, или же команды Вашего движка, могут достаточно надёжно скрыть все страшные теги и параметры от парсера). Также радует некий пофигизм в отношении position: relative, который при определённой сноровке не хуже absolute, ну и прочие мелочи.

На реальном проекте приходилось использовать safehtml, но из-за неудобной работы оказалось проще (и заметно быстрее по скорости исполнения) переписать его заново, с блекджеком и шлюхами со своими регэкспами и с использованием tidy. При недавнем анализе порадовало, что если так или иначе выкинуть пользователей IE6, количество кода для фильтрации можно уменьшить на порядок, о чём по сути и были мои предыдущие посты.
2010-11-18 16:36
Linux Firefox
 Москва
0
1
 LLeo
Спасибо за разъяснения.

Мне вообще не нравится идея изучать какие-то пакеты, фреймфорки и проч. Пока из того, что я видел, наиболее удобным кажется модуль от Вордпресса (хотя я о нем поначалу, не глядя, высказался негативно - и ошибался). Там одна страничка php, без всяких фреймфорков и парсеров из портов, с достаточно понятной и складной логикой работы.
2010-11-18 17:08
Windows Safari Chrome
whois
0
0
 antarx
Погодите. Если Вы о ссылке из комментариев, то:
Во-первых, kses не имеет отношения к WordPress'у, и живёт здесь: http://sourceforge.net/projects/kses/
Во-вторых, как раз тот факт, что он не использует внешние парсеры (в идеале даже не на php, например, tidy) как минимум настораживает.
В-третьих, внешний анализ кода подсказывает, что kses игнорирует стили, что уже нехорошо, да и просто не расширяем.
В-четвёртых, требуется полное описание разрешённых тегов с атрибутами, что в рамках html5 довольно муторно.

В сравнении с kses HTML_safe - идеальная вещь, вида "вписал 5 строчек и всё работает как надо".

Повторю, лучше писать работать с кодом самостоятельно - это и быстрее, и надёжнее, при грамотном подходе и отказе от поддержки IE6.
2010-11-18 17:37
Linux Firefox
 Москва
0
0
 LLeo
Я все равно, видимо, буду писать самостоятельно - мне это проще, чем понять, как работает чужой код, как установить к нему кучу каких-то левых парсеров, библиотек и пакетов, и на каких основаниях всю эту кучу потом можно включать в свой движок, чтобы не возникало авторских претензий.

Я понял для себя такие вещи:

1. Не существует никакого CODE.php из 1 файла, которому можно на вход подать текст, а получить текст гарантированно очищенный. Поэтому буду писать сам.

2. Мне не надо запрещать вредные тэги - лучше разрешить дозволенные по списку, который потом можно расширять. Список тэгов, которыми пользуется человек при написании заметки и комментария, обычно крайне ограничен. В дизайне тоже используется в основном DIV и TABLE.

3. Мне не надо возиться со стилями - в комментариях это только вредно, а в заметках пусть владельцы аккаунтов работают с классами, редактируя свои css. А уж css я почищу от уязвимостей отдельно.

Я прав?
2010-11-19 11:35
Windows Safari Chrome
whois
2
0
 antarx
В целом, всё верно - универсальных средств решения нет, подход белым списком убог, а комментарии должны быть весьма ограничены.

Однако, по опыту, если исходить из реальной потребности конечных пользователей, требуется:
для постов:
1. Возможность вставлять всяческие видеоролики и прочие флеш-игры - это iframe'ы, embed'ы и прочее.
2. Возможность подключения настроенного полноценного wysiwyg редактора, со спеллчекером и прочими наворотами.
3. Остальное у Вас есть.
для комментариев:
4. Обрезанный wysiwyg редактор, хотя бы как вконтакте - небольшой тюнинг шрифтов, ссылки и прочее насущное.

1 важно по самоочевидным причинам, причём здесь не помогут модули движка.
Без 2 реальные пользователи, видевшие только Ворд и вконтакте, не справятся с форматированием. Да и просто на практике эти редакторы в разы ускоряют форматирование.
4. Тут можно взять какой-нибудь действительно маленький редактор, да и можно написать самому при желании.

1 означает, что лучше не резать iframe'ы и прочий флеш. Соответственно, желательно во избежание проблем сделать динамические домены для зарегистрированных пользователей, с куками в них.
2 - практически все wysiwyg редакторы генерят style в свойствах, и никуда от этого не деться. Да и просто банальные теги u и s на текущий момент deprecated. Так что от style лучше не отказываться.
3 - тут важно грамотно проверять входящий код с учётом ваших модулей и возможного SSI-кода.
4 - такие редакторы обычно пишутся довольно просто, и должны работать везде.

PS Это взгляд со стороны пользователя - со стороной разработчика у Вас трудностей не должно быть. Написанное здесь - скорее пожелание об идеальном сервисе.
2010-11-27 13:42
Mac Safari Chrome
whois
0
0
 goodkat
имхо, зря
создавшие фрэймворки люди уже наступили на большинство граблей, избавились от большинства багов и уязвимостей
вы создаёте сложную модульную систему, и через какое-то время у вас будет тьма разных функций, в которых довольно трудно будет разобраться кому-нибудь кроме вас - это к тому, что вы не хотите использовать ООП

я бы порекомендовал фрэймворк от создателей PHP - Zend Framework, это не готовая CMS, это обширная библиотека классов для всего на свете, которые можно использовать и по отдельности, но ZF предлагает довольно удобную (если в ней разобраться) архитектуру для построения веб-приложения (сайта)
2010-11-27 18:10
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Опять это нытье о том, что все в мире давно уже есть и ничего делать не надо... Вам не надоело?
2010-11-27 18:58
Mac Safari Chrome
whois
0
0
 goodkat
где здесь нытьё-то?
в Zend за несколько лет проделали огромную работу и сделали удобный фрэймворк - его можно использовать как основу для своего сайта.

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

Вот вы собираетесь парсить пользовательский HTML, в ZF есть для этого компонента: http://framework.zend.com/manual/ru/zend.dom.query.html
2010-11-27 19:12
Linux Firefox
 Москва
0
0
 LLeo
Вы будете поражены: пока хомячки дрочили на чужие фреймворки, я тоже за несколько лет проделал огромную работу, и ее можно использовать как основу для своего сайта. Уже пара десятков сайтов используют. Как мне это удалось без Джквери, Кока-Колы, Гамбургера и прочих фреймфорков?
2010-11-27 19:51
Windows Safari Chrome
whois
1
0
 goodkat
Да я вас понимаю, и поэтому спорить мне с вами не охота - сам такой, люблю городить свои велосипеды :)

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

Я пишу не потому что покритиковать вас хочу, или я гуру какой, а наоборот, мне интересен ваш проект, хотел бы помочь в разработке.
2010-11-28 03:40
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Так-то оно так, вы правы. Да только и проект не большой - расти ему в высоту особенно и некуда. А вот расти в ширину (наполняя папки аякса и папки модулей новыми фичами и функциями) - это сколько угодно, но тут его нынешняя архитектура как раз не помеха, а помощь.
2010-11-22 21:19
Windows Safari Chrome
whois
0
0
 taskmgr
«1. Не существует никакого CODE.php из 1 файла, которому можно на вход подать текст, а получить текст гарантированно очищенный. Поэтому буду писать сам.»

Вы же на PHP будете писать? 
— Используйте любой штатный парсер, который построит по входящему тексту XML-дерево (XHTML)
— Пройдя это дерево рекурсивно, удаляя узлы с тегами (и атрибутами), не вошедшими в белый список.
— Сохраните получившееся дерево в HTML

Этим не только облегчится анализ, но заодно достигнется валидный HTML (да-да, я помню, что вам плевать на стандарты)
2010-11-23 02:38
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Что такое "штатный парсер"? Если это функция или модуль php - это одно. Если комплект на 1.5Мб из 200 файлов да еще со сложной лицензией - это другое. Если модуль в апаче или пакет для инсталляции, бинарник - это третье, и вообще неприемлемо для проекта.
2010-11-23 03:02
Windows Safari Chrome
whois
0
0
 taskmgr
Штатный - это входящий в PHP «из коробки».
Например, такой:
http://ru.php.net/manual/en/class.domdocument.php

Пользоваться очень просто, типа так:

$doc = new DOMDocument('1.0','utf-8');
$doc->loadHTML($USER_HML_NOT_SAFE);
MY_COOL_FUNCTION_TO_CHECK_TAGS($doc);
$SAFE_HTML = $doc->saveHTML();
2010-11-23 03:13
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Звучит очень заманчиво... Но вопрос: что это за $doc в итоге и как его обработать? Я не понгимаю формат.
2010-11-23 03:28
Windows Safari Chrome
whois
0
0
 taskmgr
$doc — объект типа DOMDocument class. Ссылка на документацию  — выше.
Если ты даже раньше не использовал в PHP объекты, то можно нагуглить и посмотреть пример использования класса DOMDocument и будет все понятно.
========================================
Вот обход без рекурсии, только узлы верхнего уровня
$doc = new DOMDocument();
$doc -> loadHTML($html);
foreach ($doc -> childNodes as $item)
    if ($item -> nodeType == XML_ELEMENT_NODE && $item->nodeValue == 'script')
      $doc -> removeChild($item); // remove hack
2010-11-23 04:01
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Понял, спасибо. Читаю документацию.
Есть смутные сомнения:

1) Говорят, в самом php постоянно обнаруживаются уязвимости. Я не очень понимал, о чем речь и где там могут быть уязвимости самого языка. Но, глядя на все эти хмл и дом-парсеры, начинаю подозревать, где... Я прав?

2) Чистка от "лишних" тэгов и атрибутов - достаточно сложное дело и после парсера. Если нет уязвимостей, которые можно создать именно неправильным построением дом (типа наоткрывать 1000 таблиц и не закрыть), которые завесят браузер... Если это все закрыть одним дивом (а за открытыми дивами следить). То я не вижу необходимости работать с дом вообще. Проще написать гонялку по тэгам, которая бы выкусывала лишние тэги и атрибуты. Ей-богу проще. поэтому хочу понять, могут ли быть опасности именно в дом, а не в тэгах. Навскидку - вроде нет.

3) Беглые тесты показывают, что парсер много гадит сам, и притдеться код чистить от лишнего. Типа как парсер doc-html Винворда - если заглянуть в его код, там ацкий ужас.
2010-11-23 04:22
Windows Safari Chrome
whois
0
0
 taskmgr
1) Не слышал про уязвимость именно в DOM-парсере. В PHP, разумеется есть, исправляются и т. д.
2) Ну может быть и лишнее строить ДОМ, тем более, что это достаточно тяжеловесная процедура, я просто предложил способ, и почему-то мне интуитивно чувствуется, что на каждый регэксп найдется хитрый невалидный хтмл. Обосновать не могу :-)
3) Не правда, если не считать гадостью заголовок !DOCTYPE, кавычки вокруг значений атрибутов, и некоторые тэги, которые на практике браузеры разрешают не ставить, типа TBODY
4) В примере выше, я не проверив, фигню написал, конечно :-)
5) Вроде в пятом PHP рекомендуют не этот парсер, а другой, основанный на событиях - он гораздо более легковесен. Кстати! Там события типа "встретился тег такой-то, ваши действия?" Это даже больше подходит для твоих целей, правда я его не юзал. И не знаю, может ли он читать кривой ХТМЛ, может ему только правильный ХМЛ нужен. Так что не подскажу точно.
2010-11-23 03:38
Nokia-E90 Safari
 Москва
0
0
 Леонит Каганофф
Попробовал. Нет, не понимаю, как И чем мне работать с промежуточным форматом, и что он вообще такое... Print_r() его не берет :)
2010-11-23 03:42
Windows Safari Chrome
whois
0
0
 taskmgr
как это не берет? а что он пишет?
всего комментариев: 73

<< предыдущая заметка
следующая заметка >>
	ноябрь 2010
ПН	ВТ	СР	ЧТ	ПТ	СБ	ВС
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30