Некоторые мысли, навеянные изучением игры Zynga Poker (номер один приложение в AppStore по In-App покупкам)

• Реализуем какую-нибудь известную оффлайновую игру, достаточно простую и азартную, как Texas HoldEm покер. Эту игру многие знают - низкий порог вхождения. Азартность - чтобы люди играли помногу и возвращались. Игра не должна прекращаться, если один из игроков отвалится из-за плохой связи. Одна игра не должна длиться слишком долго.
• Простота игры позволит написать множество клиентов под разные платформы, основное действо происходит на сервере.
• Качество приложений не играет такую уж большую роль, если играть интересно и всегда есть с кем. Я пощупал клиенты под iPhone, iPad и приложение для Facebook. Самое удобное и приятное приложение для iPad. Приложение для Facebook перегружено ненужной информацией и рекламой других игр. Приложению под iPhone явно не хватает места на экране, из-за этого меняется назначение кнопок во время игры и получается не очень удобно.
• Авторизация только через Facebook - чтобы спамить друзей. Собственно спамить необязательно, но игра это поощряет плюс некоторые дополнительные плюшки можно заработать только вовлекая друзей.
• На входе дают определенную сумму виртуальных денег. Если проигрался и хочется играть еще - можно вовлекать друзей или купить фишек внутри игры. Стоят фишки недорого, минимальный пакет стоит 99 центов.
• Подумали и о тех, кто проигрался полностью, но тратить деньги не хочет. Время от времени присылают в подарок небольшой набор фишек, чтобы можно еще поиграть и не соскочить с крючка.
• Обычные социальные моменты - можно общаться за столом, угощать виртуальными напитками, подсаживаться со стол к друзьям итд.
• Пузомерки - рейтинги, турниры, достижения, уровни.

Как видно, ничего технически сложного в этом нет. Все остальное это маркетинг, вовлечение как можно большего числа пользователей.

Тут сразу подумалось, у каких традиционных русских игр есть шанс выйти на такое количество пользователей. Преферанс слишком академичен, игра интеллигенции. Мафия, на мой взгляд, интересна именно для игры в кругу друзей, кроме того нельзя терять игроков из-за дисконнекта. Шахматы - слишком сложно и любитель никогда не обыграет профессионала. Игра в слова (составлять слова из букв большого слова) на время может быть интересна. Эрудит - тоже неплохой вариант, у той же Zynga есть достаточно популярный WordsWithFriends. С покером, конечно, не сравнится, но тоже довольно азартно. Какие еще есть варианты?

Это совершенно удивительная страна, небольшая, уютная, зеленая. Там мало деревьев, но трава и мох растут повсюду. Там горы, скалы, океан и свежий вохдух. Там вкусное пиво и простая еда. Там мало людей, но они всегда рады гостям и туристам. Там размеры населенных пунктов измеряют в пабах (один паб на каждые 80-100 жителей вне крупных городов) . В самих пабах уютная атмосфера и играет живая музыка.  Там нет нет номеров домов, только названия. А зачем, почтальон и так всех знает. Там узкие дороги, вместо обочин живая изгородь или каменная оградка. Там растет вереск и гуляют фазаны. Там здорово.

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

Взять обычное авторадио. Я люблю видеть, как называется текущая песня и кто ее исполняет. Вот как выглядит этот экран в Audi Q7. Название песни неспешно прокручивается вместе с названием радиостанции и исполнителем в маленьком окошке.

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

А вот как оно вышлядит на панели Mini Couper.

Там все все две строки информации, но можно прокрутить и поставить как тебе надо.

Удобно, практично. Казалось бы мелочь, но продукт и состоит из множества таких мелочей.

Компания Б является в какой-то мере конкурентом компании А, но продукты у нее слабенькие и работает она в другом ценовом диапазоне. Продукты обновляются нечасто, затрат на поддержание бизнеса почти нет, техподдержки минимум, типичный бизнес программиста одиночки. Основной актив компании Б - хорошее положение в поисковых системах по важным для нашей индустрии фразам таким как "web databases", "database software" и "mysql software". Эти позиции они держат давно, можно предположить, что никакого черного SEO там не замешано и как минимум еще какое-то время эти позиции сохранятся.

