Поговорим о компьютерных вирусах? Нет, не о том, что вчера поймал ваш антивирус. Не о том, что вы скачали под видом инсталлятора очередного Photoshop. Не о rootkit-e, который стоит на вашем сервере, маскируясь под системный процесс. Не о поисковых барах, downloader-ах и другой малвари. Не о коде, который делает плохие вещи от вашего имени и хочет ваши деньги. Нет, всё это коммерция, никакой романтики…

Мы поговорим о компьютерных вирусах, как о коде, который способен порождать собственные копии, изменяясь от поколения к поколению. Которому, как и его биологическим собратьям, необходим файл-носитель, работоспособный, и остающийся работоспособным, чтобы давать жизнь новым поколениям вируса. Которому для размножения необходима благодатная среда, много вкусных исполняемых файлов, а также, много глупых и активных пользователей, чтобы они их запускали. Так что название «вирус» не просто красивый ярлычок для описания вредоносной программы, компьютерный вирус, в его классическом понимании, является сущностью весьма близкой к его биологическому аналогу. Человечество, как это не раз доказывалось, способно создавать весьма изощренные решения, особенно когда дело касается создания чего-нибудь наносящего вред другим людям.

Статья будет о создании второй по счету моей игры под Android, на кроссплатформенном движке Cocos2D-x (v3.1). Код преимущественно на С++, местами Java и Lua. Попытаюсь вкратце рассказать про основные моменты разработки.

Думаю, не мне одному чрезвычайно надоели ресурсы, требующие регистрации по каждому поводу и без. С обязательной капчей, которая правильно введется только с пятого раза, с подтверждением по е-мейлу, которое обязательно свалится в спам и то — только через сутки. Придумывать каждый раз новую пару логин-пароль — забудется, вводить одно и то же на всех сайтах — небезопасно. Местами прокатывают пары вида «qwerty:qwerty» или «login:password», но, увы, далеко не везде. Надоело. Не счесть, сколько раз я, увидев надпись «только зарегистрированный пользователь может ****», просто кривился и закрывал вкладку, чтобы больше ни разу на этот сайт не заходить. Неужели администраторы ресурсов сами этого не понимают?

Недавно рынок e-commerce CMS пополнился новым продуктом от ReadyScript lab. Система обладает рядом уникальных особенностей, о которых мы расскажем в этом посте.

Мы продолжаем делать обзор функционала современного интернет-магазина и саму технологию проектирования качественного продукта с высокой конверсией. В этой части мы расскажем про карточку товаров и все, что с ней связанно. В прошлый раз мы написали довольно популярные статьи: «Серьезное проектирование серьезного магазина. Часть 1. Исследования» и «Серьезное проектирование серьезного магазина. Часть 2. Модули интернет-магазина», эта статья логическое продолжение.

Карточка товара

Рис. 1. Карточка товара

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

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

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

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

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

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

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

Это, собственно, и стало поводом написать такую статью, в которой тезисно будут описаны основные уязвимости, причины, примеры и решения.

Некоторые из предоставленных в списке уязвимостей уже расписаны и не раз — известный факт, но без них список был бы неполным. Поэтому сразу дам небольшое содержание поста:

• SQL Injection
• Некорректная аутентификация и управление сессией
• Межсайтовый скриптинг (XSS)
• Небезопасные прямые ссылки на объекты
• Небезопасная конфигурация
• Утечка чувствительных данных
• Отсутствие контроля доступа к функциональному уровню
• Подделка межсайтовых запросов (CSRF)
• Использование компонентов с известными уязвимостями
• Невалидированные редиректы
• Кликджекинг
• Фишинг
• Include

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



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

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

Возникла идея объединить в одной системе и базе данных всю внутреннюю работу и звонки. Я долго допиливал нашу CRM с функцией встроенной звонилки c записью разговоров.
Для реализации звонков рассмотрел ряд технологий и пришел к выводу, что их не так уж и много. Нашлась пара опенсорсных и коммерческих реализаций, а так же несколько SAAS сервисов, которые не подходили в силу внутренних политик безопасности — обрабатывать звонки через собственный сервер.

В начале пытался использовать sipml5:

Уровень подготовки веб-мастера: любой

Функция «Просмотреть как Googlebot» в Инструментах для веб-мастеров позволяет понять, как ваша страница выглядит для роботов Googlebot. Заголовки серверов и код HTML помогают выявить ошибки и последствия взлома, но иногда разобраться в них бывает затруднительно. Веб-мастера обычно хватаются за голову, когда им приходится заниматься решением таких проблем. Чтобы помочь вам в подобных ситуациях, мы усовершенствовали эту функцию, и теперь она может показывать страницу с помощью того же алгоритма, который использует робот Googlebot.

Здравствуйте! Я решил попробовать себя на поприще game-dev'а и заодно рассказать и показать как это было. Вторая часть здесь.

