информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / web building
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
О чём вы, сударь? Фильтрация и экранирование - это крайние... 01.03.11 01:28  Число просмотров: 4122
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 01.03.11 16:17  Количество правок: 4
<"чистая" ссылка>
> Ну-ну... Блаженны верующие ;) Хозяин уверен, что знает.И,
> пока данные шлет его фронт-энд, это так и есть. Но
> фронт-энд может сварганить кто-то другой и поэтому и
> приходится извращаться с фильтрацией, экранированием,
> проверками...
О чём вы, сударь? Фильтрация и экранирование - это крайние меры. Правильное решение - проверка на соответствие ожидаемому типу данных. Нормальный пользователь просто не сможет внедрить в поле md5 что-либо, а ненормальных - в баню.

А ну-ка показывай пример как можно прорвать этот шаблон! ;)
if (!preg_match("^[0-9a-f]{32}$i",$_POST['md5']) {
trow("mistaked md5 data, possible cracker's attack");
} 

---


> Кстати, вместо md5 лучше использовать sha1.
Читай md5, как "некий удобный алгоритм хеширования, который в принципе не имеет значения". Не принципиально - сути не меняет.

>> В результате на сервере может храниться хэш пароля,
> Должен. Не "может", а должен. Пароли в чистом или обратимо
> зашифрованном виде уже даже мелкософт лет десять-двенадцать
> как хранить перестал.
>> а сравниваться он будет с повторным хэшем источника и соли.
> Что есть такое "соли"?
Не стоит рвать предложение:
Уточняю чуть другими словами.
Сервер может хранить хэш, а сравнение проводить, используя простую функцию f(hash+salt)
Солью в данном случае отлично служит капча.
В качестве f может быть что угодно. На вскидку всё тот же md5
Нет смысла в необратимо-хэшированном пароле если хэш одинаковый от сессии к сессии.


> Рекомендую забить на нее и использовать mysqli. Там есть
> все и даже больше.
Не думаю, что это решение идеально, я предпочитаю писать не привязываясь к конкретным расширениям, ибо далеко не везде они могут быть.

И да, разумеется в php были баги типа внедрения нулевого символа в строку - подобные фишки нужно помнить, но не стоит заморачиваться на них. Не надо быть параноиком, а просто иметь в виду в каком из мест надо обратить внимание. При использовании функций типа pg_prepare эта проблема уходит в никуда.
Про нуль можно почитать, например, по ссылке.

null-byte-injection
<web building> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach