логин: 
<< предыдущая заметкаследующая заметка >>
22 ноября 2010
binoniq - SMS

Спасибо Кате и Билайну, у проекта для 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: Прошу учесть, что я не умею читать на иностранных языках.

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
архив понравившихся мне ссылок
Оставить комментарий
Windows Safari Chrome
1
0
1) Как известно прочность всей цепи зависит от того насколько часто ее будут дергать, выходя из кабинки самого слабого звена. В связи с этим вопрос — не получается ли, что вы облегчается задачу гипотетическому злоумышленнику, предлагая на выбор сломать любое из нескольких хранилищ? (Я не специалист по evercookie, и только из этого поста узнал о нем)

2) Насколько я понял, «куки» основная и запасная будут разные, но по запасной куке, не защищенной привязкой к адресу, некий дополнительный «неукокошиваемый» сервер (кстати, в чем его неуязвимость, в отличии от основного?) без базара отдает новую куку для основного сервера?
В этом случае мне представляется, что посетители некоего клуба носят с собой серьезные такие пропуска на гербовой бумаге, с фотографиями, которые предъявляют суровому охраннику на входе этого клуба. Однако еще они таскают с собой простенькую бумажку с паролем, которую можно предъявить вкупе со своей фотографией 3х4 бабке, сидящей на заднем дворе, она сверит эту бумажку с толстой книгой выданных ранее паролей, и по-пырому наклеит фотку на новый гербовый бланк, после чего он будет официально действителен для вышеназванного мордоворота.
Злоумышленнику ничего не даст похищение пропуска, так как на нем не его фото, но вполне достаточно спиздить бумажку и получить новый пропуск. Не?

3) Как вы планируете, не компрометируя прекрасную (и частично реализованную у вас на сайте) идею аутентификации пользователя, которая его не напрягает, и вообще, большую часть времени для него прозрачна, позволить ему работать с рабочих станций не персонального пользования (интернет-кафе, компьютерные классы в школах/ПТУ/универах, а зачастую, и офисные компьютеры). В таких местах пользователь может забыть выполнить выход из системы, что позволит следующему пользователю беспрепятственно войти от его имени. Планируется какая-то стандартная галочка "не запоминать меня на этом компутере"?

===
оффтоп: пока не известно по 18 дек. - Новосибирск? У нас еще есть шансы?

===
зы: резервное сохранение "черновика" набиваемого поста - прекрасно! оно спасло сейчас много моих нервов :-)
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Отличие основного сервера от запасного в том, что запасной сервер не может содержать чужого (хоть и "очищенного") контента. Соответственно нет способа вытянуть из браузера куки этого домена. Разработчики браузеров не идиоты, там есть строгая политика. Есть конечно люди, которые принципов не понимают, от них я часто слышу типа "как Лео отгадал, что я в ЖЖ Pupkin? Да он просто на своем сайте читает куки ЖЖ..." Это смешно конечно - не существует способа читать чужие куки.
Windows Safari Chrome
0
0
В чем отличие резервного сервера понял — он заведомо не захвачен врагами
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Пример: в ЖЖ лет 5 назад прокатилась повальная волна взломов. Выяснилось, что IE6 и некоторые IE7 могут открыть специальную картинку .png не как картинку, а как скрипт. Поскольку картинки (юзерпики) лежат в ЖЖ на том же домене, где и куки авторизации, это была катастрофа. После этого в ЖЖ спешно меняли всю систему авторизации, и сейчас она крива до невозможности (для тех, кто в курсе, как она работает изнутри).