Игра представляет собой экран, на котором расположены созвездия. Каждая звезда этого созвездия имеет свой цвет (нота). Например, ноту «До» обычно представляют красным цветом, а «Ми» — желтым. Вот что получится в итоге:



Итак, каждый уровень — новое созвездие и новая мелодия. Звезды играют первые четыре ноты, а затем вы должны повторить их в той же последовательности. Затем, к первым четырем нотам добавляются еще четыре и так далее, пока уровень не будет пройден.

Писать будем, используя фреймворк libGDX. Мне он больше всех понравился, как новичку в этом деле. Да и информации по нему я нашел больше. Итак, приступим.

Простите, но накипело.
Много шишек уже набито на тему безопасности сайтов. Молодые специалисты, окончившие ВУЗы, хоть и умеют программировать, но в вопросе безопасности сайта наступают на одни и те же грабли.

Этот конспект-памятка о том, как добиться относительно высокой безопасности приложений в вебе, а также предостеречь новичков от банальных ошибок. Список составлялся без учета языка программирования, поэтому подходит для всех. А теперь позвольте, я немного побуду КО.


Итак, каким должен быть безопасный сайт?

Пост о воплощении мечты и о создании игры с нуля. И о граблях разной величины.

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

(характеристика1 = true AND (характеристика2 < 100)) OR (характеристика1 = false AND (характеристика3 > 17)) ... далее обычно мешанина из AND\OR

Типичный пример подобного функционала — hotline.ua/computer/myshi-klaviatury



У нас все реализовано в рамках MySQL + Symfony2/Doctrine, скорость неудовлетворительная — ответы формируются в течении 1-10 секунд. Мои попытки оптимизировать все это хозяйство — под катом.

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

Поэтому в этой статья я решил собрать топ-10 советов о том, как же можно увеличить скорость загрузки веб-странички и сайта в целом. Статья не претендует на гениальность и рассчитана на новичков.

В первом посте об аналитической системе Sports.ru и Tribuna.com мы рассказали о том, как используем нашу инфраструктуру в повседневной жизни: наполняем контентом рекомендательную систему, наблюдаем за бизнес-метриками, ищем среди пользовательского контента бриллианты, находим ответы на вопросы “Как работает лучше?” и “Почему?”, нарезаем пользователей для почтовых рассылок и строим красивые отчеты о деятельности компании. Всю техническую часть повествования мы скромно спрятали за этой схемой:



Читатели законно потребовали продолжить повествование со смешными котиками, а olegbunin пригласил рассказать о всем, что было скрыто, на РИТ++. Что ж, изложим некоторые технические детали – в продолжении веселого поста.

Как реализовать long polling с помощью Nginx и Javascript в сети достаточно много материала. Но полного руководства я ещё не встречал. То возникают проблемы с компиляцией модуля под Nginx, то в браузере вертится иконка загрузки при long poll запросах. Под катом, полный материал как же все таки это сделать правильно.

Быть может создатели реестра запрещенных сайтов не думали о том, что такое возможно. А может им было известно о такой возможности, но они не придали ей должного значения. А может им не было дела до возможных технических проблем при реализации реестра, и «лишь бы запретить». А может им было понятно, что избежать таких проблем нельзя, и к чему об этом волноваться раньше времени?..

Можно долго спекулировать о том, что они думали и чем они не думали, но факт есть факт: блокировкой любого сайта они невольно вручают мощное средство, если не сказать орудие, защиты и нападения в руки владельца домена, включенного в реестр.

Логичным продолжением заметки про неявные вызовы php кода во вредоносных скриптах будет ее вторая часть, в которой я рассмотрю более сложные и менее очевидные варианты использования различных обработчиков и загрузчиков php, а в конце статьи приведу несколько примеров, как еще хакеры неявно вызывают вредоносный код и php скрипты на сайте.

В качестве примера вредоносного кода снова будем использовать вызов

echo 'Test'

Поскольку цель статьи показать различные подходы и механизмы скрытого выполнения кода, то для простоты функция, которая выполняет наш «вредоносный код» будет объявлена рядом с вызываемым ее неявно кодом. В реальной жизни вредоносный код и его вызов находятся далеко друг от друга, как минимум в разных php скриптах, но чаще код подгружается из базы данных, мета-данных изображений, с другого сервера, после чего выполняется функцией eval, assert, preg_replace и им подобными.

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

Данный подход популярен среди разработчиков вредоносного кода, так как с одной стороны значительно усложняет анализ исходного кода, а с другой позволяет хранить код в текстовых данных. Например, часть вредоносного кода может загружаться со стороннего сайта, из базы данных, мета-данных jpeg/png/gif или передаваться в запросе к скрипту. Кроме того, часть кода, представленная в виде обычной текстовой строки, может быть легко зашифрована.

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

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

echo "Test"

который выводит слово «Test» на странице. Естественно, в реальных шеллах и бэкдорах имена переменных и функций, а также исполняемый код не хранятся в открытом виде и в большинстве случаев обфусцированы.