Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Несколько вопросов о безопасности [2]
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
likvidator пишет:
- это так круто,то почему все крупные проекты юзают куки????
Вероятно, Вы не очень хорошо себе представляете механизм работы сессии. На деле, при открытии сессии, ключ доступа к ней отправляется клиенту, но данные сессии хранятся на сервере. Распространённым способом хранения ключа сессии является кука (та самая PHPSESSID как пример).
Теперь вспомните о том, как работает HTTP-протокол. При переходе по ссылке он отправит (на самом деле "он" - это, конечно, браузер, который следует HTTP-протоколу) в Request-запросе куки, относящиеся к домену того хоста, на который делается запрос. И, значит, ключ сессии будет передан таким образом через HTTP-запрос. Если соответствующая сессия открыта на сервере, то есть ключ распознался - клиент получает доступ к данным сессии.
Так вот, собственно, http_only означает, что ключ сессии может быть получен/передан/установлен только через HTTP-протокол, но не через иные средства. То есть, к примеру, нельзя будет оперировать с ним в javascript через document.cookie - любыми способами. Это приводит к невозможности чтения этой куки - и, значит, если имеется XSS-уязвимость, то злоумышленник не сможет прочитать ключ сессии, хранящийся в куки, и, значит, атака не будет успешной. Разумеется, такой функционал должен поддерживаться именно браузером - ведь именно он решает, допускать ли чтение куки или нет - поскольку исполнение того же javascript происходит в контексте браузера.
-----
likvidator
Отправлено: 27 Июня, 2013 - 11:43:13
Посетитель
Покинул форум
Сообщений всего: 416
Дата рег-ции: Март 2012
Помог: 4 раз(а)
[+]
EuGen пишет:
likvidator пишет:
- это так круто,то почему все крупные проекты юзают куки????
Вероятно, Вы не очень хорошо себе представляете механизм работы сессии. На деле, при открытии сессии, ключ доступа к ней отправляется клиенту, но данные сессии хранятся на сервере. Распространённым способом хранения ключа сессии является кука (та самая PHPSESSID как пример).
Теперь вспомните о том, как работает HTTP-протокол. При переходе по ссылке он отправит в Request-запросе куки, относящиеся к домену того хоста, на который делается запрос. И, значит, ключ сессии будет передан таким образом через HTTP-запрос. Если соответствующая сессия открыта на сервере, то есть ключ распознался - клиент получает доступ к данным сессии.
Так вот, собственно, http_only означает, что ключ сессии может быть получен/передан/установлен только через HTTP-протокол, но не через иные средства. То есть, к примеру, нельзя будет оперировать с ним в javascript через document.cookie - любыми способами. Это приводит к невозможности чтения этой куки - и, значит, если имеется XSS-уязвимость, то злоумышленник не сможет прочитать ключ сессии, хранящийся в куки, и, значит, атака не будет успешной. Разумеется, такой функционал должен поддерживаться именно браузером - ведь именно он решает, допускать ли чтение куки или нет - поскольку исполнение того же javascript происходит в контексте браузера.
так тс говорит,если нет xss,то зачем упираться в ограничения браузеров?
teddy
Отправлено: 27 Июня, 2013 - 11:44:37
Участник
Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013
Помог: 91 раз(а)
likvidator
ТС сторонник того, что бы передавать эти данные посредством http. А вы наоборот. Видимо, мы друг друга не понимаем. Вам EuGen уже написал, мне нечего повторять... отпостил он по поводу вашего возражения, при чем тут я ?
Покинул форум
Сообщений всего: 7187
Дата рег-ции: Февр. 2012
Помог: 353 раз(а)
teddy пишет:
Как можно запретить на уровне .htaccess доступ к существующим файлам/директориям на сервере?
Если нужен 404 - mod-rewrite вам в помощь. Однако проще заинуть все инклуды в папку на уровень выше DOCUMENT_ROOT и к ним стопудово никто не получит прямого доступа.
teddy пишет:
то передача сессионных куки будет проходить только по http и браузер session_id не получит
Если он не получит session_id - он не сможет оправить этот id серверу, а сервер не сможет опознать какая сессия используется.
session_id передается в любом случае, но с установкой этого параметра идентификатор нельзя будет передать, например, аяксом. Но не все браузеры поддреживают данное ограничение. (Так написано в мануале, если я правильно понял)
teddy пишет:
Если я отфильтрую числовые данные к примеру при помощи abs((int)$_GET['id']) или вместо int, intval, либо если это строка, то mysql_real_escape_string - стоит ли использовать ini_set('session.cookie_httponly', 1); ? Это я спрашиваю потому, что данная фильтрация исключает к примеру XSS атаки
это две совершенно разные атаки - XSS и SQL-injection. Фильтрация данных при записи в базу защищать должна именно от инъекций.
Так же интересует вопрос по поводу подготовленных запросов, зачем они нужны? Какую пользу они могут принести?
Если в течение одного http-запроса происходит несколько одинаковых запросов к БД имеет смысл сделать таие запросы подготовленными.
-----
EuGen
Отправлено: 27 Июня, 2013 - 11:47:51
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
http_only следует устанавливать. Суть в том, что никогда нельзя быть уверенным в том, что в веб-приложении нет уязвимостей. Дополнительную возможность защиты это обеспечит - по крайней мере для тех браузеров, которые этот флаг поддерживают. Если же браузер не распознаёт такой флаг - то будет попросту обычное поведение. Иными словами, если предположить, что 70% браузеров поддерживают такой режим (цифра взята с потолка, более предметно - здесь), то, устанавливая http_only, можно приобрести дополнительную защиту от XSS в 70% случаев. Это намного лучше, чем 0% случаев, и при этом оно даётся таким простым способом. Поэтому не вижу причины, чтобы не пользоваться такой возможностью.
-----
teddy
Отправлено: 27 Июня, 2013 - 11:49:52
Участник
Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013
Помог: 91 раз(а)
DelphinPRO пишет:
Однако проще заинуть все инклуды в папку на уровень выше DOCUMENT_ROOT и к ним стопудово никто не получит прямого доступа.
Да, я думал об этом, но для личного спокойствия хочу использовать оба варианта
DelphinPRO пишет:
Если он не получит session_id - он не сможет оправить этот id серверу, а сервер не сможет опознать какая сессия используется.
Сможет, но только посредством http, если вы конечно про браузер... А если браузер этого не поддерживает, тогда будет использоваться способ по умолчанию, тоесть через куки
DelphinPRO пишет:
это две совершенно разные атаки - XSS и SQL-injection. Фильтрация данных при записи в базу защищать должна именно от инъекций.
Да, это я в общем смысле спросил, может нарвусь на какие замечания )
А за статью спасибо, как только дочитаю ссылку от vanicon-а перейду на вашу ) (Добавление) EuGen
Да, честно говоря, я тоже так думаю... Как раз хотел получить более точный ответ, благодарю что смогли объяснить мне это окончательно в двух словах...
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Помог: 322 раз(а)
я тут увидел аргумент мол привязка к ip бред так как он бывает динамическим
ну надо же...в течении сессии он чтоли динамический???
вполне рабочий способ помешать краже...если конечно крадущий не под тем же ip
EuGen
Отправлено: 27 Июня, 2013 - 11:58:08
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
LIME пишет:
я тут увидел аргумент мол привязка к ip бред так как он бывает динамическим
ну надо же...в течении сессии он чтоли динамический???
вполне рабочий способ помешать краже...если конечно крадущий не под тем же ip
Нет, это не бред. Это один из хороших способов защитить кратковременный сеанс. Суть в том, что применимость данного подхода ограничивается длительностью сеанса и интервалом смены внешнего адреса. У некоторых ISP действительно бывает так, что адрес меняется с периодичностью порядка нескольких часов. Если продолжительность сеанса работы с веб-приложением превышает данный интервал (это нечасто, но всё же - бывает), то такой способ защиты может вызвать проблемы - от неудобств до серьёзных потерь. На практике описанный случай встречается нечасто, поэтому проверка IP-адреса при работе с авторизованной частью - как правило, хорошая практика. При этом следует помнить, что, так как пользователи часто находятся за NAT, то эта проверка не подойдёт для отсеивания запросов от другого пользователя, расположенного за тем же NAT
-----
esterio
Отправлено: 27 Июня, 2013 - 12:05:54
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
teddy пишет:
ini_set('session.cookie_httponly', 1);
Не юзаю. Не знаю как поведет себя ajax в таком случае. И еще настройка окружения - ЗАДАЧА СИСАДМИНА
teddy пишет:
Нужно ли ini_set('session.cookie_httponly', 1); указывать во всех файлах, где есть session_start() ? Или только в том файле, где происходит авторизация пользователей?
Правильней всего сделать единую точку входа. В вашем же случае сделайте файл(например bootstrap.php) и подключайте его во всех фалах. А внем уже делайте session_start и прочую инициализацию
teddy пишет:
Если я отфильтрую числовые данные к примеру при помощи abs((int)$_GET['id']) или вместо int, intval,
abs - по модулю. значит он не нужен. Если пользователь указал в строке id=-1 то выдаем 404. У вас же будет контент от id=1 а ето уже не правильно
(int) делает то же самое что и intval. разницы нету. Мне больше нравиться (int)
- Как запретить загрузку файлов на сервер, если типы загружаемых файлов не соответствуют требованиям. Например хочу позволять загружать только фотки, достаточно ли проверки на тип загружаемого файла? Если нет, то что нужно делать в этом случае?
Как сделать так, что бы кешировалось только то, что было обновлено
Ничего самому делать не надо. Браузер сам знает что и как ему кешировать. Есть только ручное кеширование ajax GET запросов(часто добавляют рандомный параметр) и таких страниц как "новые сообщения" на етом форуме
также рекомендую к ознакомению: http://nomagic[dot]ru/?p=123
teddy пишет:
Кеширование SQL запросов
рекомендую к прочтению
Цитата:
MySQL Оптимизация производительности (Бэрон Шварц, Петр Зайцев, Вадим Ткаченко, Джереми Д. Заводны, Арьен Ленц, Дерек Дж. Бэллинг)
Подготовленные выражения нужны для того что бы каждый раз не отправлять sql запрос целиком, а отправлять тока нужные параметры для определенного запроса, так сказать экономия трафика...
И много у Вас таких запроссов подряд. Данная особенность сомнительна в своей полезности, потому как запроссов мног и они все разные. Плюс только то что данные отделены от самого тела запросса и уже не нужно использовать escape_string
vanicon пишет:
Что за чушь, сейчас полно динамических ip, и т .п
likvidator пишет:
По поводу сессий: если вы боитесь кражи SSID,то можно привязывать его к ip
Ну как бы сменил ИП сначит новая сессия. На то она и сессия. Ето ж не "вечные куки"
likvidator пишет:
ini_set('session.cookie_httponly', 1)
- это так круто,то почему все крупные проекты юзают куки????
Походу Вы не знаете назнчение параметра. Он просто запрещает доступ к куке из JS не более
Покинул форум
Сообщений всего: 1462
Дата рег-ции: Апр. 2013
Помог: 91 раз(а)
esterio
Спасибо за советы и ссылки ) вопросов в принципе нет.. буду читать.
Надеюсь переварю всё сегодня... если нет, тогда держитесь Шутка )
Всем спасибо за помощь и советы
armancho7777777
Отправлено: 27 Июня, 2013 - 12:30:08
Активный участник
Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011 Откуда: Москва
Помог: 221 раз(а)
esterio пишет:
Не знаю как поведет себя ajax в таком случае.
Проверил: нормально.
EuGen
Отправлено: 27 Июня, 2013 - 12:32:21
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
esterio
AJAX - есть HTTP-запрос, а потому будет иметь доступ к таким куки. Строго говоря, конечная реализация зависит от конкретного браузера - и можно себе представить, что этот механизм не сработает, однако же современные браузеры обрабатывают это корректно. То есть, http-only куки будут представлены в XmlHttpRequest запросе к серверу.
-----
esterio
Отправлено: 27 Июня, 2013 - 12:36:19
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
armancho7777777, EuGen, teddy
Спасибо. Вроде и знал о таком параметре. Но стосовно сессионых кук как-то не думал. Сегодня постиг что-то новое для себя. И теперь с увереностю могу сказать что юзать данный параметр все такы стоит.
DelphinPRO
Отправлено: 27 Июня, 2013 - 13:36:36
Активный участник
Покинул форум
Сообщений всего: 7187
Дата рег-ции: Февр. 2012
Помог: 353 раз(а)
esterio пишет:
Не юзаю. Не знаю как поведет себя ajax в таком случае.
нормально. я в своем посте имел ввиду, что нельзя будет спереть куку и отправить ее по-тихому, аяксом например, на сервер злоумышленника.
-----
LIME
Отправлено: 27 Июня, 2013 - 13:37:58
Активный участник
Покинул форум
Сообщений всего: 10732
Дата рег-ции: Нояб. 2010
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
Главная
Помощь
Поиск
Пользователи
Форумы портала PHP.SU » PHP » Программирование на PHP » Вопросы новичков (Модераторы: OrmaJever, Саныч, Строитель)
Без описания
Шутка )