Вопрос: кто даст гарантию, что завтра не откроется похожая дырка в IE8?
Windows Safari Chrome
0
0
Ну так вот поводу того, что куки в принципе нельзя своровать, не кажется ли, что это как раз немного противоречит такому опыту и фразе «какие дыры появятся в каких браузерах завтра — над этим мы не властны. И какие способы могут открыться при разрешении использования тех или иных тегов — тоже заранее все предугадать нельзя»? :-)
А по поводу ЖЖ - да, остроумно, но сколько уже раз народ писал что мол "да нет, я вовсе не он, а просто зашел по ссылке, читая его журнал" :-)
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Дружище, если выяснится, что куки чужих доменов можно воровать, то это уже будет не моя проблема. Это будет проблема всего мира и всего интернета. Я-то как раз пострадаю меньше всех на общем фоне - у меня есть солидный опыт работы и с флеш-куками, и с куками браузерных хранилищ, и я просто сброшу всем авторизацию, предложив набрать пароль заново, а сам переведу движок на другие куки за полчаса - все схемы и процедуры в нем есть и давно отлажены. А вот что будет делать остальной интернет от фейсбуков до одноклассников - даже подумать страшно ;)
Windows Safari Chrome
0
0
Ну да, согласен
Windows IE
0
0
D.iK.iJ
Обычно самое удобное что пока встречал - это авторизация в онлайн магазинах типа Озона. Сервер практически всегда тебя узнает, но для серьезных действий (особенно после смены IP) просит логиниться заново.
Не знаю, уместно ли это будет в данном случае.

Второе что встречал из удобного - сохраняемые на ПК ключи от Webmoney.

P.S. Про Iframe в статьях о взломе уже давненько пишут что отдаются все свойства, но только для данного домена.
Windows
0
0
lesha (#406942)
Недавно читал про исследование (не спрашивай как его провели) по результатам которого выяснили, что много пользователей используют один и тот же логин и пароль на разных сервисах.
Это прикольно, пока не понимаешь что какой-то абв-мейл фактически может зайти на любой сайт под многими пользователями. В том числе и на этот, как бы сильно он не был защищен :)
Хотя это уже проблема пользователей и ее не решить.

По поводу современных идей авторизации - есть клиентские ssl сертификаты. Но это не удобно и не катит с т.з. "оно нужно проекту, а не пользователю". Зато надежно.

Про отдельный сервер без контента - красиво. Лучше на него ssl навесить для защиты от перехвата в wifi сетях и т.п.

А как будет решаться ситуация с комп+мобилка? каждый раз выдаваться новый куки когда переключаешься с одного на другое? Если ip будет меняться часто, то все это становится похоже на независимый openid сервер :)
Nokia-E90 Safari
 Москва
1
0
Leonid Kaganov
Тут сразу надо разграничить область ответственности: беспечное хранение паролей, стикеры на мониторе, подлости соседей-квартирантов, вирусы и трояны Виндоус, несложившаяся половая жизнь и прочие проблемы пользователей - все это не моя зона ответственности и решать подобные вопросы в своем движке я не готов.

Про ssl я мало что знаю и никогда с ним не работал. Но если это то суровое парткомовское окнище, которое периодически выскакивает на говносайтах всяких банков и говорит что-то типа "Вы уверены, что хотите на время разрешить сертификат для этого недостойного сайта?" - то это настолько не наш метод и настолько здесь не в кассу, что даже обсуждать нет смысла.
Windows
1
0
lesha (#406942)
Это из той же серии, но совсем не то.
То окно - это подтверждение что сервер тот, за кого себя выдает. А есть еще механизм, который подтверждает что клиент тот, за кого себя выдает. Серверу, как понимаешь, никаких окон не показывают - если что-то не так пользователь сразу считается "не тем" и блокируется доступ без варианта "пустить на время" ;)

