Python-сообщество

И что это даже не помогает? http://docs.djangoproject.com/en/dev/releases/1.0/#automatic-escaping-of-template-variables

Ferroman
https позволяет закрыть траффик от третьих лиц

Это значит что там где приходят данные от пользователя, если не использовать https то от “снифера” не поможет даже экранирование?

romankrv
Это значит что там где приходят данные от пользователя, если не использовать https то от “снифера” не поможет даже экранирование?

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

romankrv
Да, конечно. Грубо говоря, если не использовать https то можно считать что все данные обмена между клиент-севером доступны 3-й стороне.
fetish
Не один AOL пропускает все через внешние прокси. Множество крупных провайдеров так делают.
Можно использовать шифрованную http-аутентификацию (правда, в IE<7 не работает). Зато для пользователя ничего не изменится, а кук не будет.
Можно сделать короткую сессию (как делают платёжные системы)+https. Я бы так и сделал.

Теперь ясно. И еще вопрос
1)как “настраивать” django проект для использования https? то есть что кроме urls.py необходимо переделывать?
2) достаточно ли будет free сертификата (на стороне сервера(хоста) ) которые генерятся штатными спосабами (openssl) . Так как платить ну совсем не хоцится

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

romankrv
как “настраивать” django проект для использования https? то есть что кроме urls.py необходимо переделывать?

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

romankrv
достаточно ли будет free сертификата (на стороне сервера(хоста) ) которые генерятся штатными спосабами (openssl) . Так как платить ну совсем не хоцится

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

Отредактировано (Апрель 8, 2009 14:50:27)

romankrv
Теперь ясно. И еще вопрос

Ром, в отдельный топик пожалуйста.

Уважаемый, упырьте свой мел. Тут, между прочим, вам помочь пытаются.

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

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

да, кукис по хттпс - это хорошо. я не отрицаю. но это не является панацеей.

Если вы ищите панацею, то вам не сюда. Защита должна соответствовать ценности данных.

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

К чему этот опус? Если есть определённые ограничения, то стоит их озвучить сразу. А отношения с менеджментом тематики поста не касаются.
Я не знаю, как у других, а я предпочитаю не изобретать велосипеды и использовать способы, глюки которых давно известны, а не изобретать новые, борясь с новыми глюками. Что предложил и вам. Не нравится - не надо, насильно не заставляем. Если вы сами знаете лучше - тут вам и флаг в руки и попутного ветра в широкую спину.

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

Ferroman
Защита должна соответствовать ценности данных.

а как вы определите какова ценность хранимых вами данных?
помнится, лет 5 назад, когда я еще любил пошалить на просторах интернета, поломал я слегка одного американского провайдера
слил пользователские хеши, правила хеширования, написал брутер и запустил на выходные
в понедельник у меня были данные примерно 40% списка - это около 120 человек
из этих 120 примерно у трети пароли подошли к их почтовым ящикам на яху, аолу, хотмейлу…
я проверил около 5 ящиков. вы удивитесь как много можно найти у них в почте. аккаунты к различным сервисам, данные кредиток (в том числе и чужих), адреса и телефоны…
и вот я получаю доступ к этому только потому, что какой-то технический специалист относится к пользователям по принципу ССЗБ
зачем конструкторы автомобилей тратят столько денег на краштесты лобового удара? водитель обязан контролировать то, что у него перед машиной. ударился? ССЗБ и дело закрыто.

Ну, через интернет настроение видеть трудно, его можно оценить только по тому как написано. Так что не обессудьте.
Ценность данных оценить не трудно. Достаточно сделать так, что бы угнать пароль с вашего сайта было труднее, чем с любого другого с сравнимой посещаемостью. That's it.
Короткие сессии+https с этим отлично справятся. Вот moneybookers.com годами так делает, а я думаю что его со всех сторон обходили на предмет безопасности. KISS-Бритва Оккама.
Сравнение с машинами - явная гипербола. Сломанный аккаунт != жизнь.