В новостной ленте я недавно обнаружил любопытное исследование, где ребята скачали и распарсили Android Playmarket, проанализировали сотни тысяч приложений на предмет наличия зашитых секретных токенов и паролей.

То что результат их работы касался только анализа декомпилированного кода под Android, cподвиг меня написать про исследование, которое я проводил еще год назад, причем не только для Android, но и для iOS приложений, и которое, в итоге, вылилось в целый online-инструмент, о котором я расскажу в самом конце, когда станет очевиден его смысл. Часть написанного ниже была представлена на конференции ZeroNights и на страницах журнала «Хакер». (Т.к. материал не был опубликован онлайн, редакция дала на «добро», на публикацию здесь). Итак, поехали.

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

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

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

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

iOS 7 официально вышла в сентябре, тогда Apple предоставила разработчикам новый способ работы с сетью — NSURLSession. Это достаточно фундаментальная вещь, потому в случае необходимости поддержки iOS 6 и ниже, распараллеливать код относительно версии системы будет крайне проблематично. Но тем не менее, время идет, и уже сейчас по разным данным от 75 до 85 процентов пользователей перешло на последнюю iOS, потому я бы советовал попробовать NSURLSession уже в следующем проекте.

По замыслу Apple, NSURLSession должна сменить NSURLConnection, и тут действительно возникает вопрос: «а зачем все это надо?» Потому сразу плюсы по сравнению с NSURLConnection:

1. Загрузка и отправка данных в бэкграунде
2. Возможность останавливать и продолжать загрузку
3. Мы можем использовать блоки и делегаты одновременно, так, например, блоки используем для получения данных и обработки ошибок, а делегатный метод — для прохождения аутентификации
4. У сессии есть специальный конфигурационный контейнер, в который можно уложить все нужные свойства для всех тасков(запросов) в сессии, а также, например, хэдеры для всех запросов в сессии
5. Можно использовать приватное хранилище для куков, кэша и прочего
6. Получаем более строгий и структурированный код, в отличие от набора беспорядочных NSURLConnection

2 июня на конференции WWDC 2014 Apple представила новый объектно-ориентированный язык программирования — Swift. Я думаю, многие уже успели посмотреть, что из себя представляет этот язык (Swift — нововведения), поэтому я не буду останавливаться на нововведениях. Я предлагаю создать простенький проект на языке Swift, чтобы понять на деле основные отличия от привычного Obj-C.

Я — веб-разработчик с непрофильным образованием и ~10-летним стажем. Я делал для веба все, что только могло прийти в голову моим заказчикам и, иногда, начальству. Я люблю эту работу. Но все же есть несколько вещей, которые я делаю совсем не улыбаясь. Одна из них — это file uploader. From the very beginning — когда еще никому не приходило в голову делать его аяксовым — и до настоящего времени — когда он ресайзит картинки, загружает файлы в несколько потоков и многое-многое другое — он остается для меня одной из самых нелюбимых задач. Вроде как у меня получилось с этим справиться. Если интересно — добро пожаловать под кат.
Вас ждут немножко Coffeescript-а, совсем чуть-чуть жалоб на jQuery, краткое описание $.Deferred, один к месту и не к месту нечаянно примененный паттерн и отсылка к одной забавной и интересной книге.

Хочу поделиться нашей историей взаимодействия с Google Adsense. Начиная с их первого предупреждения и заканчивая отключением показов контекстной рекламы на darudar.org. Покажу, как мы решали озвученную перед нами проблему о недопустимости размещения рекламы рядом с «контентом для взрослых». А также хочу узнать, был ли у кого-то подобный опыт, что мы сделали неправильно, что ещё можно предпринять?

Эта статья о самых главных ошибках четырех backend разработчиков, которые решили заработать денег на приложении для iPhone не имея никакого опыта в разработке мобильных приложений и тем более их продвижении.

Все началось с того, что чуть более года назад мы собрались и решили написать небольшое, но полезное приложение. Небольшое, потому что опыта не было, а затягивать выпуск на неопределенный срок не хотелось. Полезное, чтоб каждый из нас хотел им пользоваться. Работать над приложением мы решили в свободное время. В результате долгих споров у нас появилась идея, которая устраивала всех.

Ошибка #1 — Идея

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

Вывод: в следующий раз сначала очень серьезный анализ рынка, потом поиск людей готовых купить идею, и только потом продукт.

Разработчики из компании Bonanza потратили более двух лет на создание программы для автоматического удаления фона с изображений. Задача оказалась гораздо сложнее, чем думали поначалу. Как оказалось, автоматическое удаление фона — одна из классических проблем компьютерного зрения, известная ещё с 80-х годов.

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

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

К тому же, время от времени нужно удалять устаревшие файлы сразу на всех серверах, что пока делается вручную и занимает несколько суток. Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

UPD: Как показала практика, необходимо ощутимое измение и дополние в тексте. Я решил внести лишь незначительные правки в основную часть, а новыми выводами поделиться в конце статьи.

Summary

Announced: 2010-05-20
Credits: 80sec
Affects: сайты на ngnix+php с возможностью загрузки файлов в директории с fastcgi_pass

Background

Зачастую How-To по настройке связки nginx с php-fpm / php-cgi есть подобные строчки:

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}