Ключ из 128 символов лучше чем пароль. На стикер его уже не приклеешь :) Но технология мутная, если не в курсе то сейчас точно не будешь разбираться. И для пользователя, Имхо, не вполне очевидная. Хотя есть нормальные реализации (у https://www.myopenid.com/signup например).
Evercookie - это гадость, причём небезопасная.

— Сгенерированные и закэшированные PNG может невозбранно взять любой сайт Сети. Либо угадать адрес, либо целенаправленно поставить.
— Использовать window.name для проверки авторизации будет только идиот.
— HTML 5 Global Storage в Firefox 2 реализован криво и доступен также вышестоящим доменам. Вообще, Global Storage из спецификации был удалён, вместо него теперь Local Storage.

Ну и в любом случае стоит помнить, что на следующий день может выйти новый IE, продемонстрировать новый комплект дыр и радостно отдать весь набор кук левому сайту.

Также сценарий «Злые люди перехватили соединение и спокойно украли авторизацию» вполне реален, если не используется SSL (TLS) и достаточно сильное шифрование куков. Ещё есть сценарий «На компьютер попал злой вирус и украл все мои куки», хотя это намного меньше вероятно.

SSL — это хорошо, но платить за сертификат глупо. У вас же не банк. Сертификат стоит чертовски дорого. Для безопасности достаточно взять самоподписанный сертификат — но тогда браузер клиента будет паниковать и ударяться в предупреждения: „Вы действительно хотите зайти на этот сайт, к сертификату нет доверия, мы все умрём!!!”

Из экстравагантных методов есть ещё сертификаты, как у Webmoney. Но они хранятся не просто на одном компьютере, а ещё и на одном браузере (конкретно Огнелис), так что — не прокатит.
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Разумеется, я не буду использовать еверкуки как есть - перепишу под свои задачи. Например, флэш-часть один мудрый человек переписал уже, она стала более адекватной и более кроссбраузерной (флэш-6).

Спасибо за пояснение про ПНГ и др. А что еще в методах еверкук не следует использовать для авторизации?
Windows Safari Chrome
0
0
alexeybobkov
Я ни в коем случае не специалист, но вот подумал...
Тут пишут, не все методы evercookie безопасны. Однако что, если использовать небезопасные "куки" не для хранения всяких приватных ID, а для хранения простого логического флага, что данный пользователь уже регистрировался? Тогда, если сервер обнаруживает, что у желающего зарегистрироваться нормальных куков нет, но флаг присутствует, это значит, что данный пользователь все куки вытер, а до флага добраться не смог. Ну и дальше, как фантазия позволит (например, при регистрации каптча на 50 символов).
Linux Firefox
 Москва
0
0
Изумительная идея. Пользователь ставил новый плагин и перенастраивал браузер, и тут вдруг ему приехала капча на 50 символов. Очень гуманно.
Windows Safari Chrome
0
0
alexeybobkov
Если ВСЕ нормальные куки вдруг пропали, вряд ли это перенастройка браузера. И потом, 50 - это я для красного словца сказал. Пусть будет 10 :).
Впрочем, как я уже писал, я ни разу не специалист. Вам виднее.
Windows Safari Chrome
0
0
alexeybobkov
Ещё одно уточнение: я, разумеется, не имел в виду регистрацию под уже имеющейся на сервере записью, а исключительно заведение новой.
Windows
 Киев
2
0
lesha (#437416)
Само-подписных недостаточно от злых людей.
http://vitus-wagner.livejournal.com/548941.html

А платить уже не обязательно
http://cert.startcom.org/
"StartCom Free SSL Certification Authority"
Windows Safari Chrome
1
0
N.tony
Обычно когда показывают разные мериканские фильмы, у них телефоны пишутся довольно оригинально, типа 800-call-vasya-pupkin. Я раньше не очень понимал как такое набрать на телефоне, а потом решил, что это они должны набирать те циферки, под которыми эти буковки и стоят. Тогда, например, binoniq будет соответствовать 2466647. Если не смущают три шестерки в середине - по-моему это как-то логичнее.
Nokia-E90 Safari
 Москва
1
4
Leonid Kaganov
Мы же не для одного Перельмана проект делаем. Зачем эта ацкая гичь?
Mac Safari
2
0
Dmitrii 'Mamut' Dimandt (#500351)
Не гичь, а банальная мнемоника. В тех же штатах применяется на каждом углу.
Windows Firefox
0
0
kto (#422086)
по-моему, это как раз самая естественная мнемоника для любой домохозяйки. и блогохозяйки.
Windows
1
0
lesha (#406942)
А есть еще вариант отказаться от паролей совсем.
Все равно он хранится где-то в базе броузера и его никто не помнит (а с evercookie про них еще реже будут вспоминать). Зато часто будут восстанавливать пароль через mail. Так можно оставить только этот способ "залогинится через ваш mail. Вам на почту прийдет одноразовая ссылка, перейдя по которой вы попадете в систему".

Если пользователь может восстановить пароль через почту, то самым слабым звеном остается она в любом случае. ;)
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Я понял! Вы просто не понимаете, о чем разговор.
Как раз о том, чтобы не вводить никаких паролей никогда.
Windows
 Киев
0
0
lesha (#437416)
Да. Не понял вас сразу :(
Думал что это касается после-парольной авторизации, а не всей.
Mac Safari
0
0
Dmitrii 'Mamut' Dimandt (#500351)
К вопросу о куках — так называемый Secure Cookie Protocol, http://rsdn.ru/forum/web/3143416.aspx

И код для этого на РНР: http://raza.narfum.org/post/1/user-authentication-with-a-sec[...]


P.S. То есть это не совсем комментарий по теме, просто — пару ссылок в копилку мыслей.
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Это вообще о чем? У меня нет даты истечения кук - речь о том, что куки должны храниться вечно. Гонять пользователей на перелогин и дурак сумеет.
Windows
 Киев
0
0
lesha (#437416)
Нее - там главный прикол не во времени истечения.
Там смысл в том что куки зашифрованы и только сервер может понять содержимое (а клиент и злоумышленник - нет). И никто другой кроме этого клиента не сможет отослать те же самые куки, как будто он тот пользователь.

Правда смущает то, что они советуют использовать SSL :) Не смотря на то что сами используют алгоритм HMAC ( http://ru.wikipedia.org/wiki/HMAC )
Linux Firefox
 Москва
0
0
Что значит "куки зашифрованы"? У вас сейчас тоже зашифрованы. Вопрос в том, к чему привязаны. Разберитесь с этим.
Windows
0
0
[email protected]Леша (lesha)
Зашифрованы - значит что содержат полезную информацию, а не просто случайный набор буквочек как в частном случае с идентификатором сессии.
Linux Firefox
 Москва
0
0
Ну естественно. Сейчас в движке кука (вы ее можете посмотреть в своем браузере) содержит зашифрованный идентификатор пользователя - единственная полезная информация, остальное всё, касаемо пользователя, движок хранит у себя в базе. Подделать куку нельзя, поскольку неизвестна кодовая строка шифровки. Это азы, которые обсуждать смысла нет, речь совсем не об этом.
Mac Safari
0
0
Dmitrii 'Mamut' Dimandt (#500351)
Ну, по сути это и есть secure cookie :)

В приведенном выше случае с expiration date добавляется дополнительный шаг проверки. Вместо expiration time можно испольовать что-гибудь другое, а можно и не использовать.
Linux Firefox
 Москва
0
0
А зачем тогда для этого "протокол" и "код PHP"? Это ж одна строчка типа:
if($kuka==$numer.'-'.md5($numer.'ебаныйкарась')) { авторизовались! }
Mac Safari
0
0
Dmitrii 'Mamut' Dimandt (#500351)
Ну, авторы так его назвали, я не виноват :)

md5 не является криптостойким алгоритмом. Авторы предлагают более криптостойкий HMAC

Код на РНР был приведен, если вдруг возникли бы вопросы «как этим пользоваться» и т.п.

Оказалось, что этот подход для биноника не подходит, так как там будут стоять «вечные» куки.
Linux Firefox
 Москва
0
0
md5 не является криптостойким алгоритмом?! И что, в сети были случаи взлома блогерских акаунтов путем расшифровки подбора md5?
Windows Firefox
0
0
jabacrack
Вопрос по движку в целом.

Если во время редактирования поста случайно щелкнуть по его заголовку, то форма редактирования откроется заново и все не сохраненное потеряется. Возможно стоит добавить исключения ввида "Если открыта форма редактирования, то никак не реагировать на щелчок по заголовку поста"?
Linux Firefox
 Москва
0
0
Теоретически можно... Но тогда возникает вопрос, почему именно по заголовку? Любой элемент навигации на странице, любая ссылка на ней или в тексте заметки (особенно простейшая "a href="), если по ней кликнуть - сразу уведет далеко с потерей всех данных страницы. Так уж устроен браузер, с этим ничего не поделать.

Можно конечно устраивать карательный рейд JS по всем объектам "a" и навешивать на них событие, запрещающее переход по ссылкам... Но это монструозно и нигде я такого не видел.
Windows Firefox
2
1
lleo.me/[email protected]Артем Павлов
Можно проложить между формой редактора и страницей прозрачный DIV размером с окно браузера, тогда клики будут попадать на него, а не на ссылки/кнопки.
Windows Safari Chrome
0
0
Все нормально? Отпустило?
Windows Firefox
 Пенза
1
0
Тогда уж лучше черный полупрозрачный. Еще один плюс такого решения - затемнение фона будет как бы фокусировать внимание на окне редактирования.


Linux Firefox
 Москва
0
0
А как это лучше сделать?
Если чо - функция установки прозрачности в движке имеется.
Windows Firefox
1
1
lleo.me/[email protected]Артем Павлов
Функцией mkdiv (или как ее там?) создать DIV со стилями position: absolite; background: #000; top: 0; left: 0; z-index: 9000; opacity: setOpacity(); width: 100%; height: getWinHeight().
Ну, понятное дело, setOpacity и getWinHeight - движковые функции, которые должны подставить вместо себя соответствующие значения, если я правильно вспомнил их имена.

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

http://pastebin.com/fZBfDFTy

С HTML все. Дальше дело за CSS.

http://pastebin.com/S77EENin

Не спрашивайте, зачем городить такой огород - тут есть костыли почти под все известные науке браузеры. Здесь прозрачность выставлена на 75%, меняется во втором правиле. z-index: 100 в первом правиле выбран от балды, его можно заменить на любое большое число.

Ну а дальше, собственно, открываем окошко. Единственное, что с ним нужно сделать - присвоить ему CSS-свойство z-index: 101 или больше (ну, смысл в том, чтобы оно по-любому перекрыло свежесозданный DIV). После закрытия окошка DIV убираем... В общем-то все.
Windows Firefox
 Пенза
0
0
Леонид, что-то у вас не то с механизмом заливки фотографий. Я пять раз подряд получил сообщение "Fatal error: foto", а сейчас открываю страницу - вижу аж целых семь своих комментариев с этой картинкой. Причем на первых пяти картинка залита на Ваш сервер, на предпоследнем - залита на ImageShack (несмотря на это, движок мне все равно выдал "Fatal error"), и только последний комментарий с картинкой на ImageShack отправился нормально.
Windows Firefox
0
0
jabacrack
по заголовку, потому что он:

1. кликабелен по все ширине
2. вверху страницы и при легком скроллинге прижимается практически к панеле вкладок

Уже второй раз промахиваюсь при переключении вкладок при редактировании.
Windows IE
0
0
D.iK.iJ
Чтобы не был кликабелен во всю ширину, достаточно поменять местами теги ссылки и заголовка :)))
Но это уже к Леониду.
А прозрачный гиф... будет немного глупо как-то - столько бороться за отдельные окна и вот. Может сразу тогда окно на всю ширину открывать? У меня на сайте так и реализовано. Не скажу что удобнее ))))
Windows Safari Chrome
0
0
Достаточно вешать на onbeforeunload - так делают всякие гуглы-шмуглы например, ну и я в своих админках - работает отлично.

