Спустя несколько дней с момента устранения (http://www.opennet.ru/opennews/art.shtml?num=42098) прошлой уязвимости в популярной системе управления web-контентом WordPress выявлена новая критическая уязвимость, которая как и прошлая проблема дает возможность осуществить подстановку JavaScript-кода в комментарий к заметкам в блогах. В настоящий момент проблема уже устранена в оперативно сформированном выпуске WordPress 4.2.1 (https://wordpress.org/news/2015/04/wordpress-4-2-1/), но информация об уязвимости была раскрыта (http://klikki.fi/adv/wordpress2.html) до исправления, т.е. потенциально любой сайт на базе актуальной версии WordPress мог быть атакован.Метод атаки основан на том, что поле TEXT в MySQL не может превышать 64 Кб, в то время как лимит на размер комментария установлен в 66 тысяч символов. Если сообщение превышает данный размер, то хвост обрезается и в БД помещается лишь часть текста. Соответственно, можно добавить сообщение, размером чуть больше 64 Кб, в котором размещается HTML-тег с произвольным большим блоком текста внутри. Так как хвост будет обрезан тег останется разорван, что позволит обойти код чистки HTML-тегов в WordPress. После отображения такого текста, закрытием тега послужат далее идущие теги интерфейса WordPress. Если размещённый таким образом комментарий просмотрит администратор блога, то в его браузере в контексте блога будет выполнен JavaScript, через который можно получить доступ к операциям в интерфейсе администратора и организовать выполнение PHP-кода на сервере путём загрузки плагина или редактирования темы оформления.
<center><iframe width="640" height="360" src="https://www.youtube.com/embed/OCqQZJZ1Ie4" frameborder="0" allowfullscreen></iframe></center>
URL: http://arstechnica.com/security/2015/04/27/just-released-wor.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=42117
Это просто праздник какой-то!
Для вордпресса каждый день - такой "праздник".
Вордпресс - это праздник, который всегда с тобой.
Праздник каждый день :)
да уж, лучше использовать чистый html чем это..
Чистый html - совершенно не годится. Текст на голом html будет очень легко читаться, причём посетитель может позволять себе такую возмутительную наглость, как выбрать нравящийся ему, а не дизайнеру шрифт, его цвет и размер. На голом html неудобно делать текст сайта в виде тонкого столбца в 500 пикселей на экране шириной в 2-4 тысячи пикселей. На голом html никак не сделать, чтобы во время чтения вылезло на передний план какое-нибудь очень важное изображение. Крайне неудобно делать весь текст переливающимся всеми мыслимыми цветами.
Ну и кому он нужен, чистый html?
Ммм, простыню текста раскинувшуюся на весь экран от левого края до правого удобно читать?
CSS? Нет, никогда не слышал и слышать не желаю!
не экран, а окно... думать надо головой покупая "экран" с соотношением от 16:9 и открывая там одно окно браузера на всю ширь...
> не экран, а окно... думать надо головой покупая "экран" с соотношением от
> 16:9 и открывая там одно окно браузера на всю ширь...У меня так и есть. 16:9, 23" моник. На весь экран. И мне удобно.
> не экран, а окно... думать надо головой покупая "экран" с соотношением от
> 16:9 и открывая там одно окно браузера на всю ширь...Так у нормальных сайтов "резиновая" верстка и они на весь экран как раз получаются.
И если что - мониторы с мало-мальски большой диагональю нынче почти все 16:9 как правило. А не нравится .. ну смотри в офисные 1280х1024, блин. "Зато 4:3" - единственное достоинство такого экспоната.
> И если что - мониторы с мало-мальски большой диагональю нынче почти все
> 16:9 как правило. А не нравится .. ну смотри в офисные
> 1280х1024, блин. "Зато 4:3" - единственное достоинство такого экспоната.Есть, кстати, 2048х1536, тоже 4:3.
> Есть, кстати, 2048х1536, тоже 4:3.Хз, мне достойные внимания аппараты за разумные деньги в продаже не попадались. А так у меня 2560х1440 (вообще 16:10), к тому же IPS c нормальной цветопередачей и даже вполне разумным временем отклика. Очень приятный и довольно универсальный аппарат: и с графикой поработать, и кино посмотреть, и в игрушки побегать, и попрограммить - все на ура.
Очень удобно на самом деле оказалось. Навалом места по бокам для панелей во всяких графических редакторах, CAD, програмерских эдиторах и прочих подобных программах, всегда вспомогательная информация и инструментальные выноски умещаются, всегда все перед глазами. И даже какой-нибудь ушибленный прайс с кучей столбцов теперь не проблема.
На самом деле я не понимаю такую принципиальность в 4:3 на больших мониторах. У человека поле зрения в ширину больше чем в высоту и монитор с подобным соотношением сторон очень логично вписывается в поле зрения.
> Очень удобно на самом деле оказалось.Для большого настольного дисплея широкий формат удобнее.
> На самом деле я не понимаю такую принципиальность в 4:3 на больших
> мониторах. У человека поле зрения в ширину больше чем в высоту
> и монитор с подобным соотношением сторон очень логично вписывается в поле
> зрения.Уже 17-ти дюймовый ноут лучше не 4:3, а широкоформатный. Но вот на малых диагоналях широкоформатный монитор превращается в танковую щель. Поэтому, для текста на совсем крошечных ноутах лучше вообще квадратный монитор, на 12-15 дюймов - 4:3, дальше широкий формат.
Но у меня-то 15-ти дюймовый 4:3.
Более того, от размера монитора зависит и то, какой оконный менеджер стоит использовать. Например, на большом мониторе текст лучше не разворачивать во весь экран, а держать колонкой, окна не наслаиваются => лучше что-то вроде WindowMaker'а. На средних мониторах уже хорошо идут мозаичные WM, на маленьких - каждое окно на полный экран.
> так у меня 2560х1440 (вообще 16:10)Вообще это 16:9. 16:10 — 2560х1600.
> Ммм, простыню текста раскинувшуюся на весь экран от левого края до правого удобно читать?Немного увеличенным шрифтом - вполне удобно. И у меня экран лёгким движением руки становится вертикальным.
> Немного увеличенным шрифтом - вполне удобно. И у меня экран лёгким движением
> руки становится вертикальным.Если экран - не совсем щель, то это даже лучше 4:3.
> На голом html неудобно делать текст сайта в виде тонкого столбца в 500 пикселей на экране шириной в 2-4 тысячи пикселей.Табличная вестка же! Там это делается элементарно.
"поле TEXT в MySQL не может превышать 64 Кб, в то время как лимит на размер комментария установлен в 66 тысяч символов"Я даже не знаю, как это прокомментировать.
ну ошиблись, сделать alter table, поменять TEXT на LONGTEXT и всё заработает или массив свой поменять на 63кб
Движок самдолжен запрашивать макс размер поля в БД
> Движок самдолжен запрашивать макс размер поля в БДНа каждый запрос клиента? Получать типы, размерности, связи и прочее? Этак мы до битрикса докатимся. Если и делать, то с кэшированием, хотя бы в админке, а лучше при обновлении версии/изменении модулей, и в конфиги. Тогда не будет провала в скорости для простых юзеров.
> Если и делать, то с кэшированием, хотя бы в админкев смысле, перечитывать свойства базы при изменениях в админке, причём не во всех разделах, а только в тех, где есть шанс изменения структур данных.
Ну и кнопка force sync для ручных изменений.
Какой LONGTEXT?
VARCHAR(xxx) уже давно как позволяет до нескольких мегабайт записывать с указанием ограничения в байтах.
TEXT-ом пользуются те, кто до сих пор в танке.
Но проблему это всё равно не решает, нужно при валидации самому следить чтобы текст был не пустым и не переваливал за установленное значение, что делается простым isset-ом.
> в то время как лимит на размер комментария установлен в 66 тысяч символов.Сначала не понял откуда такое число, но
> The exploit works by posting some simple JavaScript code as a comment and then adding a massive amount of text—about 66,000 characters or more than 64 kilobytes worth.
Если я правильно понял, в самом WP никакого лимита нет вообще. Имеется в виду, что для размещения XSS достаточно 64k любого текста + пару k на сам эксплойт.
А вообще, имхо, предоставлять пользователям публичных ресурсов возможности HTML-разметки - это всегда опасная практика. Формат уже слишком сложный, чтобы можно было полагаться на всякие средства "очистики". Если прям необходимо дать возможность выделять текст "жирненьким", лучше встроить какой-нибудь markdown или bb-коды на худой конец.
Точнее, разметку можно (и нужно) делать HTML-подобной - такое большему числу людей понятно, но всё равно её полностью парсить и генерировать заново.
html проще парсить, чем тот же markdown. Не говоря о textile.
А все потому что мыскль.
В нормальной субд при превышении размера поля будет error и rollback.Да, в мыскле тоже можно включить strict mode, но этого никто не делает - половина кода, написанного похапе-программистами, отвалится.
Какой флаг нужно вписать в sql-mode?
STRICT_ALL_TABLES
У меня STRICT_TRANS_TABLES
Если таблицы в InnoDB - сойдёт.
TokuDB
Ну или так, TRANS_ - это для всех движков, которые Transactions = YES в SHOW ENGINES.
Если не 90%.
всё‐таки пицца оказалась не умнее сыра.
Увы. Это, наверное, зелёная Жаба виновата. Давно пора было уволить.
Да просто не надо полагаться на то, что в базе html типа "чистый" - нужно очищать ПОСЛЕ того, как берёшь из базы. Заодно получаешь защиту от просто подстановки яваскрипта через какую-нибудь дыру, которая позволяет текст записей менять.Очищать кстати норм htmLawed'ом.
P.S: Я думал, что "критичная" - это выполнение кода, а тут XSS всего лишь... этих XSS'ов там по-моему на каждом углу.
> P.S: Я думал, что "критичная" - это выполнение кода, а тут XSS
> всего лишь... этих XSS'ов там по-моему на каждом углу.Нет, тут не XSS и не всего лишь, а возможность впихать свой JS, который при просмотре админом может лихо вкачать PHP shell на сервер и далее поиметь все и вся с правами пользователя под которым php крутился.
Это, конечно, многоходовочка, но с учетом массовости вордпресса - такое будет летать чартерными рейсами в самом обозримом будущем. Халявные шеллы нужны всем, так что пощады от хакерья не ждите.
Слушайте, а у меня идея: ставишь на localhost любой http сервер, на него загружаешь любой, какой угодно дырявый CMS (ну или делаешь сайт с нуля), а потом сделать такой скриптик, который скачивает его целиком с помощью чего-то вроде httrack в виде статических html файлов и заливает их на хостинг (само собой только те, котрые обновились). Правда комментарии в таком блоге оставлять не получится, но можно вынести их в отдельные страницы (типа как гостевые книги в старые времена, только для каждого поста). А порядком можно даже специально заточенный CMS запилить для этой цели, который генерировал бы реальные html файлы и заливал их на хостинг. А можно чтоб даже можно было выбрать, какие страницы превращать в 100% статические, а какие оставить динамическими.
https://www.staticgen.com/ is your friend.
Спасибо! Я просто не смог найти, как этот подход называется - везде тупо давали ссылки на flat-file CMS.
Я такую фигню на python, bottle и scp собрал минуты за две. Правда, не для блогов, а для просто статических сайтов, у меня они все статические.А для блогов существуют десятки подобных решений, с разными дискусами для комментариев.
Wordpress удалили из портов OpenBSD. Ибо нефиг :)