Вопрос: за какую сумму (в размерах годового оборота компании Б) компании А стоит ее покупать? В случае покупки, как правильно монетизировать этот актив? Нужно заметить, что компанию Б устраивает положение дел и продаться она будет готова только за достойную, по ее мнению, цену.

Варианты отбить потраченные деньги

Ну и просто навскидку несколько вариантов:

1. Пассивный.  Просто  сидеть и собирать денежку. Через какое-то время потраченное деньги вернутся и дальше начнется прибыль. Есть риск, что срок возврата можеят затянуться.
2. Пытаться  апгрейдить  его  пользователей  на наши продукты. Что-то получится  конечно,  но  цену  на апгрейд придется  дать  им  очень  хорошую, его продукты  дешевле в 6-7 раз.  Плюс придется что-то писать дополнительное для импорта существующих продуктов.
3. Рекламировать   на   его   сайте   наши   продукты. Будет  часть дополнительных  покупок,  хотя  это можт повлиять на продажи его продуктов. Сильно менять  его  вебсайт  не  хочется, можно испортить хорошее положение в поисковых системах.
4. Развивать его продукты смысла особого нет, там полный тупик.
5. Варианты  поиграться  ценой его продуктов,  поднять или повысить. Может принести успех, а может и не принести. Возможно он уже такое делал и остановился на отпимальной цене.
6. Постепенно заменить его продукт нашим. Можно сильно облегченный/домохозяечный вариант нашего софта, обозвать его PHPMagic (его продукт) и продавать.

Какие еще варианты вы видите? На каких условиях вы купили бы компанию Б?

UPD: владелец websitedatabases.com таки выставил его на продажу на Flippa. Там же можно посмотреть сколько он зарабатывает.

У айтишной компании если несколько вариантов развития:

1. ничего не получилось - закрываемся
2. остаемся маленькими и успешными (37Signals, FogCreek)
3. вырастаем  и продаемся другой компании (их много)
4. вырастаем и сами всех скупаем на корню (Google, Facebook, Adobe, Microsoft)

Грань между вариантами 3 и 4 довольно тонка. Не всегда легко оценить размер рынка и возможности дальнейшего роста. Большинство успешных компаний доходит до третьего уровня и поглощается лидерами рынка.

Сценарий: вы основали айтишную компанию, которая успешно растет, набирает работников и клиентов, возможно прошли один или два раунда финансирования. Вы любите свое дело, своих клиентов и с оптимизмом смотрите вперед. В один прекрасный день приходит письмо от CEO компании, являющейся в вашей индустрии признаным лидером. Ура, они хотят вас купить! В процессе переговоров выясняется один нюанс - их больше всего интересует не ваши технологии и не ваши миллионы пользователей. Им нужна ваша талантливая команда инженеров.

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

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

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

Добрый день!
Mы рады сообщить, что бета-версия нового Product X доступна для скачивания.
Product X воплотил в себе весь опыт компании Y как в создании решений для собственной ИТ-инфраструктуры организаций, так и в построении и управлении публичными облачными сервисами. Product X является легко масштабируемой, простой и экономически эффективной серверной платформой для построения собственной серверной инфраструктуры организации, включая частное облако, а так же гибкой и безопасной ее интеграции с публичными облачными сервисами. Product X – это:

• Больше, чем просто виртуализация
• Возможности множества сервисов, простота одного инструмента
• Любое приложение на любой платформе
• Новый стиль работы

Попробуйте Product X уже сегодня в бета-версии!

Угадали? Не сомневаюсь.

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

Все идем сюда и учится представлять новые товары просто и со вкусом.

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

Пердставьте себе ситуацию - в IT отделе крупной компании поздним вечером в субботу раздается звонок. Сотрудник X, находящийся на выставке в Лас-Вегасе, не может скачать важную презентацию компанейского сервера. Без этой презентации завтрашний день можно считать потерянным. Ваша компания использует двухфакторную аутентификацию с помощью RSA брелока, но сотрудник X забыл его на работе. Сотрудник X знает свой логин и пароль, свой Employee ID, имена боссов и других сотрудников, названия проектов над которыми он работает.

