Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | |
О чём вы, сударь? Фильтрация и экранирование - это крайние... 01.03.11 01:28 Число просмотров: 7262
Автор: 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>
|
Опять вопрос по PHP+SQL 09.12.10 04:17
Автор: Fighter <Vladimir> Статус: Elderman
|
Наткнулся на одном форуме на вот такой пост:
inferno26
$result = mysql_query("SELECT * FROM `users` WHERE email = '".htmlspecialchars(addslashes($_POST['email'])."'AND md5 = '".htmlspecialchars(addslashes($_POST['md5'])."'");
согласен так лучше???
Нет.
Сначала два раза addslashes, а затем уже htmlspecialchars
Зачем вообще нужно обрабатывать md5 и для чего ему советуют два раза использовать addslashes перед заменой тегов?
|
|
Кстати, сразу не отметил, кроме функций со слешами нужно ещё и разум врубать - фильтровать с умом. Та же md5 - это набор hex-цифр длиной 32 символа. В итоге один regexp решит стоит ли вообще отрабатывать запрос или нет. 27.02.11 19:46
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 27.02.11 19:49 Количество правок: 2
|
> $result = mysql_query("SELECT * FROM `users` WHERE email =
> '".htmlspecialchars(addslashes($_POST['email'])."'AND md5 =
> '".htmlspecialchars(addslashes($_POST['md5'])."'");
> согласен так лучше???
В качестве теста может подойти такой код.
if (!preg_match("^[0-9a-f]{32}$i",$_POST['md5']) {
trow("mistaked md5 data, possible cracker's attack");
}
Ну, а далее уж без запарок помещать переменную в запрос.
|
| |
Ну, если врубать разум, то ответ на мой первый вопрос такой:... 27.02.11 23:07
Автор: Fighter <Vladimir> Статус: Elderman
|
|
Ну, если врубать разум, то ответ на мой первый вопрос такой: потому, что md5 не вычисляется на стороне сервера, а получается от клиента ;))))
|
| | |
Суть верна, реализация оно ) На фиг слешить hex-последовательность? ) правильнее проверить, а действительно ли переменная имеет ожидаемый тип ) Равно как и цифровые id слешить не надо. Надо убеждаться, что они цифровые, либо приводить к цифре: $id+=0; 28.02.11 19:26
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | |
Ага, вот так и появляются на свет продукты - будущие жертвы SQL-инъекций и прочих шалостей ) 01.03.11 00:03
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | | | |
Ошибаешься, сударь. sql-инъекцию забабаешься здесь внедрять ;) А вот фанатеть от слешей - это нелепо. 01.03.11 01:19
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 01.03.11 01:31 Количество правок: 2
|
Кроме того за слеши и квотирование ПЕРЕД внесением в бд прибивать надо. Если данные верны - то они и храниться должны так, как и были введены.
Попробуй-ка организовать редактирование статей при использовании addslashes, html_specialchars ДО внесеня в бд.
А текст бусть будет из одной строки:
"Tom & Jery"
отслешил, да заквотировал - получил:
\"Tom & Jery \"
Что б подобную гадость отдать в поле редактирования textarea придётся убирать квотирование вручную. И как раз на этом этапе можно легко накосячить. Особенно, если значение Magic_Quotes отличается от сервера к серверу.
Более правильный вариант:
1. проверка входных данных на соответствие ожидаемому типу.
2. избегание прямого размещения переменных в запросах. Мне понравилось решение Котерова DbSimple, как реализация функционала pg_prepare
3. Отсутствие искажения данных вносимых в бд
4. Качественная отработка вывода данных полученных из бд.
Пара примеров проверки типов:
<?
$_POST['id']="I'm c00l haxor"
$id = $_POST['id'];
$id+=0;
echo $id;
?>
---
Аналогично - проверка на заранее безопасный тип данных [0-9a-f]{32}
if (!preg_match("^[0-9a-f]{32}$i",$_POST['md5']) {
trow("mistaked md5 data, possible cracker's attack");
}
---
разумеется в sql-запрос переменные подставляться должны после квотирования необходимого для используемой субд. касательно mysql решение в лоб - mysql_real_escape, решение с удобствами - уже описал.
|
| | | | | |
У меня ощущение, что ты только закончил читать Котерова (или Котерова с Костаревым?8) ) и спешишь рассказать все, что там узнал ;) 01.03.11 02:07
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | | | | | |
Зато я чётко вижу, что ты заблуждаешься не только в кодинге, но и в суждениях о других :) 01.03.11 15:59
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | | | | | |
Ну, с кодингом у тебя, вроде, нормально, а вот о чем писал я - ты так и не понял ) 01.03.11 17:34
Автор: Fighter <Vladimir> Статус: Elderman
|
|
Так что, не знаю как с первым, но во втором мы видимо коллеги... ;)
|
| | | | |
Не обязательно парсить всё подряд. 01.03.11 00:56
Автор: Den <Денис Т.> Статус: The Elderman
|
|
Если тебе по get или post пришли данные, которые ты должен интерпретировать как целое число, то слешить и проверять не обязательно, достаточно прогнать через функцию приобразования строки в целое число и хранить до востребования как переменную типа integer.
|
| | |
Смотря для чего. 28.02.11 01:31
Автор: Den <Денис Т.> Статус: The Elderman
|
|
Если не ошибаюсь, POST передает данные от клиента к серверу в защищенном канале. Соответственно, пароль можно передавать через POST не прогоняя его через MD5. Но хранить пароль в базе регистрации "открытым текстом" это, мягко говоря, моветон. И в этом случае, MD5 ,будет вычисляться только на сервере.
|
| | | |
Ошибаешься. Если ты не включил защищенный режим, то браузер... 28.02.11 02:27
Автор: Fighter <Vladimir> Статус: Elderman
|
> Если не ошибаюсь, POST передает данные от клиента к серверу
> в защищенном канале. Соответственно, пароль можно
Ошибаешься. Если ты не включил защищенный режим, то браузер за тебя его сам включать не будет
> передавать через POST не прогоняя его через MD5. Но хранить
> пароль в базе регистрации "открытым текстом" это, мягко
> говоря, моветон. И в этом случае, MD5 ,будет вычисляться
> только на сервере.
Это все до %опы, тем более что MD5 необратима, и нам не известно считали ее для пароля или порнофильма. В общем случае, запись $_POST['md5'] обещает, что форма имела текстовое поле с именем 'md5' и ее содержимое было передано методом $_POST. Но, на то, что это так, мы только надеемся. На самом деле, как всегда, предполагаем худшее: не было никакой формы, а пришедший в запросе набор данных сформировал злой кулхацкер А Си Сяй, возжелавший наше все.
|
| | | | |
Не много не в тему, про использование Md5 для создания динамических ключей-авторизации и о DbSimple 28.02.11 19:23
Автор: kstati <Евгений Борисов> Статус: Elderman
|
> > Если не ошибаюсь, POST передает данные от клиента к
> серверу
> > в защищенном канале. Соответственно, пароль можно
> Ошибаешься. Если ты не включил защищенный режим, то браузер
> за тебя его сам включать не будет
> > передавать через POST не прогоняя его через MD5. Но
> хранить
> > пароль в базе регистрации "открытым текстом" это,
> мягко
> > говоря, моветон. И в этом случае, MD5 ,будет
> вычисляться
> > только на сервере.
> Это все до %опы, тем более что MD5 необратима, и нам не
> известно считали ее для пароля или порнофильма. В общем
> случае, запись $_POST['md5'] обещает, что форма имела
> текстовое поле с именем 'md5' и ее содержимое было передано
> методом $_POST. Но, на то, что это так, мы только надеемся.
> На самом деле, как всегда, предполагаем худшее: не было
> никакой формы, а пришедший в запросе набор данных
> сформировал злой кулхацкер А Си Сяй, возжелавший наше все.
Угу, тем более, что реализаций md5-js уже до фени, а хозяин сайта (кодер как минимум) должен знать какой тип переменной используется фронт-эндом.
И небольшое увеличение защищённости можно делать как... md5(md5(password)+captcha) то есть использовать сессионные ключи. В результате на сервере может храниться хэш пароля, а сравниваться он будет с повторным хэшем источника и соли.
при установке пароля в бд вносится md5(pass) = md5pass
в форме авторизации висит и каптча, на сервер возвращается, например,
$_POST['checksum'] = md5(md5(pass)+captha)
сервер зная md5pass легко проверит правильность связки пароль + каптча например так.
select id from users where md5(md5pass+'$captcha') == '$checksum';
К слову сказать, мне оч нравится идея sqlite да postgree с подготовкой запросов. Тот же pg_prepare:
$result = pg_prepare($dbconn, "my_query", 'SELECT * FROM shops WHERE name = $1');
$result = pg_execute($dbconn, "my_query", array("Joe's Widgets"));
---
Аналогичные плюшки разработаны и для Mysql. На вскидку - Котеров написал неплохую либу. Грех не воспользоваться ею. Разумеется, прочитав исходники да описание многие вещички станут на свои места.
DbSimple
|
| | | | | |
Ну-ну... Блаженны верующие ;) Хозяин уверен, что знает.И,... 01.03.11 00:01
Автор: Fighter <Vladimir> Статус: Elderman
|
> > > Если не ошибаюсь, POST передает данные от клиента
> к
> > серверу
> > > в защищенном канале. Соответственно, пароль можно
> > Ошибаешься. Если ты не включил защищенный режим, то
> браузер
> > за тебя его сам включать не будет
> > > передавать через POST не прогоняя его через MD5.
> Но
> > хранить
> > > пароль в базе регистрации "открытым текстом" это,
> > мягко
> > > говоря, моветон. И в этом случае, MD5 ,будет
> > вычисляться
> > > только на сервере.
> > Это все до %опы, тем более что MD5 необратима, и нам
> не
> > известно считали ее для пароля или порнофильма. В
> общем
> > случае, запись $_POST['md5'] обещает, что форма имела
> > текстовое поле с именем 'md5' и ее содержимое было
> передано
> > методом $_POST. Но, на то, что это так, мы только
> надеемся.
> > На самом деле, как всегда, предполагаем худшее: не
> было
> > никакой формы, а пришедший в запросе набор данных
> > сформировал злой кулхацкер А Си Сяй, возжелавший наше
> все.
> Угу, тем более, что реализаций md5-js уже до фени, а хозяин
> сайта (кодер как минимум) должен знать какой тип переменной
> используется фронт-эндом.
Ну-ну... Блаженны верующие ;) Хозяин уверен, что знает.И, пока данные шлет его фронт-энд, это так и есть. Но фронт-энд может сварганить кто-то другой и поэтому и приходится извращаться с фильтрацией, экранированием, проверками... Кстати, вместо md5 лучше использовать sha1.
>
> И небольшое увеличение защищённости можно делать как...
> md5(md5(password)+captcha) то есть использовать сессионные
> ключи. В результате на сервере может храниться хэш пароля,
Должен. Не "может", а должен. Пароли в чистом или обратимо зашифрованном виде уже даже мелкософт лет десять-двенадцать как хранить перестал.
> а сравниваться он будет с повторным хэшем источника и соли.
Что есть такое "соли"?
>
> при установке пароля в бд вносится md5(pass) = md5pass
> в форме авторизации висит и каптча, на сервер возвращается,
> например,
> $_POST['checksum'] = md5(md5(pass)+captha)
> сервер зная md5pass легко проверит правильность связки
> пароль + каптча например так.
>
> select id from users where md5(md5pass+'$captcha') ==
> '$checksum';
>
> К слову сказать, мне оч нравится идея sqlite да postgree с
> подготовкой запросов. Тот же pg_prepare:
> $result = pg_prepare($dbconn, "my_query", > 'SELECT * FROM shops WHERE name = $1');
> $result = pg_execute($dbconn, "my_query", array("Joe's
> Widgets"));
---
>
> Аналогичные плюшки разработаны и для Mysql. На вскидку -
> Котеров написал неплохую либу. Грех не воспользоваться ею.
> Разумеется, прочитав исходники да описание многие вещички
> станут на свои места.
Рекомендую забить на нее и использовать mysqli. Там есть все и даже больше.
|
| | | | | | |
О чём вы, сударь? Фильтрация и экранирование - это крайние... 01.03.11 01:28
Автор: 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
|
| | | | | | | |
У меня ощущение, что отвечающие читают только знакомые слова, не напрягаясь понять написанное в целом. 01.03.11 02:02
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 01.03.11 02:02 Количество правок: 1
|
> > Ну-ну... Блаженны верующие ;) Хозяин уверен, что
> знает.И,
> > пока данные шлет его фронт-энд, это так и есть. Но
> > фронт-энд может сварганить кто-то другой и поэтому и
> > приходится извращаться с фильтрацией, экранированием,
> > проверками...
> О чём вы, сударь? Фильтрация и экранирование - это крайние
О проверках, уважаемый! И о фильтрации с экранированием при необходимости.
> меры. Правильное решение - проверка на соответствие
> ожидаемому типу данных. Нормальный пользователь просто не
> сможет внедрить в поле md5 что-либо, а ненормальных - в
> баню.
Слушай, ты вообще о чем? Чего ты с этим 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 эта проблема уходит в
> никуда.
> Про нуль можно почитать, например, по ссылке.
|
| | | | | | | | |
Не стоит материться, даже если твои аргументы исчерпаны )) 01.03.11 16:13
Автор: kstati <Евгений Борисов> Статус: Elderman
|
> На хуя мне это нужно и что ты пытался мне доказать написав
> это? Что знаком с регэкспами?
Псих ты )) не видишь очевидного.
Это простая проверка
Аналогично как при вводе цифрового пин-кода слеши и прочая ерись не нужны. Достаточно убедиться, что введены именно цифры.
> Не стоит писать всякую хрень. Включи разум, перечитай тебе
> написанное и подумай что именно тебе писали.
Как я тебя понимаю ))
> Ога, рекомендуемая тобой библиотека есть везде )))
Это сырец, который легко внедряется в проект. Настройки сервера не имеют значения.
|
| | | | | | | | | |
Тут обязательно станешь психом)) Я же кучу постов пытаюсь... 01.03.11 17:47
Автор: Fighter <Vladimir> Статус: Elderman
|
> > На хуя мне это нужно и что ты пытался мне доказать
> написав
> > это? Что знаком с регэкспами?
> Псих ты )) не видишь очевидного.
Тут обязательно станешь психом)) Я же кучу постов пытаюсь объяснить, что мне это все и так понятно, а вопрос про md5 был вызван только тем, что я не заметил $_POST и решил, что автор вопроса обрабатывает результат вызова md5(), и его зачем-то в этом поддерживают.
> Это простая проверка
> Аналогично как при вводе цифрового пин-кода слеши и прочая
> ерись не нужны. Достаточно убедиться, что введены именно
> цифры.
Полностью с тобой согласен, но копипастерам лень это делать, им проще вызвать addslashes().
>
> > Не стоит писать всякую хрень. Включи разум, перечитай
> тебе
> > написанное и подумай что именно тебе писали.
> Как я тебя понимаю ))
Ох, надеюсь )
>
> > Ога, рекомендуемая тобой библиотека есть везде )))
> Это сырец, который легко внедряется в проект. Настройки
> сервера не имеют значения.
|
| | | | | | | | |
тебе обработку md5 приводят в качестве хорошего и наглядного... 01.03.11 02:38
Автор: Den <Денис Т.> Статус: The Elderman
|
> Слушай, ты вообще о чем? Чего ты с этим md5 носишься как
> дурень с писаной торбой... Злоумышленник не будет
> использовать веб-форму на твоем сайте и/или сервере. Ему
> твой фронт-энд до %опы если только он не позволяет
> использовать известные злоумышленнику дыры.
тебе обработку md5 приводят в качестве хорошего и наглядного примера. Если бы ты до конца дофтыкал тему парсинга параметров get/post ты бы понял, что на одном прослешивании свет клином не сошелся. Существует еще несколько способов корректно обработать полученные данные и поместить их в БД без риска выполнить sql инъекцию. А там пусть хоть telnet в роли фронт-энда - пофигу!
> > А ну-ка показывай пример как можно прорвать этот
> шаблон! ;)
> > > > if (!preg_match("^[0-9a-f]{32}$i",$_POST['md5']) {
> > trow("mistaked md5 data, possible cracker's attack");
> > }
---
> На хуя мне это нужно и что ты пытался мне доказать написав
> это? Что знаком с регэкспами?
никак не пойму - толи ты реально протормаживаешь, толи прикидываешься.
если ты используешь приведенный шаблон, то хоть десять sql инъекций засунь - нифига у тебя не выйдет. При этом, ничего прослешивать не требуется.
|
| | | | | | | | | |
Ты дурак или прикидываешься? Нахуя мне этот пример и твои объяснения про md5? 01.03.11 10:36 Штраф: 20 [Den, Fighter]
Автор: Fighter <Vladimir> Статус: Elderman
|
|
ИМХО, дурак: умные уже давно поняли, что изначально я просто не обратил внимания, что md5 передается скрипту, а не генерится им. А про двойное прослешивание мне уже давно ответили
|
|
|
подробно о проекте
Анализ криптографических сетевых...
