textarea и слеши

[RomCom]

Проблема такая. Почему то в текст из textarea добавляются слеши (\) перед кавычками и самими слешами.
вот простой скрипт (для примера) t.php:

Код:

<form action="/test/t.php" method="post">
<textarea cols="100" rows="10" name="htmltext"><?php if(isset($_POST[&#39;htmltext&#39;])) echo($_POST[&#39;htmltext&#39;]); ?></textarea>
<BR>
<input type="submit" name="htmltextEdit" value="OK">
</form>

т.е. он выводит в textarea то что послано метадом post из этого же textarea.
После нескольких итераций получается вот такая хрень
<p align=\\\\\\\"left\\\\\\\">
Как с этим боротся?

[RomCom]

Разобрался. Всему виной php_flag magic_quotes_gpc 1 
Если кому интересно вот ссылка с полным раскладом по этому вопросу http://www.phpfaq.ru/slashes

[RXL]

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

if (iniget('magic_quotes_gpc'))
{
    $_GET['var'] = stripslashes($_GET['var']);
}

[RomCom]

Отключить не возможно, т.к. пользую виртуальный сервер у хостера --> нет доступа к настройкам системы.
А вообще нет худа без добра
Не зацепись я за слеши то не нашел бы приведенную выше страничку. Не прочитал бы о "SQL Injection".
Теперь может хакером стану (хотя навряд ли, я строить а не ломать люблю).

RXL, мож посоветуешь сайты по безопасности (рус.). Меня в основном интересует: PHP скрипты, MySQL, способы авторизации пользователей. Чет меня это немного зацепило . Начел копаться в инете, воды очень много. Проблемы описываются, а пути решения обозначены в скользь.

[RXL]

RomCom, по php: www.php.net/manual/ru/ . Там есть разделы по безопасности и вообще хорошо сделано - есть комментарии. Только, в основном, на английском.

По безопасности MySQL все много проще, просто нужна внимательность и соблюдение одного правила: перед помещением внешних данных в sql-строку их следует проверить.
Для чисел достаточно сложить с нулем или проверить ф-иями из серии is_*() или регулярным выражением.
Для строк - обязательно mysql_escape_string() и обернуть кавычками. В принципе, числа можно обрабатывать как строки - sql это допускает.
Не рекомендую заменять mysql_escape_string() на addslashes(), хоть они и выполняют одну работу.
Строки еще можно проверять на максимальную длину.

[Шнибл]

xelos в теме https://forum.shelek.ru/index.php/topic,7990.0.html интерессную сылку приводил.

[RomCom]

RXL, про www.php.net я в курсе
Читал то что там есть по аутентификации, но там только упоминается HTTP-аутентификации.
А как быть если охота сделать всё розовым и пушистым, тобиш чтоб как у большинства сайтов (включая и shelek.com) выводить предложение ввести логин и пароль на страничке сайта.

Например выводим приглашение аутентификации:

Код:

<form action="/auth.php" method="post">
<div>Логин</div>
<div><input type="text" name="login" value="" maxlength="15"></div>
<div>Пароль</div>
<div><input type="password" name="pass" value="" maxlength="25"></div>
<div><input type="submit" name="submit" value="Login"></div>
</form>

Далее в auth.php

Код:

if($_POST['login']==$lg &&
   md5($_POST['pass'])==$ps) // в $ps наш пароль зашифрованный в md5
{
 //здесь мы должны как-то сохранить что всё ОК
}

А как безопасно сохранить что чел. уже прошел авторизацию?
Знаю, знаю!! Вы меня дружно пошлете в session или cookie   Но содержимое session, а тем более cookie, можно перехватить.
В найденных мной статьях на эту тему рекомендуется проверять HTTP_USER_AGENT, REMOTE_ADDR и т.д. т.е. переменные из $_SERVER. Но насколько я знаю их тоже можно "подделать".
Чему тогда можно верить  ?

[RXL]

RomCom, если нужна еще большая надежность, то используй https - это понизит вероятность перехвата.

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

Поройся в коде движка SMF 1.1RC2 - по части безопасности наворотов много - есть чему поучиться: sha1 пароли, шифрованные данные в куки.

Собственно, расскажи, какие возможные ситуации тебя смущают?

[Chaa]

Содержимое сессии перехватить нельзя, можно лишь после перехвата cookie узнать идентификатор сессии и воспользоваться чьей-то сессией. Радует, что cookie перехватить совсем не просто.
IP-адрес (REMOTE_ADDR) клиента подделать практически невозможно, следует только учитывать, что он может быть одним и тем же у нескольких клиентов.

На большинстве сайтов используется сессия для хранения факта, что человек прошел авторизацию. Для большей безопасности можно добавить в сессию IP-адрес авторизованного человека.

HTTPS поможет, если есть вероятность перехвата трафика в локальной сети или в сети провайдера клиента.

[RomCom]

Мне собственно необходим вариант защиты аутентификации "среднего" размера так сказать. Без лишних наворотов, чтоб перекрывала возможности 80-90% процентов юнцов, считающих себя хакерами. Сайты которые я делаю не представляют интереса для хаказоидов, но лучше немного подстраховаться мало ли, кому ручки захочетси размять
Куки мне пока без надобности, т.к. аутентификация пока нужна только для админки.

Если в переменной сессии и базе сохранять (например) md5(rand(-999999,999999)." ".SERVER['REMOTE_ADDR']), а после сравнивать. Такой защиты будет достаточно для выше указанного контингента?

И еще на будующее
Что нужно чтоб запустить HTTPS на сайте? Там же какой то сертификат необходим.

[RXL]

RomCom, т.е. ситуации с перехватом идентификатора сессии ты откидываешь? На всякий случай спрашиваю, чтоб не возвращаться к нему. Men in middle то же не рассматриваем?

https поддерживается средствами сервера. Для программы разница только в появлении новых переменных в $_SERVER. Сертификат можно подписать самому, но браузеры (если не отучить) будут при каждом заходе сообщать об этом и спрашивать о продолжении работы. Некоторых пользователей это пугает.

[Chaa]

Можно сделать примерно так.
Аутентификация, после проверки логин/пароль:

Код:

$_SESSION['authenticated'] = true;
$_SESSION['remote_address'] = $_SERVER['REMOTE_ADDR'];

Проверка, что пользователь уже аутентифицирован:

Код:

if (isset($_SESSION['authenticated']) && $_SESSION['authenticated']
    && $_SESSION['remote_address'] == $_SERVER['REMOTE_ADDR'])
{
    ...
}

Если есть возможность, то для администрирования сайта стоит использовать HTTPS, но, насколько я знаю, на виртуальном хостинге он не будет работать (для HTTPS нужен отдельный IP-адрес для каждого сайта, что вряд ли возможно на виртуальном хостинге).

[RXL]

Chaa, https вполне работает и с виртуальными серверами - проверял.
Проверка IP не есть гуд - пользователь вполне законно и без злого умысла может его сменить в процессе работы с сайтом.

[RomCom]

RomCom, т.е. ситуации с перехватом идентификатора сессии ты откидываешь? На всякий случай спрашиваю, чтоб не возвращаться к нему. Men in middle то же не рассматриваем?

RXL, Chaa меня немного успокоил, сказав что перехватить сессию сложно
Я так понимаю, чтоб перехватить переменную сессии, т.е. то что находится в header части http запроса/ответа, необходимо получить доступ к этому контенту в "сыром" виде. Это возможно только если перехватив данные на прокси-сервере или на компе у самого пользователя ("Men in middle" это имеет ввиду?). Оба варианта подразумевают высокое знание хакерского дела.
Т.е. этот вариант вроде как перекрывает те 80-90%? Или я ошибаюсь?

[Chaa]

Проверка IP не есть гуд - пользователь вполне законно и без злого умысла может его сменить в процессе работы с сайтом.

Я предлагаю запоминать IP-адрес при аутентификации и проверять его в последуюшем. Если у пользователя изменится IP-адрес, то ему просто придется заново ввести логин-пароль. Все-таки в современных условиях не так уж много людей используют модемы.

[RXL]

Chaa, модемами пользуются еще очень многие - не все живут в Москве. Если при каждом конекте требовать вводить пасс, пользователь навсегда покинет сайт.

RomCom, есть еще метод дублирования идентификатора сессии в параметрах урла. Применяется при проблемах с куки у пользователя. Это тот самый случай легкого перехвата сессии: пользователь публикует ссылку, по которой любой желающий по горячим следам влезает в его сессию.
Т.е. такой метод лучше исключить.

[Chaa]

RomCom, есть еще метод дублирования идентификатора сессии в параметрах урла. Применяется при проблемах с куки у пользователя. Это тот самый случай легкого перехвата сессии: пользователь публикует ссылку, по которой любой желающий по горячим следам влезает в его сессию.

Проверка IP-адреса поможет бороться со случайной публикацией ссылки с идентификатором сессии.

Chaa, модемами пользуются еще очень многие - не все живут в Москве. Если при каждом конекте требовать вводить пасс, пользователь навсегда покинет сайт.

Насколько я понял, аутентификация нужна для целей администрирования сайта, а администратор не должен лениться

[RomCom]

RomCom, есть еще метод дублирования идентификатора сессии в параметрах урла. Применяется при проблемах с куки у пользователя. Это тот самый случай легкого перехвата сессии: пользователь публикует ссылку, по которой любой желающий по горячим следам влезает в его сессию.
Т.е. такой метод лучше исключить.

Дублирование сессии в параметрах урла может произойти если только я сам это сделаю. Браузер сам такого делать недолжен.
Или при "проблемах с куки" браузер сам, на свое усмотрение, может вытворить такой финт?

[RXL]

Нет, это делает не браузер а php. Типа есть механизм для автоматической вставки в урлы выводимого документа. Правда, как я не старался, на современных версиях php мне это не удалось.

[Chaa]

Эта опция называется session.use_trans_sid, по умолчанию она выключена. Если на хостинге включена, ее можно отключить в скрипте.

Код:

ini_set('session.use_trans_sid', '0');

[RXL]

Chaa, я пытался наоборот, в порядке эксперимента, при выключенной в конфиге включить в скрипте и мне это не удалось.

[Chaa]

В документации написано, что можно для PHP >= 4.2.3
http://ru.php.net/manual/ru/ini.php
Но сам не пробовал.
Чтобы заработало нужно еще сделать:
session.use_cookies = 0
session.use_only_cookies = 0

[RomCom]

RXL, Chaa, спасибо!
Вопрос можно считать закрытым.
Аутентификацию сделал. В сессии завел переменные SESSION['login'] и SESSION['pass']. В них храню sha1 хеш логина и генерируемой определеным образом строки (secret_str) соответственно. + добавил ограничение по "времени жизни" для secret_str.
От шифрования md5 отказался, т.к. после короткого поиска наткунлся на проги которые этот md5 взламывают за пару сек.
Читал что и с sha1 тоже вроде как не все гладко. Китайци бьют себя в грудь, мол нашли способ взламывать этот шифр . Но пока это только в теории (насколько я понял).

[RXL]

За пару секунд? Ну-ну.
Из хеша получить исходную последовательность невозможно. Можно только перебором вариантов исходной последовательности, хешированием ее и сравнением с взлавываемым образцом. Это очень долгая процедура. Конечно, если входная последовательность очень короткая или соотв. слову из типичных словарей типа craсklib, то перебор быстро даст результат.

Для усложнения можно, например, сначала захешировать пароль (тем самым довести его до 16, 20, 32 или 40 байт длины), а потом хешировать его вместе с контрольной последовательность, переданной сервером.

[RomCom]

Расшифровка оказалась шуткой Непридал значения надписи "Шютка юмора. Посвящается mikelsv"
Вот страничка: http://www.eus.ru/md5/
Вот подлеци, а я купился

Но в любом случае sha1 посолидней будет.

[Шнибл]

RXL, Chaa, спасибо!
Вопрос можно считать закрытым.
Аутентификацию сделал. В сессии завел переменные SESSION['login'] и SESSION['pass']. В них храню sha1 хеш логина и генерируемой определеным образом строки (secret_str) соответственно. + добавил ограничение по "времени жизни" для secret_str.
От шифрования md5 отказался, т.к. после короткого поиска наткунлся на проги которые этот md5 взламывают за пару сек.
Читал что и с sha1 тоже вроде как не все гладко. Китайци бьют себя в грудь, мол нашли способ взламывать этот шифр . Но пока это только в теории (насколько я понял).

Простите мне мою безграмотность но насколько я уяснил все переменные сессии хранятся на серваке, тоесть если нехороший человек узнал ID сессиии, то на серваке для этого ID все переменные SESSION['login'] и SESSION['pass'] всё равно хранятся и наш скрипт их и вытянет так как ID совпал, значит всё это работает только если генерация secret_str отталкивается от информации что то вроде  $_SERVER['REMOTE_ADDR']. и заново генерировать и сравнивать secret_str нужно на каждой странице.

Да и вроде бы, если один из способов получения session ID это кривой хостер, когда все сессии лежат в 1 папке, то что мешает злоумышленнику вместе с ID и просто не заглянуть в содержимое файла, где все переменные и записаны... в этом случае как раз спасет только хранение переменных в виде как результат md5(). чтобы за время перебора значения переменной время сесии истекло.

[RXL]

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

По первой части: куда вытянет? Не ясная формулировка условий и такие же выводы. Не экономь на словах.

[Шнибл]

ну например если  secret_str формируется из "секретного слова" которое никак не зависит от "Пользователя" то смысла в нем вообще никакого нет, тоесть  скрипт формирует secret_str=md5("константа"."что-то еще") при условии если это "что-то еще" не завязано на  какое нибуть значение получаемое от пользователя. Потому как в скрипте проверки вы опять же сформируете secret_str по точно такому же принципу, и будете сравнивать его с например с  SESSION['secret_str'], которое опять же благополучно известно при подделаном SessionID.

[Chaa]

Лично я вообще не вижу никакой необходимости шифровать или хэшировать что-либо.

В сессии обычно хранятся данные аутентифицированного пользователя. Данные сессии недоступны вне скриптов сайта (на нормальном хостинге, если хостинг ненормальный, тут уже ничего не поможет). Нужно лишь побеспокоиться, чтобы данные в сессию записывались аккуратно.

[Шнибл]

Речь идет одвойной проверке, когда наличия у пользователя SessionID еще не означает что он "тот самый" пользователь. а его еще нужно дополнительно проверить на вшивость... Простой пример когда размещают ссылку в форуме а вы по ней прошлись, Даже возможно именно вы зная о всех подводных камнях и не пройдетесь, а где гарантия что Вася Пупкин - пользователь вашего форума а может и с правами повыше, не со злого умысла не сделает такой глупости ?