Дежурный работник IT отдела в затруднении. Он советуется со своим начальником, но тот тоже не знает что делать. Звонить вице-президенту компании среди ночи тоже не хочется. Становится тем человеком, который сорвал презентацию тоже не хочется. Скрепя сердце они дают сотруднику полный доступ. Нужно ли говорить, что за сотрудником X скрывается хакер, который провел большую подготовительную работу, выяснил логин/пароль одного из сотрудников, выучил внутреннюю организацию компании итд. Любое проникновение - это всегда многоходовка, умный хакер не будет ломиться сразу на главный сервер компании.

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

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

И тут появляется хакер, которому очень интересно, что такого вы прячете на сервере. Атака в лоб не принесла успехи, вы увидели следы в логах и только улыбнулись. Но хакер попался непростой, ранее он взломал компанию вендора вашей операционной системы, которая крутится на ваших серверах, получив доступ к исходным кодам системы и, что еще более важно, к базе данных секьюрити уязвимостей найденных в системе. Хакер проникает на ваш сервер, скачивает что ему было нужно и подчищает за собой логи. Ваш сон не потревожен. Вы, может быть, узнаете о взломе из газет, когда хакера поймают (если поймают).

Типичный баг репорт из базы данных Sun:

Synopsis: syslog can be used to overwrite any system file
Keywords: security, password, syslog, overwrite, system
Severity: 1
Priority: 1
Responsible Manager: kwd
Description:
syslog and syslogd feature of LOG_USER can be used to overwrite *any* system file. The obvious security violation is using syslog to overwrite /etc/passwd. This can be done to remote systems if LOGHOST is not set to localhost.
bpowell: breakin code removed for security reason
If you need a copy of the breakin code see Staci Way (contractor) (staciw@castello.corp).
Work around: NONE except turning off syslog which is unacceptable
Interest list: brad.powell@corp, dan.farmer@corp, mark.graff@Corp
Comments: this one is pretty serious. It has already been used on sun-barr to break root, and is one of the few security bugs that work for 4.1.X as well as 2.X e.g. ANY Sun released OS.


Конечно же, Кевин напишет упомянутой в репорте Staci Way с внутреннего аккаунта Sun и выманит у нее нужный код.

И таких историй там десятки. Неудивительно, что Митником заинтересовалась FBI. Он скрывался от них более трех лет, меняя номер своего мобильного по своему желанию, поменяв несколько раз имя. Самое главное, что он не мог удержаться от проникновения в сети все новых и новых компаний. В конце концов это и привело к его поимке.

Ему удавалось скрываться до тех пор, пока он не проник на компьютер другого хакера, чем сильно расстроил последнего. Объединив усилия с FBI хакер сумел проследить за Митником и спустя некоторое время FBI удалось его задержать. После четырех лет в тюрьме Митник вышел белым и пушистым. Работает консультантом в области компьютерной секьюрити, выступает с докладами, уважаем обществом.

Могу так же посоветовать его же Art of Deception (Искусство вторжения). Там собраны истории проникновения, совершенные другими хакерами и записанные Митником. Тоже довольно интересно, но не хватает общей связующей нити.

На прошедших выходных перестала работать часть сервисов компании Digital River. Для тех кто не в теме - Digital River объединила под своей крышей множество компаний занимающихся приемом оплаты по кредитным картам в онлайне. Им принадлежат RegNow, RegSoft, SWREG, ShareIt, DigiBuy и с десяток других, о которых уже все забыли. Больше других досталось SWREG, который был в дауне 36 часов.

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

Какие из этого следуют выводы:

1. SWREG делает бэкапы, потери данных не было

2. Плана Б у SWREG нет

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

Для решения этой задачи мы используем выделенные сервера, но на них крутятся виртуальные машины, так проще переносить с сервера на сервер.

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

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

Для дополнительной надежности стоит сервера держать в разных датацентрах. Я пока этого не делаю, слишком мне нравится мой провадйер Hivelocity.

