| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Безопасность cookie |
| Автор: bigturtle 27.9.2009, 12:13 |
| Здравствуйте, являюсь новичком в программирование на php. Подскажите если есть авторизация по средствам cookie. Пользователь, получает cookie например с номером sid или хэш который сохраняется в mysql. После чего при посещении страницы sid в cookie сравнивается с sid в БД. Нужно ли проверять cookie например на размер и на присутствие '/" и всяких не желательных элементов? |
| Автор: capitan 27.9.2009, 16:20 |
| bigturtle, cookie можно подменить, подделать. Отсюда делайте вывод. |
| Автор: Ипатьев 27.9.2009, 16:50 |
| проверять не обязательно. sql запрос составлять обычным порядком. |
| Автор: TerminalSoul 27.9.2009, 17:33 |
| Да забей проверять, нафиг надо...) Ну если кончено тебе пофиг на то, что твой сайт через SLQ-Injection можно будет взломать как нефиг) Если данные из кук хочешь вставлять в SQL запрос, обязательно проверяй их - самый простой способ - в запросе переменную помещаешь в одинарные кавычки, а перед подстановкой переменной экранируй кавычки, также есть отличная функция - htmlspecialchars(). |
| Автор: capitan 27.9.2009, 18:26 |
| bars80080, тема называется "Безопасность cookie". ИМХО стоит пояснить, что кукам доверять нельзя. Помнится, как я зная хеш админа, подставил его и попал в админку сайта. Так вот. |
| Автор: Ипатьев 27.9.2009, 19:12 |
| capitan, суть авторизации на куках состоит в том, по хэшу проходит авторизация. И зная хэш админа, можно попасть в админку. Никакие проверки в этом случае не помогают. Проверять нечего. К безопасности это не имеет отношения. Вообще, такие топики редко бывают информативными. Крупицы действительно нужной инфы тонут в тоннах советов доморощенных специалистов по информационной безопасности. В данном случае вопроса никакого нет. Никаким особенным проверкам, данные получаемые из кук, подвергать не нужно. С ними работают точно так же, как с любыми другими данными. |
| Автор: bars80080 27.9.2009, 19:12 |
| и это объясняет ерунду, которую написал TerminalSoul? |
| Автор: capitan 27.9.2009, 19:53 |
| Ипатьев, согласен. Вот только после того, как хакнут через них, начинают задумываться. И пользоваться сессиями |
| Автор: Ипатьев 27.9.2009, 21:04 |
| Я так понимаю, что вы, уважаемый, не ставите на этом форуме галочку при авторизации "Запомнить меня"? В целях, так сказать, безопасности. Чтобы не поломали. |
| Автор: capitan 27.9.2009, 21:22 | ||
Если честно. Не ставлю. НИГДЕ. Ибо может жена сесть за ноут, зайти например, на одноклассники, и почитать всю мою переписку. Я не то чтобы не хочу показывать что там у меня написано. Просто не люблю, когда это без меня читают. P.S. C Вами приятно общаться, правда иногда начинаешь злиться. |
| Автор: youri 28.9.2009, 00:36 | ||
mysql_real_escape_string, parameter markers (mysqli::prepare), http://phpfaq.ru/slashes много есть отличных функций, но как они соотносятся с работой с бд и sql-инъекциями |
| Автор: Crypton 28.9.2009, 16:46 |
| Читал одну статью по таким поводам которая относилась больше к ботообороне чем к безопасности, но думаю кое-какие аспекты и здесь можно применить. Теория такова. При генерации страницы, можно послать какой-нибудь хэш в <input type="hidden" и запомнить его например в сессии или где-нибудь еще, например хэшировать его еще разок и запихнуть в другую плюшку. При отправке формы, извлекаем хэш с поля и сверяемся с перехэшированным видом из другой плюшки либо сессии. Если сравнение не происходит, посылаем пользователя куда надо |
| Автор: Ипатьев 28.9.2009, 16:56 |
| Это почти не помогает от ботообороны. Здесь тоже применить не получится. Если только этот параметр - не цифры с каптчи. но, опять же, это не "безопасность cookie", а защита от перебора, если только. |
| Автор: Crypton 28.9.2009, 17:04 | ||
Не знаю, но справляемся |
| Автор: capitan 28.9.2009, 17:08 |
| Из опыта могу сказать, что это не поможет от ботов. Писал как-то авторегистраторы на мыльные сервисы с простой капчей. Так как капчу тоже на php распознавал. Точкой предкновения являлись только переменные сгенерированные через JS. Так как CURL не может с JS работать. Приходилось или переводить функции JS на php или отказываться от такого сервиса. |
| Автор: Crypton 28.9.2009, 18:11 |
| Хм. Не могу согласиться но и спорить не стану. Я более разбираюсь в ASP.NET, чем в php но и сам проработал ведущим php разработчиком в одной конторе полтора года. |
| Автор: Ипатьев 28.9.2009, 18:54 |
| Серверная платформа в данном случае вообще не важна, НТТР запросы-то одинаковые. |