Никакой монстроидальности, защита и от случайных закрытий окна, и от случайного обновления по кнопке или F5
Windows Safari Chrome
1
0
И вот еще когда я пытаюсь подтвердить емейл, то открывается окно с надписью

"Ошибка email.
Необходимо зайти тем самым брайзером, которым регистрировались."


Разумеется, я захожу под тем самым и всё такое. Куки, яваскрипты, флеши и прочее такое у меня разрешено.
Ну и как-то я уже тут логинился, вполне успешно.
Linux Firefox
 Москва
0
0
Сайт видит не тот браузер. Мне уже писал об этой проблеме один человек, потом выяснилось, что у него стояли опции "очищать куки после закрытия браузера".
Windows Safari Chrome
0
0
100% не закрывал сайт, и куки 100% не очищаются.

написал коммент, в соседней вкладке пришло в гугл-почту письмо, из него и открыл
т.е. даже в том же окне, просто в новой вкладке
происходило всё в течении одной минуты. т.е. ни закрыться ни удалиться ничего не могло в принципе.
Windows
0
0
[email protected]Леша (lesha)
Вкладка = другое окно. Просто выглядит оно как вкладка.
Linux Firefox
 Москва
0
0
Попробуйте скопировать ссылку ПОЛНОСТЬЮ (Гугл мог в нее что-то вставить от себя или разбить, перенеся "лишнее" на другую строку) и открыть в другом окне.

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