Интересна реакция Digital River на это проишествие. Обычно с ними не так просто связаться в случае каких-то проблем, скажем на сайте SWREG нет в принипе никаких телефонов. Сейчас они опубликовали сразу кучу способов связаться с ними через Twitter, Facebook, LinkedIn и Google+. Помимо этого они дают вендорам один месяц бесплатного сервиса в апреле (у SWREG это 4.5% от суммы продаж). Пустячок, а приятно.

Что еще забавно, один из немногих оставшихся независимых e-commerce провадйеров в нашей индустрии, CleverBridge, тут же разослал письмо счастья клиентам DigitalRiver, предлагая перейти к ним. Как раз тот случай, когда можно оправдать спам.

Все идем работать над планом Б.

1. Вы проверяете число продаж перед тем как ложиться спать и перед завтраком

2. Вы измеряете цену вещей (машина, квартира, игровая приставка) в количестве лицензий программы, которые нужно продать

3. Вы отдаете на аутсоурсинг работу кому-то, кого никогда не видели и понятие не имеете где он живет

4. Заказывая гостиницу вас больше интересует хороший ли там интеренет, чем качество кухни

5. Ваш продукт получил минимум 20 пятизвездочных наград на софтовых архивах

6. Вы знаете, что такое CTR, CPC и CPM.

7. Вы упрашивали друзей и родственников проголосовать за страничку вашего продукта на Facebook.

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

9. Вашу программу взламывали как минимум один раз

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

11. Вы отвечали на письма в поддержку сидя перед компьтером в одних трусах

12. Вы настроили уведомления в Гугле и Твитере на каждое новое упоминание вашго продукта

13. Вас начинает колбасить если вы не проверяли почту несколькоч часов

14. Последний раз вы ставили будильник, когда собирались в отпуск и боялись пропустить самолет

15. Ваши родственники считают что у вас нет "настоящей работы"

16. Вы владете минимум десятком доменов

17. Вам приходилось устранять ошибки в вашей программе или на вебсайте в то время как вы были в отпуске на отдыхе

18. У вас был как минимум один чаржбэк

19. На вашу программу ругался как минимум один антивирус

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

21. Вам приходилось отвечать людям на вопрос "И тебе удается зарабатывать на жизнь этим?"

22. Вам приходилось отвечать на вопрос в техподдержку на языке, которого вы не знаете при помощи Google Translate

23. Вы говорите о свой компании "мы", даже если работаете в одиночку

24. К вам прибегал кто-то с блестящей идеей, обещая дать 50% от прибыли, если вы на 100% реализуете ее самостоятельно

25. Последний раз вы носили костюм с галстуком на свадьбе или похоронах

Если вы набрали 20 и более очков - вы настоящий шароварщик.

Оригинал на английском за авторством Энди Брайса

Ничто меня не бесит так, как автореспондеры. После каждой рассылки насыпается пара сотен автоматических ответов. Я получил ваше письмо, я не получил, но получу и прочту, меня нет на месте, наш специалист свяжется с вами, я в отпуске, я родил малыша, я уволился. Да кому какое дело, что там у тебя. Не о тебе речь вообще.

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

1. Джерри и Адриана

Джерри - разработчик приложений для iPhone. Путешествует с женой Адрианой, работает откуда придется и у него это неплохо получается.

2. The Unstoppable family

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

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

Зарабатывают они на жизнь какой-то мутной ерундой типа MLM, но в остальном интересно почитать.

3. Аджей и Маша

Профессиональные трэвеливеры, в путешествии уже несколько лет. Сдают квартиру в Москве, немного подрабатывают фрилансерством и блогом. Путешествуют по Юго-Восточной Азии. Пишут интересно.

4. Другая жизнь

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

Рекомендую почитать про восхождение на Килиманджаро, впечатляет.

5. Shooow me

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

А что тебе не дает сорваться с места прямо сейчас?

Размышлизмы, навеянные рассылками по клиентской базе.

1. Распродажи аля Groupon работают

Спасибо Групону, народ привык покупать всякую малонужную ерунду со значительной скидкой в надежде когда-нибудь воспользоваться ей. Рецепт: возьмите пару-тройку своих продуктов, которые продаются слабо,  объедините их в бандл, сделайте скидку процентов 60-80 и сделайте рассылку по списку клиентов. Для убедительности ограничьте срок действия распродажи и повесьте часы с обратным отсчетом.

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

2. Повторенье - мать ученья

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

3. Как понимать клиентов.

Это самое интересное. Разговор с клиентом больше всего напоминает общение с женщиной. Думает одно, говорит другое, а ожидает от тебя третьего.

Клиент говорит: хочу чтобы было такое место, где люди могут обмениваться своими шаблонами.

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

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

Чтобы подстегнуть процесс создания иобмена стилями запустили конкурс. Нужно сделать свой стиль и прислать его нам. Сроку дали десять дней. Десять лучших стилей получают по 100 долларов каждый. В принципе не так плохо за пару часов работы.

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

Удачных вам рассылок!

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

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

Нужно купить и сделать самому большой настенный календарь на целый год и повесить его на видном месте. Вооружиться большим красным маркером.

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

"Не разорви цепочку", повторил он еще раз.

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

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

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

Не разорви цепочку!

Источник: Lifehacker

------------------------------

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

Ссылки

Печально известный финансовый стартап Wesabe выложил исходники своего парсера сайтов банков и других финансовых организаций на Github. Вот тут немного дополнительной информации и обсуждение.

------------------------

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

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

1. SQL injection

Допустим у вас есть вебсайт с формой ввода имени пользователя. Для проверки наличия имени в базе данных  вы используте вот такой код:

$query = "SELECT * FROM `Users` WHERE UserName='" . $_POST["Username"]. "'";
mysql_query($query);

где $_POST["Username"] - введенное пользователем имя.

Пользователю достаточно ввести вот такое значение в поле Username

' or '1'='1

чтобы получился запрос, который всегда возвращает данные:

SELECT * FROM `Users` WHERE UserName = '' OR '1'='1'

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

Пример такого ввода:

a';DROP TABLE `Users`; SELECT * FROM `userinfo` WHERE 't' = 't

Запрос на выходе:

SELECT * FROM `Users` WHERE `UserName` = 'a';DROP TABLE `Users`; SELECT * FROM `userinfo` WHERE 't' = 't'

Два основных способа избежать SQL injection:

• параметризованные запросы

Наиболее надежный метод, но не всегда подходит. В PHP можно для этой цели использовать MySQLi

$stmt = $db->prepare('update people set name = ? where id = ?');
$stmt->bind_param('si',$name,$id);
$stmt->execute();

• escaping

В PHP для этого есть функция mysql_real_escape_string, которая заменит опасные символы на escape последовательности. Наш пример теперь будет выглядеть вот так:

$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s'",
                  mysql_real_escape_string($_POST["Username"]));
mysql_query($query);
 

2. Сross Site Scripting (XSS)

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

Чем может навредить безобидный джаваскрипт? Довольно многим, от открытие левых сайтов в попапе или простого завешивания браузера до воровства куки. Последнее уже может привести к выполнению другим пользователем действий на этом сайте от вашего имени. Рассмотрим минимальный пример.

Форма для ввода текста:

 
<form id="myFrom" action="showResults.php" method="post">
<div><textarea name="myText" rows="4" cols="30"></textarea>
<input type="submit" value="Submit" name="submit" /></div>
</form>
 

Файл showResults.php:

echo("You typed this:");
echo($_POST['myText']);

Мы видим, что введенный текст никак не обрабатывается и выводится на страницу в исходном виде. Теперь рассмотрим такой пример ввода:

<script type="text/javascript">myRef = window.open('http://www.google.com','mywin',
'left=20,top=20,width=700,height=500,toolbar=1,resizable=0');</script>

Нетрудно видеть, что javascript код исполнится после сабмита формы. Лечится пропусканием ввода через htmlentities() непосредственно перед показом:

echo("You typed this:");
echo(htmlentities($_POST['myText']));

3. Использование HTTPS

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

4. Предотвращения скачивания пользовательских файлов по прямой ссылке

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

Есть закачивать все файлы в директорию вида public_html/files, то файл mysecretdoc.pdf будет доступен любому желающему по прямой ссылке http://mysecurewebsite.com/files/mysecretdoc.pdf.

