Леонид Каганов: дневник

Спасибо Кате и Билайну, у проекта для SMS-постингов будет такой номер:

+7-9XX-

618-0-819 bin-o-niq

.net

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

Я пока код там забил крестиком, потому что номера пока нет (как и модема), и слать на него ничего и даже звонить нельзя.

Плату GSM-модуля собрал Артем. Говорит, на днях будет. Не очень пока понимаю, сможет ли эта плата принимать MMS (и не придется ли тратить свое бабло, чтобы выкачать фотку, на заливку которой уже потратил свое бабло отправитель), но знакомые из Билайна сказали, что уже скоро (в декабре) заработает сайт с кабинетами пользователей, и можно будет настроить робота ходить за MMS туда.

Ну а пока суть да дело, поговорим про вопросы авторизации в проекте. Принципы:

1. Я считаю, что авторизация больше нужна проекту, а не пользователю. У платежных систем, скажем, наоборот. Но в веб-проектах именно так. «Приучайте своих пользователей чаще логиниться» — такие советы отметаются сразу. Авторизацию должен давать сервис, давать прозрачно для пользователя, и сделать все, чтобы она держалась как можно крепче — любыми средствами. Как минимум, чтобы френды не теряли подзамочные доступы, нарушителей (в массе своей малоквалифицированных) можно было проще банить, а на сервере велась статистика, что тот и этот комментарий действительно написан с одного и того же компьютера. Это данность, которую обсуждать бесполезно.

2. При этом безопасность должна быть на первом месте. Не должно возникнуть ситуации, когда авторизацию можно будет украсть. Вопрос взлома авторизации волнует меня куда больше вопросов взлома сервера — о них я позабочусь сам. При грамотном программировании на сервере не так уж много вариантов взлома, и все их можно заткнуть. Совсем другое дело с авторизацией на стороне пользователя: какие дыры появятся в каких браузерах завтра — над этим мы не властны. И какие способы могут открыться при разрешении использования тех или иных тегов — тоже заранее все предугадать нельзя. Поэтому задача: сделать авторизацию такой, чтобы даже временно внедренный злоумышленником javascript (пока не обнаружили и не заткнули дыру) не помог ее украсть и использовать. То же самое относится к flash и прочим объектам, выполняемым на стороне пользователя, открывшего страницу злоумышленника Васи Пупкина, создавшего ее в своем аккаунте на нашем проекте (вариант: Вася обманом заставил пользователя зайти на свой сторонний сайт и попытался скриптами украсть что-то; но вопросы фишинга и прочей социнженерии мы сейчас не рассматриваем, речь о чисто технических средствах).

Соответственно, я долго думал и пришел к таким выводам:

а) Следует использовать evercookie. Но для начала надо разобраться, какие из тех 10 методов можно выуживать со сторонних ресурсов, а какие браузеры отдадут строго родному домену и никому больше.

б) Авторизаций должно быть две: кука основная на основном домене binoniq.net — привязанная к IP. И кука запасная на вспомогательном «неуязвимом» домене (binoniq.ru или вообще по IP http://123.45.67.89), где нет никакого пользовательского контента. Под словом «кука» я подразумеваю не обязательно cookie, а некий ключ, который хранится на стороне пользователя любым из современных методов. Пока IP не сменился — работает авторизация основная. Если IP сменился — браузер отправится (по ajax или через iframe 1x1) на вспомогательный домен, где кука не привязана к IP, и тот вернет авторизацию для нового IP. Либо напрямую пользователю, либо через сервер — это я пока не придумал. В результате получается, что если враг завел на сервисе аккаунт, внедрив в свои страницы некий уязвимый (и неизвестный пока разработчикам) код, позволяющий воровать куки посетителей, то украденная кука окажется привязанной к IP конкретного посетителя, и воспользоваться ею враг не сможет.

В связи с выше изложенным у меня к вам следующие просьбы:

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

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

3. Мне нужна консультация по веб-безопасности от _грамотного_ специалиста. В комментах, по аське или телефону. Есть специалисты, готовы потратить 10 минут времени? В частности, интересуют такие вопросы:

— Комментарии по evercookie и его методам. Мне там пока много неясно, особенно с Etag и картинками;

— Политика разграничения доступа у разных браузеров: какие данные на стороне клиента (флэшкуки, куки, хранилища) браузер готов отдать только родному сайту pupkin.ru, а какие можно у него «выпросить» скриптами, заманив на сайт pupkin.com;

— iframe и политика браузеров по работе с ним. Что может получить страница родитель от своего iframe? Что может передать iframe странице-родителю? В случае родного сайта? В случае разных сайтов? И главное — каково реальное поведение разных браузеров, я не поверю, что все они ведут себя по спецификациям — я когда-то экспериментировал с обычными cookie и даже там сталкивался с дикими разночтениями даже в вопросах области действия cookie (некоторые отдавали куки с lleo.aha.ru на верхний домен mat.lleo.aha.ru, некоторые нет).

PS: Прошу учесть, что я не умею читать на иностранных языках.