Я могу вставить дополнительную отладку, которая бы показывала, что именно демонстрирует ваш браузер в качестве куки.
Windows Firefox
0
0
kto (#422086)
а какой вообще сакральный смысл в подтверждении с того же "брайзера"? нигде такого не видел. у меня может к тому "брайзеру" уже и доступа нет, и вообще я почту читаю и по сайтам хожу с разных устройств
Linux Firefox
 Москва
0
0
Возможно, вы правы. Я подумаю.
Windows Firefox
0
0
kto (#422086)
мы, кажется, были на "ты" ;)
я не прав и не лев, я вообще ничего не утверждал. я только спросил, вставлена ли эта фича туда со специальным умыслом, или просто потому, что это технически возможно
Linux Firefox
 Москва
0
0
Это как?
Windows Safari Chrome
0
0
http://www.xiper.net/manuals/html/events/onbeforeunload.html
Добавляю пару своих слов, чтобы ссылка выглядела более завлекательно
Windows
0
0
[email protected]Леша (lesha)
Красиво разводят :)
http://habrahabr.ru/blogs/infosecurity/108553/

Инструкция для пользователя как самостоятельно выполнить вредоносный код на странице ;)
Windows Safari Chrome
2
0
goodkat (#404330)
iframe - если на другом домене, то доступа в него извне нет - безопасность. можно ставить src, но не читать. ну, в нормальных браузерах.

как вариант, другую куку можно опрашивать через тег script - загружать javascript с другого домена, так называемый JSONP (http://en.wikipedia.org/wiki/JSONP#JSONP), но.. но если у пользователя в браузере выбрана (дефолтная) опция "сохранять куки только от посещённых сайтов", то увы

можно сделать что-то типа авторизации по OpenID, когда на "вспомогательном «неуязвимом»" домене будет OpenID-провайдер с вечной непривязанной к IP кукой, а ваш биноник-сайт будет зависимой стороной (потребителем), при заходе на биноник пользователь будет редиректиться на неуязвимый сервер за авторизацией, а потом обратно. на первый взгляд должно сработать.

Лео, переходите на юникод, пожалуйста!
Windows Safari Chrome
0
0
>Лео, переходите на юникод, пожалуйста!
+1
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Для этого должна произойти последовательность событий по смене БСД6 на БСД8, одно из которых (Алексей Петрович Семеняка) от меня не зависит.
Mac Safari
0
0
Dmitrii 'Mamut' Dimandt (#500351)
> Не должно возникнуть ситуации, когда авторизацию можно будет украсть.

Авторизацию можно украсть всегда :) В частности, из-за «человека посередине», http://ru.wikipedia.org/wiki/Человек_посередине

Более того, использование evercookie только увеличит количество способов украсть/подменить эту информацию (через те самые дыры в браузере, над которыми мы не властны).

Есть только способы затруднить получение этой информации — зашифрованные криптостойким алгоритмом куки, передача всех данных по https и т.п.
Linux Firefox
 Москва
1
0
При этом гораздо умнее бросить силы не на усложнение алгоритмов шифрования, латание дырок в браузерах и использование замороченных протоколов, требующих при каждом действии вводить 32-значные пароли, а на умную организацию базы изменений. Когда любой взломанный журнал с удаленными и переправленными заметками вернувшийся хозяин всегда сможет откатить до состояния на любое число.
Mac Safari
0
0
Dmitrii 'Mamut' Dimandt (#500351)
Зашифрованные криптостойким алгоритмом куки — это не усложнение протокола. Это замена некриптостойкого md5, который используется сейчас, на криптостойкий алгоритм.

https не требует ввода 32-значных паролей.

Латать дырки никто не призывает. Только вот желание использовать evercookie идет врзарез с «Совсем другое дело с авторизацией на стороне пользователя: какие дыры появятся в каких браузерах завтра — над этим мы не властны. И какие способы могут открыться при разрешении использования тех или иных тегов — тоже заранее все предугадать нельзя». Так как evercookie только расширяет количество потенциальных дыр. А это количество надо наоборот уменьшать.


А версионность журналов — это вещь хорошая. Защита не только от взлома, но и от самого себя.
Windows IE
0
0
greshnik
Как в свое время делал я.
Кука действительна ровно один раз - на следующий запрос (для облегчения ситуации всякие элементы статики, общедоступные картинки, таблицы стилей и скрипты можно отджавать бесплатно).
При последующем запросе выдается новая кука, а старая уничтожается - тут возможны варианты, она либо уничтожается насовсем, либо помечается как однажды использованная.
Соответственно, даже если куку украдут - злоумышленник сможет использовать ее в пределах одной сессии, как только легальный владелец аккаунта зайдет - кука злоумышленника протухнет. То есть, у вора есть только один вариант - воспользоваться кукой немедленно после ее получения. Но так как с большой долей вероятности юзер не остановится на вороватом контенте - то его попытка будет сразу же пресечена. Если куки не сбрасывать совсем, а помечать как протухшие, то при обнаружению тухлой куки можно сообщить человеку, что вероятно, его аккаунт был несанкционированно использован.
Ну, понятно, что никакие регистрационные данные по одной куке изменить нельзя - только при подтверждении паролем.
В описанном выше примере есть недостаток - при использовании, например, двух компьютеров авторизация будет слетать. Для того, чтобы этого не происходило, можно вводить список "белых" ip-адресов пользователя - и если пользователь логинился с этого адреса в прошлом, разрешать использовать протухшие куки. Для списка белых адресов вполне разумно иметь некий таймаут - после которого адрес исключается из списка.
Другой вариант, более сложный в реализации - при логине с нового адреса (это означает, что пользователь залогинился с работы, например) последнюю использованную куку не удалять, а помечать особым образом. При попытке ее использовать (а это будет означать, что он вернулся домой) - помечать тем же самым образом последнюю (на настоящий момент) использованную куку. Теоретически, таких "помеченных" кук может быть больше чем одна, но активная - только одна.
Можно еще придумать такую схему: насколько я могу судить, современный блоггер - как правило не писатель, а читатель. С другой стороны, опять же как правило, серьезная угроза безопасности на соврменнном блогосервисе это доступ на запись, а не на чтение. Соответственно, кук может быть две - читающая, которая не протухает никогда, и пишущая - стаймаутом. Таким образом, при попытке что-то написать после истечения таймаута можно затребовать пароль еще раз.
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Не очень понятно. А как вы различаете своих посетителей, с одноразовыми-то куками? Кука протухла, и что дальше? Введите заново логин, пароль и капчу из 100 цифр? А если посетитель откроет сразу 3 страницы одновременно во вкладках? Да и вообще - каков смысл?
Windows IE
0
0
greshnik
В 7 IE нельзя отвечать на комментарии, так что отдельной веткой. Вероятно, я не вполне понятно объяснил.
Одноразовая кука, естественно, уникальна для каждого посетителя. Более того, там их вообще-то две (хотя можно и в одну слить с тем же эффектом) - одна имя пользователя, вспомогательная - не меняется, вторая - как раз та самая переменная.
Одноразовая кука протухает одновременно с отправкой новой.
То есть, пользователь делает запрос, передает куку ААА, ему возвращают БББ. ААА больше не действительна.
Три страницы в трех вкладках в переделах одного браузера работать будут совершенно нормально, так как куки шарятся между вкладками.
Зачем - чтобы понятие "воровство сессионной куки" вообще потеряло всякий смысл. Подсмтотренная кука становится недействительной практически сразу же, если она не использована. А если она использована - то об этом узнает легальный владелец, тоже как правило сразу же.
Linux Firefox
 Москва
0
0
Я не понимаю вас.

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

Другой случай: у вас есть кука ААА, но по какой-то причине (пытались сделать запрос, был сбой, сделали повторно) она "протухла", как вы выражаетесь. Что дальше? Шагом марш на полную диспансеризацию с логином и паролем?
Windows IE
0
0
greshnik
>Допустим, у вас есть кука ААА, но я у вас ее украл, передал на сервер и получил вместо вас куку ВВВ. Вы об этом узнали?
Я же сказал - теоретически это возможно. На практике подобная ситуация маловероятна, ибо как правило воровство кук происходит во время сеанса нормальной работы пользователя. То есть если кука была просто сложена в хранилище, она бесполезна - ее надо сразу же отработать. Если кука начинает использоваться сразу же (что требует нетривиального подхода) - то пользователь узнает об этом моментально, и деактивирует все сеансы.

>Другой случай: у вас есть кука ААА, но по какой-то причине (пытались сделать запрос, был сбой, сделали повторно)
Это невозможно. Либо запрос был успешен, и тогда была выпущена новая кука, или запрос до сервера не дошел - и тогда старая кука действительна.

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

всего комментариев: 71

<< предыдущая заметка следующая заметка >>