Есть как минимум два способа предотвратить эту ситуацию:

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

5. Пароли пользователей

- Не хранить пароли открытым текстом

Достаточно очевидное решение. Если мы будем хранить хэши паролей (MD5+salt), последстивия утечки таблицы паролей становятся намного менее серьезными, особенно в сочетании со следующим пунктом.

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

- Использовать комбинацию пароля (пин-кода) и устройства типа RSA токена для логина. Подойдет для банковских или внутрикорпоративных приложений.

- Сделать авторизацию через сторонний сервис, такой как Facebook, Twitter или OpenID. Пусть у них болит голова как уберечь пароли.

6. Шифрование и обфускация кода

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

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

Шифрование кода для PHP: ionCube, ZendGuard, SourceGuardian

Обфускация: Thicket Obfuscator for PHP

7. Шифрование данных

Шифрование данных защищает от ситуации, когда база данных попала в чужие руки, но нет кода, который с ней работает.

Технически ничего сложного здесь нет. Шифрование/декодирование можно реализвать как средствами языка программирования так и в самой БД. Второй метод предпочтительнее, особенно если нужно реализовать поиск по зашифрованным данным.

Вот как это можно сделать для MySQL.

Шифрование с помощью триггеров

delimiter |
 
CREATE TRIGGER insert_encrypt BEFORE INSERT ON cars
  FOR EACH ROW BEGIN
    SET NEW.Model = AES_ENCRYPT(NEW.Model,"my passphrase");
  END;
|
 
delimiter |
 
CREATE TRIGGER update_encrypt BEFORE UPDATE ON cars
  FOR EACH ROW BEGIN
    SET NEW.Model = AES_ENCRYPT(NEW.Model,"my passphrase");
  END;
|

Декодирование в SQL запросе

SELECT
...
AES_DECRYPT(Model,"my passphrase"),
...
FROM carscars

Бонус для параноиков

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

Из минусов:
- при смене пароля придется перешифровать данные
- в случае утери пароля восстановить данные не получится

8. Защита данных сессии (PHP, shared server)

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

Содержание типичного файла сессии PHP:

userName|s:5:"admin";accountNumber|s:9:"123456789";

Решение:
- шифровать переменные сессии
- хранить данные сессии в БД. В PHP можно переопределить обработчик сессии с помощью функции session_set_save_handler

9. Отключите показ сообщений об ошибках

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

Как минимум, сообщения об ошибках стоит отключить. В PHP это можно сделать вот так:

error_reporting(0);
@ini_set('display_errors', 0);

Наиболее же правильный метод это перехват сообщений об ошибке, запись их в БД, отправка уведомления разработчику итд. В PHP перехват сообщений об шибках делается с помощью функции set_error_handler(). И вот еще пример перехвата фатальных ошибок, которые нельзя перехватить с помощью set_error_handler().

10. Защитите соединение между базой данных и приложением

Применимо к ситуации когда база данных расположена на другом сервере. Вот статья, которая рассказывает как создать SSL тоннель между MySQL и PHP.

11. Защита от form spoofing

Допустим у вас есть форма редактирования данных пользователя вот с таким УРЛ: http://example.com/edit_user.php?id=12345. Ничто не мешает пользователю 12345 поменять номер аккаунта в УРЛ и попытаться отредактировать другого пользователя. Простая проверка на стороне сервера пресекает эти попытки на корню.

Неискушенный прграммист может подумать, что заменив GET на POST мы избавимся от номеров аккаунтов в УРЛ и закроем уязвимость. Разумеется это не так. Сохранив страницу на свой компьютер и изменив данные формы, злоумышленник может подделать POST запрос.

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

Эта тема плотно перекликается с валидацией всех данных, вводимых пользователем. Допустим у вас есть радио-кнопка с выбором пола.

 
<input name="gender" type="radio" value="m" />Male
<input name="gender" type="radio" value="f" />Female

Зная, что значение этого поля может быть только m или f, программист может посчитать проверку этого поля необязательным и записать его в базу данных в виде как оно есть.

