> Смотрим на картинки, которые приводит автор, и делаем еще несколько выводов: пользователи игнорируют логотипы сайтов, заголовки статей, вообще все картинки, меню и вообще всю навигацию.
Вот тут я могу подтвердить свои налюдения: когда я пользуюсь браузером без фильтра рекламы, баннеры и текстовая реклама (обычно обведена рамочкой и имеет специфический вид) отсеиваются подсознательно. Даже если взгляд попадает на рекламу, как только я пойму, что это реклама, я убираю взгляд.
Надежно замечается только реклама, объекдиненная с полезным контентом и мимикирующая под него.
Да, это верно. Например, хотите узнать кто посетил определенную веб-страницу? Берем какую-нибудь CSRF-уязвимость вконтакте (я не знаю, какую, их периодически находят, а потом закрывают), к примеру (пример выдуманный), отправляющий сообщение кому-нибудь, типа vkontakt.ru/mail.php?act=send&to_id=1&text=hello, делаем страничку с [img src=«эта ссылка»], заманиваем жертву, проверяем почту.
Все беды — от инвалидов-производителей бразузеров и станжартов. разрешающих 3rd party активное содержимое. И от вещей типа Content type sniffing, когда сервер отдает png с типом text/plain, а бразер все равно отображает его как картинку, если файл укаазн в [img src=...] (вот за это вообще убивать надо)!
Я так понимаю, Content-type sniffing был сделан из-за большого кол-ва криво настроенных серверов, не отдававших правильный тип файла. Почему надо отображать левые файлы, вмсето того, чтобы вправить мозги криворуким вебмастерам. я искренне не понимаю.
> Например, что можно объединить GIF + JAR (он же zip), PDF + JAR и этот файл будет валидным pdfом и валидным jarом в одно и то же время?
Дык если у него расширение .gif — у него тип image/gif, и толку от того, что к нему приклеен JAR? Правильный (не существующий в природе, лол) браузер отобразит картинку и все. В чем риск? Вот реальный риск — это когда png-картинка в начале содержит тег типа [html][script..], и тупая майкрософтовская поделка *интерпретирует* картинку как HTML документ (с выполнением скрипта в нем).
В общем мое мнение — веб-стандарты, технологии для серверного программирования, и реализации браузеров должны были быть по дефолту безопасными. Возьмите язык парсер — там выводимые данные автоматически экранируются, так что, чтобы сделать XSS, надо *специально* написать соответствующий параметр, о котором начинающий программист может быть и не в курсе. То же с параметрами SQL-выражений.
Несмотря на то, что сам Парсер — ограниченная, в общем-то домашняя поделка, с плохим синтаксисом, но с этой точки зрения (tainted/untainted data) он сделан грамотно.
Вообще, модемные соединения в винде — отдельная тема, у меня как-то было такое, что при отсоединении/ошибке GPRS-модема сетефой интерфйес и правила роутинга не удалялись, в результате пакеты никуда не ходили. Переподсоединиться тоже было невозможно, команда rasdial просто наглухо висла (подозреваю неснятую блокировку). Перезапуск службы телефонии и сетевых подключений (или как там ее) тоже ничего ее давал :((
> и привык к Мплейеру, который не пользовался дайректиксовскими кодеками
1) Да, у Мплейера свои кожеки для декодирования видео
2) Нет, Mplayer по умолчанию *использует* оверлеи (DirectX), т к это выгодно с точки зрения производительности.
Вот, как приятно читать вещи типа «укладывалась в несколько мегабайт».
Но, с другой стороны отрисовка градиента «70 раз в секунду» на современном процессоре — маловато (как же игры работают, там более сложные картинки), может тут надо уже видеокарту там задействовать, или directX какой-нибудь, чтобы быстрее рисовалось.
> Вечные проблемы с отрисовкой: часто не всё отрисовывается в динамике и остаются старые куски. Наглядно видно в твиттере.
Ага, помню, под выдвигающимся меню пришлось поместить невидимый див, высотой с это меню, если его двигать яваскриптом — движение меню прорисовывается, иначе ничего не происходит ((
Вообще, что-то в последнее время Опера, к которой раньше не было особых нареканий, глючит не по детски.
Гм, а вроде же для флоатов (и абс. поз. элементов) можно не указывать ширину, тогда она определяетс сама по какому-то алгоритму «shrink-width», т.е. по ширине контента?
Если это быстрее даст результат, то нифига не хуже. Чем возиться с этими дебанггерами, настраивать, запускать какую-нибудь убогую тяжеленную IDE на яве, нафиг нужно (а консольный дебаггер — вообще ад).
Ну а если вам, чтобы все заработало, надо «весь день» отлаживать программу, может стоит код правильно переписать? На модули там разбить какие-нибудь.
1 — Nokia PC Suite — убогая софтина, сделанная явно аутсорсерами. мне как программисту, ее видеть противно, тем более что она у меня на порезанной винде не установилась и причину не установки тоже говорить отказалась :)
Пришлось руками ставить драйвера, телефона, кабеля, позже и Bluetooth, мучения адские, они требуют каких-то левых программ в автозапуске (драйвера??), требуют зачем то запущенную службу DCOMLaunch — лучше бы я под Убунтой сидел с приятным интерфейсом, чем под виндой, где каждый производитель делает свою (в 99% случаях тяжелую, убогую, плохо сделанную) приблуду для каждого устройства, и этой фигней я должен загрязнять свой жесткий диск.
Но Убунту мегаторозная, и неправильная внутри (в смысле в плане архитектуры и прочего), так что приходится продолжать есть кактусы ((
Дык проблема, что D — пожалуй лучший вариант, из того что есть. C/C++ просто невозможно пользоваться — руки отвалятся, устаревший, громоздкий, провоцируюший-к-ошибкам синтаксис.
А D более-менее вменяем, поддерживает C-библиотеки, почему бы не пользоваться? Несмотря на все недостатки из статьи.
Я вас понял :) Просто хотелось бы язык с продвинутым и удобным синтаксисом, типа Руби (ну или хотя бы D), но компилируемый и без мерзких сборщиков мусора и многомегабайтного потребления памяти ((
То есть, в идеале, чтобы избавляться от лишних deep copy при возврате занчений из функции не использвоанием Pick, а чтобы компилятор все это прозрачно делал :)
Упс, туплю немного :)) Правильный пункт 2) выглядит так:
2) На *своем* сервере пишем код типа: [a href=«mail.google.com/… путь к флешке»]
3) Заманиваем жертву на свой сервак, где яваскрипт кликает по ссылке и загружает флешку в браузер. Для флешки origin domain будет хост. где она расположена. например mail.google.com
Перевожу еще раз для всех, кто тупит! И не понимает основ!!! HTML, теорию блин учите! Так вот.
1) Загружаем флеш на нужный нам сайт, например: vkontakte :) gmail или куда-то еще, лишь бы туда можно было лить флеш.
2) На *своем* сервере пишем код типа: [embed src=«mail.google.com/… путь к флешке»]
3) Заманиваем жертву на свой сервак
4) Флешка загружается в браузер жертвы и получает доступ к кукам юзера на mail.google.com, + возможность жделать туда запросы.
Как уже замечено, взломщикам может помочь то, что флеш можно «склеить» с zip, gif и прочими файлами, что расширяет диапазон сайтов для взлома.
Единственное исправление, в самом новом флеше: Если есть заголовок Content-disposition :attachment, такая флешка выполняться не будет. Это защищает правильно сделанные (т.е. отдающие этот заголовок) файлообменники, форумы с вложениями для скачивания, и т.д.
Если же сайт позволяет загружать на себя флеш и отображать его — он (точнее его юзеры) может стать жертвой.
Кто виноват?
Инвалиды-разработчики HTML, которые позволили включать на страницу 3rd party активный контент (скрипты, флеши, апплеты). Производители браузеров, которые их послушали. В связи с этим уже пришлось придумать кучу дурацких правил, типа same origin policy, которая все равно например не дает 100% защиты, а только осложняет все. Сколько с этим связано угроз типа CSRF, угроз приватности и прочего — никто не борется :((
К тому же все эти тонкости слишком сложны для понимания начинающими разработчиками, что потенциально увеличивает число уязвимых сайтов.
Как бороться?
Либо не позволять загружать на свой сайт флеш (даже если он переименован в zip к примеру)б либо хранить загружаемые юзерами файлы на отдельном домене, либо отдавать все загружаемые файлы с Content-Disposition: attachment.
Что делать?
Запретить флеш :) Я например, включил флеш только для сайтов типа ютуб, на многих других он все равно не нужен (спасибо, флешевую рекламу оставьте себе).
> Пора уже взрослеть и трезво смотреть на вещи, если единственное, за что платят здесь и сейчас — это «тыкание кнопок в 1С или виндоусах в какой-то помойке, разгребая чужие косяки», то нужно стиснуть зубы и заниматсья именно этим.
Дык подстава в том, что в такой ситуации так ничего и не изменится, так и будешь тыкать кнопки, пока коллеги всяких там успехов и карьерного роста добиваются.
Да и на том же Маке, в культовом TextMate никакого дебага нет.
> Смотрим на картинки, которые приводит автор, и делаем еще несколько выводов: пользователи игнорируют логотипы сайтов, заголовки статей, вообще все картинки, меню и вообще всю навигацию.
Вот тут я могу подтвердить свои налюдения: когда я пользуюсь браузером без фильтра рекламы, баннеры и текстовая реклама (обычно обведена рамочкой и имеет специфический вид) отсеиваются подсознательно. Даже если взгляд попадает на рекламу, как только я пойму, что это реклама, я убираю взгляд.
Надежно замечается только реклама, объекдиненная с полезным контентом и мимикирующая под него.
Я так понимаю, Content-type sniffing был сделан из-за большого кол-ва криво настроенных серверов, не отдававших правильный тип файла. Почему надо отображать левые файлы, вмсето того, чтобы вправить мозги криворуким вебмастерам. я искренне не понимаю.
> Например, что можно объединить GIF + JAR (он же zip), PDF + JAR и этот файл будет валидным pdfом и валидным jarом в одно и то же время?
Дык если у него расширение .gif — у него тип image/gif, и толку от того, что к нему приклеен JAR? Правильный (не существующий в природе, лол) браузер отобразит картинку и все. В чем риск? Вот реальный риск — это когда png-картинка в начале содержит тег типа [html][script..], и тупая майкрософтовская поделка *интерпретирует* картинку как HTML документ (с выполнением скрипта в нем).
В общем мое мнение — веб-стандарты, технологии для серверного программирования, и реализации браузеров должны были быть по дефолту безопасными. Возьмите язык парсер — там выводимые данные автоматически экранируются, так что, чтобы сделать XSS, надо *специально* написать соответствующий параметр, о котором начинающий программист может быть и не в курсе. То же с параметрами SQL-выражений.
Несмотря на то, что сам Парсер — ограниченная, в общем-то домашняя поделка, с плохим синтаксисом, но с этой точки зрения (tainted/untainted data) он сделан грамотно.
1) Да, у Мплейера свои кожеки для декодирования видео
2) Нет, Mplayer по умолчанию *использует* оверлеи (DirectX), т к это выгодно с точки зрения производительности.
Но, с другой стороны отрисовка градиента «70 раз в секунду» на современном процессоре — маловато (как же игры работают, там более сложные картинки), может тут надо уже видеокарту там задействовать, или directX какой-нибудь, чтобы быстрее рисовалось.
Ага, помню, под выдвигающимся меню пришлось поместить невидимый див, высотой с это меню, если его двигать яваскриптом — движение меню прорисовывается, иначе ничего не происходит ((
Вообще, что-то в последнее время Опера, к которой раньше не было особых нареканий, глючит не по детски.
> www.w3.org/TR/CSS2/visudet.html#float-width
> If 'width' is computed as 'auto', the used value is the «shrink-to-fit» width.
Ну а если вам, чтобы все заработало, надо «весь день» отлаживать программу, может стоит код правильно переписать? На модули там разбить какие-нибудь.
Да не за что, но вы меня с кем-то спутали :)
> Pagefile — 42M
Считать-то умеете? В наше время мало осталоь программистов, способных уложиться 3 Мб для GUI-программы (а среди Линукоидов их вообще нет).
Пришлось руками ставить драйвера, телефона, кабеля, позже и Bluetooth, мучения адские, они требуют каких-то левых программ в автозапуске (драйвера??), требуют зачем то запущенную службу DCOMLaunch — лучше бы я под Убунтой сидел с приятным интерфейсом, чем под виндой, где каждый производитель делает свою (в 99% случаях тяжелую, убогую, плохо сделанную) приблуду для каждого устройства, и этой фигней я должен загрязнять свой жесткий диск.
Но Убунту мегаторозная, и неправильная внутри (в смысле в плане архитектуры и прочего), так что приходится продолжать есть кактусы ((
А D более-менее вменяем, поддерживает C-библиотеки, почему бы не пользоваться? Несмотря на все недостатки из статьи.
То есть, в идеале, чтобы избавляться от лишних deep copy при возврате занчений из функции не использвоанием Pick, а чтобы компилятор все это прозрачно делал :)
Будем ждать, вдруг кто напишет?
2) На *своем* сервере пишем код типа: [a href=«mail.google.com/… путь к флешке»]
3) Заманиваем жертву на свой сервак, где яваскрипт кликает по ссылке и загружает флешку в браузер. Для флешки origin domain будет хост. где она расположена. например mail.google.com
1) Загружаем флеш на нужный нам сайт, например: vkontakte :) gmail или куда-то еще, лишь бы туда можно было лить флеш.
2) На *своем* сервере пишем код типа: [embed src=«mail.google.com/… путь к флешке»]
3) Заманиваем жертву на свой сервак
4) Флешка загружается в браузер жертвы и получает доступ к кукам юзера на mail.google.com, + возможность жделать туда запросы.
Как уже замечено, взломщикам может помочь то, что флеш можно «склеить» с zip, gif и прочими файлами, что расширяет диапазон сайтов для взлома.
Единственное исправление, в самом новом флеше: Если есть заголовок Content-disposition :attachment, такая флешка выполняться не будет. Это защищает правильно сделанные (т.е. отдающие этот заголовок) файлообменники, форумы с вложениями для скачивания, и т.д.
Если же сайт позволяет загружать на себя флеш и отображать его — он (точнее его юзеры) может стать жертвой.
Кто виноват?
Инвалиды-разработчики HTML, которые позволили включать на страницу 3rd party активный контент (скрипты, флеши, апплеты). Производители браузеров, которые их послушали. В связи с этим уже пришлось придумать кучу дурацких правил, типа same origin policy, которая все равно например не дает 100% защиты, а только осложняет все. Сколько с этим связано угроз типа CSRF, угроз приватности и прочего — никто не борется :((
К тому же все эти тонкости слишком сложны для понимания начинающими разработчиками, что потенциально увеличивает число уязвимых сайтов.
Как бороться?
Либо не позволять загружать на свой сайт флеш (даже если он переименован в zip к примеру)б либо хранить загружаемые юзерами файлы на отдельном домене, либо отдавать все загружаемые файлы с Content-Disposition: attachment.
Что делать?
Запретить флеш :) Я например, включил флеш только для сайтов типа ютуб, на многих других он все равно не нужен (спасибо, флешевую рекламу оставьте себе).
Дык подстава в том, что в такой ситуации так ничего и не изменится, так и будешь тыкать кнопки, пока коллеги всяких там успехов и карьерного роста добиваются.