Три года назад инженер по программному обеспечению Google Али Джума предложил внести изменения в работу браузера Chrome, которые бы позволили защитить пользователей от кликджекинга.

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

Кликджекинг – механизм обмана пользователей, при котором переход по ссылке на каком-либо сайте перенаправляет пользователя на вредоносную страницу – стал очень эффективным. Часто он используется для распространения через Facebook ссылок на вредоносные сайты. Недавно подобные техники показали свою эффективность в деанонимизации посетителей сайта. Также переход по хитрой ссылке может привести к тому, что злоумышленник получит доступ к данным OAuth. Давайте посмотрим, как это происходит.

Здравствуйте, Хабражители!

Сегодня гулял по сети, зашел на Яндекс, чтобы посмотреть погоду в столице. Когда нажал кнопочку «другой город» Яндекс перенаправил меня сюда. Я думаю, что у каждого, кто видит такой адрес возникает желание подменить один из параметров, а точнее retpath. :) Вставил я туда стандартный

"><script>alert('xss');</script>

и залез в исходник, смотреть что фильтруется, а что нет. Вот такая строка была в исходнике.

<span onclick="return {'b\-form\-button':{name:'b\-form\-button', 'retpath': &quot;\&quot;&gt;&lt;script&gt;alert('xss')&quot;}}"

Ну, думаю, скукота, — все фильтруется. Потом посмотрел внимательней и понял, что Яндекс не добавляет к URL вначале протокол, вот тут можно и поиграться. Ввел

javascript: alert('xss');

— работает! Но к сожалению, только при нажатии на кнопку «Вернуться». Можете попробовать. Уже интереснее, копаем дальше…

100 миллиардов долларов США – огромная сумма, не правда ли? Именно во столько оценивают мировой рынок интернет-рекламы в 2012 году. Не надо далеко ходить, чтобы понять, кто получит большую часть этих денег. Конечно же, это такие компании, как Google, Facebook, Yahoo! и т.д. Но примерно 20% от этой суммы получат спамеры. Эти огромные деньги привлекают очень хорошо организованный бизнес и талантливых людей.

19 марта мы объявили о начале месяца поиска уязвимостей «Проверь Badoo на прочность». Сегодня нам хочется подвести первые итоги и поделиться с вами промежуточными результатами, рассказать, как мы готовились к проверке на прочность, рассмотреть самые интересные уязвимости и сделать «фейспалм».

И для начала немного статистики:

• за первые две недели участники прислали нам почти 500 заявок с потенциальными уязвимостями;
• около 50 заявок оказались дубликатами;
• каждая десятая заявка содержала в себе реальную уязвимость (самые опасные были исправлены в течение нескольких часов);
• Более 150 заявок составили ошибки, не связанные с безопасностью сайта, и около 10% из них относятся к платформам, не участвующим в конкурсе.
• большинство уязвимостей пришлось на самый главный компонент системы ― профиль (как только участники конкурса не издевались над аккаунтами пользователей: удаляли и загружали фотографии, манипулировали комментариями, интересами, личными данными и адресами электронной почты).
• Более половины присланных уязвимостей ― различные CSRF, в основном затрагивающие загруженный или написанный пользователями контент (удаление и загрузка фото и комментариев, работа с чёрным списком, избранным и т.д.).

В современном Интернете мы всё чаще сталкиваемся с различными опасностями, исходящими с Web-страниц. Уязвимые плагины, XSS на сайтах, эксплуатирование уязвимостей с помощью JavaScript, Clickjacking — и это далеко не полный список радостей жизни, которые могут встретиться на сайтах.

Даже если у Вас Linux или Mac OS X, нельзя быть полностью спокойными — в таком случае гадость просто не выйдет за пределы браузера, а вот cookies или LocalStorage извлечь вредоносный код вполне в состоянии. Также мощности компьютера могут быть использованы в совершенно неожиданных целях, вплоть до майнинга биткойнов на компьютере жертвы.

Так что защищать браузер необходимо не только снаружи, но и изнутри. Для этого нужно посмотреть на соответствующие расширения, чему и посвящён этот пост. Также здесь будут рассмотрены некоторые вопросы приватности (но не анонимности!), чтобы вы могли защититься от следящих компаний.

Поговорим о виджете для авторизации.

Нам говорят, что:

С помощью виджета для авторизации Вы можете максимально просто предоставить пользователям возможность авторизовываться на Вашем ресурсе.

Также, нам говорят, что:

В результате авторизации виджет возвращает следующие поля: uid, first_name, last_name, photo, photo_rec, hash.

Несколько дней назад искал зимнюю резину. Искал в поисковой выдаче Яндекса. Переходил на сайт, смотрел. Ничего не подошло, оставил дело на потом. Ничего нигде не заполнял, никому ничего не писал (это важно).

Сегодня мне пишут в личном сообщении ВК:

«Вы интересовались нашим товаром на странице…. Мы можем Вам помочь… бла-бла-бла».

Я был очень удивлен. Как они узнали, что это был именно я?

Месяц назад на очередной Droid Party старший разработчик Данила Фетисов подробно разобрал принцип действия службы, которая отвечает за accessibility-функции Android. Вы узнаете о том, как использовать её для улучшения доступности своих проектов, а также об опасной уязвимости под названием clickjacking.


— Меня зовут Данила Фетисов, я из московского офиса Яндекса, конкретнее — из Такси, конкретнее — из Таксометра. Сегодня мы с вами поговорим о том, что же такое Android accessibility и почему же я такую святую штучку для людей с ограниченными возможностями решил назвать волком в овечьей шкуре.

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

Введение

Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат кри­тичес­кие уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

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