Злоумышленник может сохранить эту страницу себе на диск и поменять ее следующим образом.

 
<input name="gender" type="text" value="m';DROP TABLE `Users`; ... " />

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

Хорошим решением будет усечение этого поля до одного символа:

substr($_POST['gender'],0,1)

12. Cross-site request forgery (CSRF)

Эта уязвимость менее известна чем XSS, хотя не менее опасна. Представим себе форум, где участник Vasya постит сообщние, содержащее вот такой вот код:

<img src="http://mysecurebank.com/withdraw?account=petya&amp;amount=1000000&amp;for=vasya" />

Когда эту страницу откроет участник Petya, браузер исполнит запрос

http://mysecurebank.com/withdraw?account=petya&amount=1000000&for=vasya

Проблема в том, что если банк хранит данные доступа в куках, Petya будет залогинен автоматически и транзакция совершится от его имени, о чем он, конечно, и не подозревает.

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

 
<form id="f" action="http://mysecurebank.com/withdraw" method="post">
<input name="account" value="petya" />
<input name="amount" value="1000000" />
<input name="for" value="vasya" />
    </form>
 

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

Как с этим бороться?

• проверять значение HTTP реферера. Должно быть всегда с вашего собственного вебсайта. К сожалению положиться на это дело полностбю нельзя, так как многие прокси сервера могут его не передавать. К тому же его не так сложно подделать.
• использовать скрытое поле в форме с секретным значением, как правило привязанным к сессии пользователя. Злоумышленник не может прочитать форму от имени Пети, поэтому секретное значение окажется для него неизвестным (XmlHttpRequest не может выполнить запрос к другому серверу).
• Дополнительно отправлять куки через форму (прочитать с помощью джаваскрипта и вставить в форму). Если куки переданные через форму не совпадают с куками из заголовка - транзакцию не проводить.
• Ограничение времени жизни кук

Дополнительная информация:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
http://www.codinghorror.com/blog/2008/09/cross-site-request-forgeries-and-you.html

Заключение

Теперь хорошие новости. От большинства этих уязвимостей несложно защититься. Многие PHP фреймворки (Yii, CakePHP, CodeIgniter, Zend, Symfony) и генераторы кода (PHPRunner) имеют встроенную защиту от большиства уязвимостей. Тем не менее, стоит понимать, как оно работает, чем чревато и как защититься. Предупрежден - значит вооружен.

Сокращенный перевод статьи Марка Хедлунда, основателя Wesabe. Оригинал здесь.

Оба вебсайта предоставляли сервис управления персональными финансами. Были запущены примерно в одно и то же время (2006-2007 год). Mint был куплен Intuit в сентябре 2009 года за 170 миллионов долларов. Wesabe закрылся в июне 2010 года.

Почему так произошло? Дальше от лица Марка Хедлунда.

--------------------------------------------

Прежде всего развеем несколько мифов.

1. Mint победил, потому что был запущен раньше

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

2. Wesabe никогда не зарабатывал денег

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

3. У Mint было лучше название и лучше дизайн

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

4. Wesabe не был "вирусным", а Mint был

Наполовину верно. По-большому счету ни тот ни другой продукт не был вирусным. Mint в основном приобретал новых пользователей посредством Google Adwords (есть цифры, что привлечение каждого нового пользователя обходился им в 1 доллар). На графике видно, что трафик перестал расти сразу после их приобретения в сентябре 2009 и не рос 6 месяцев. Очевидно, что рост связан с размерами маркетингового бюджета, а не с вирусным распространением.

Кликабельно.

Хорошо, почему же тогда Mint добился такого успеха, а Wesabe нет? Я вижу две основные причины.

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

Mint же не побоялся и использовал Yodlee для получения пользовательских данных напрямую с банковских сайтов (Yodlee разработал парсер для каждого отдельного банка). Это дало возможность предоставить клиентам более понятный и удобный сервис. Wesabe решил построить свою собственную систему получения данных из банков, но это заняло время и они сумели сделать похожую функциональность только через 6 месяцев после того, как она появилась и Mint.

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

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

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

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

Может у 4х конвертов это получится?