Asp phpsessid buy

PHP PHPSESS > Задать вопрос

Есть Android приложение использующее Retrofit 2. Есть PHP сервер. (Не знаю, важно ли это)

Android пользователь авторизируется и получает PHPSESSID через SET-COOKIE.

Вопросы такие: Вариант 1 (HTTP): Если я использую протокол HTTP, то при передаче PHPSESSID его можно перехватить в исходном виде? Если да: его можно использовать для несанкционированного доступа от лица того, кто потерял PHPSESSID?

Вариант 2 (HTTPS): Если я использую протокол HTTPS, то при перехвате трафика PHPSESSID будет в зашифрованном виде? Если да: возможно ли его дешифровать?

Вопрос 3: PHPSESSID я использую для доступа к $_SESSION, так же передаю uuid на случай, если сессия пропадет, для ее восстановления из БД? Безопасно/правильно такое решение?

P.S. Касаемо HTTPS будем считать что все настроено и проверено. Т.к. вопрос настройки и использования HTTPS не относится к данной теме.

Правка на вопрос @andreymal (Не совсем понятно, о каком таком uuid речь): Есть MySql таблица в которой есть поля (user_id и uuid). uuid это «very_long_random unique_string_php_uniqid()». Если по каким либо причинам PHP сессия пропала (этот вопрос мною мало изучен, поэтому. ), что бы пользователь не проходил авторизацию заново, точнее если $_SESSION[‘id’] отсутствует, но из COOKIE пришел uuid, я ищу в таблице запись с таким uuid, и если нахожу, запускаю сессию и продолжаю работу скрипта.

Т.е. я думаю, если я безопасно по HTTPS могу передавать идентификатор сессии, то так же безопасно могу добавить туда UUID.

На такое решение меня направили участники сообщества StackOverflow в другом моем вопросе PHP REST API Авторизация для Android

2 ответа 2

Вариант 1. Да, перехват вполне возможен, так как все данные в HTTP передаются в открытом виде.

Вариант 2. Будет в зашифрованном виде. Расшифровать можно, но очень сложно. В стандартных условиях можно считать, что не возможно.

Вариант 3. Если uuid достаточно уникален и время его жизни ограничено (uuid для юзера иногда перегенеривается). То такую схему можно считать вполне безопасной. Сравнимую по устойчивости с тем же механизмом сессий.

Спешу вас огорчить, но при разрыве соединения следующая сессия у PHP будет иной для того же клиента. Например, если не закрывая браузер закрывая вкладки подключаться к сайту, то PHP сессия останется прежней. Но стоит закрыть сам браузер и открыв его повторно заново зайти на сайт, то сессия уже будет иной. Как обстоят дела с подключениями из иных программ не знаю. Поэтому сессия в Cookies должна использоваться как ID для чтения из базы дополнительный параметров сессии.

Если вы хотите «помнить» пользователей некоторое время, например 1-2 дня, то вам необходимо генерировать собственную сессию для каждого клиента с дополнительными параметрами. Эта сессия должна включать информацию о клиенте — User-Agent, версия ОС и т.д. В таком случае вам не обязательно использовать HTTPS протокол, т.к. даже если будут скомпроментированы Cookies данные пользователя (не говоря о реальном перехвате шифрованного трафика), то при проверке сессии из Cookies и сгенерированной сессии по информации о клиенте вы легко определите скомпроментированность сессии.

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

Итого: способов защитить сессию от перехвата и запоминания пользователя неограниченное количество. Всё зависит от вашей фантазии. Самое главное, что у вас есть доступ к Cookies и информации о клиенте (кроме IP адреса).

Примеров очень много. Вы можете с пристрастием поковыряться в «нижнем белье» любого сайта зайдя в раздел управления Cookies браузера чтобы посмотреть какие методы используют крупные порталы имея перед глазами список данных.

HTTP сессия. Session. Состояние сеанса. Работа с сессиями в ASP.NET MVC

Давайте рассмотрим такое понятие как сессия (HTTP-сессия, Session). Или по-другому, сеанс пользователя. Почему важно понимать механизм работы сессий. И посмотрим, как можно работать с состояниями сеансов на платформе ASP.NET.

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

Одной из основных особенностей протокола HTTP является то, что он не обязывает сервер сохранять информацию о клиенте между запросами, то есть идентифицировать клиента. Это так называемый stateless-протокол. Связь между клиентом и сервером заканчивается как только завершается обработка текущего запроса. Каждый новый запрос к серверу подразумевается как абсолютно уникальный и независимый, даже если он был отправлен повторно от одного и того же источника.

Что, если оставить stateless-природу протокола HTTP и не идентифицировать пользователя? Без состояний сеанса можно легко обойтись, если на вашем сайте представлена статичная (обезличенная) информация, например, новостная статья, состоящая из текста и изображений. В таком контексте совершенно необязательно ассоциировать несколько запросов с одним пользователем. Ведь содержание статьи никак не изменится, будь то десять запросов с одного устройства, либо десять запросов от разных людей с разных устройств.

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

Вот как раз в таких ситуациях, когда требуется персонализировать запросы от одного клиента, мы будем использовать сессии.

Когда клиент впервые передает персональные данные в запросе, на сервере создается новая сессия для этого клиента. В период времени жизни сессии все запросы от этого клиента будут однозначно распознаны и связаны с ним. По истечении этого времени связь с клиентом будет потеряна, и очередной запрос от него будет обрабатываться как абсолютно уникальный, никак не связанный с предыдущими.

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

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

скрытые поля на HTML-форме (hidden form fields)
куки (cookies)
сессия (session, session State)

Читать еще: Неформальные средства защиты информации

Попробуем их реализовать, используя платформу ASP.NET. Давайте кратко рассмотрим первые два механизма, и особое внимание уделим третьему, как более надежному, удобному и безопасному.

Скрытые поля на HTML-форме (hidden form fields)

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

В данном примере мы на первой html-форме получаем имя пользователя. Далее в контроллере в методе Forms2() мы извлекаем это значение из коллекции Form и передаем в представление посредством объекта ViewBag. В этом представлении генерируется код новой формы и в скрытом поле сохраняется имя пользователя. Таким образом, значение имени пользователя будет передано уже на третью формы вместе с дополнительной информацией — значением поля с именем «foodName». И так далее.

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

Во-первых, этот вариант не будет работать, если html-формы на наших страницах статичны, то есть жестко закодированы. И чтобы это исправить, чтобы повлиять на html-разметку мы прибегаем к помощи какой-нибудь серверной технологии (в данном случае механизм ViewBag);
Это безопасность. Хоть вводимые нами данные не передаются через url-параметры в адресной строке и визуально не видны на странице, мы с легкостью можем их получить или подменить или удалить или украсть просто изучив исходный код страницы или структуру запроса;

Куки (cookies)

В данном подходе мы не храним сессионные данные непосредственно на форме, вместо этого используется стандартный механизм работы cookies между клиентом и сервером. В cookies и хранятся все пользовательские данные.

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

Серверный механизм управления сессией (Session, SessionState)

Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.

При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:

Абсолютно для каждого нового запроса на сервер (неважно, разные это клиенты или один) ASP.NET генерирует уникальный идентификатор сессии.
Идентификатор сессии представляет собой случайно сгенерированное число, закодированное с помощью специального алгоритма в строку длиной 24 символа. Строка состоит из литералов от A до Z в нижнем регистре, а также чисел от 0 до 5. Пример идентификатора — hjnyuijl1pam3vox2h5i41in
Если в течение текущего запроса данные клиента НЕ сохраняются для дальнейшей работы с ним, то и время жизни сессии этого клиента заканчивается (фактически не начавшись). При этом ранее сгенерированный идентификатор сессии становится недействительным (так как не был использован). В ответ на такой запрос клиент не получает ничего, чтобы связало его с новой сессией.
Если же данные клиента (например, имя, адрес доставки товара) сохраняются на сервере, ASP.NET связывает сохраненные данные с ранее сгенерированным идентификатором сессии. Далее создается специальная сессионная куки, и в нее записывается также этот идентификатор. Эта куки добавляется в ответ на запрос и сохраняется в браузере клиента. Таким образом, создается связь клиента и его персонализированной информации на сервере. Новая сессия для данного клиента создана.
При каждом следующем запросе клиент передает на сервер персональный идентификатор сессии через куки. Сервер сопоставляет идентификаторы и «узнает» клиента в рамках текущей сессии.
До тех пор пока клиент передает свой персональный ключ, сессия считается активной. Сессия может закончиться по разным причинам, например, вручную на стороне сервера или по истечении какого-то установленного времени (таймаут).

От теории перейдем к практике. Давайте запрограммируем данный алгоритм и посмотрим, как он выполняется. Для этого используем специальный класс HttpSessionState . При работе в контроллере можно воспользоваться свойством HttpContext.Session . Работать с сессией очень просто, как с любой NameValueCollection :

В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.

В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:

В процессе следующего запроса от этого клиента давайте прочитаем его ранее сохраненное имя из сессии. Также принудительно завершим сессию. Работа с этим клиентом закончена, например, все данные обработаны и товар отправлен.

Как видно, работать с сессиями очень просто и удобно. Большинство процессов, связанных с обработкой сессии, происходит автоматически в фоновом режиме. Естественно, разработчик может вмешаться на любой стадии обработки сессии и внести свои коррективы.

Давайте посмотрим на наиболее интересные свойства и методы класса HttpSessionState , которые чаще всего используются в работе:

Item[index] – возвращает элемент данных по его индексу
Item[key] – возвращает элемент данных по его ключу
Remove(index) – удаляет элемент данных по его индексу
Remove(key) – удаляет элемент данных по его ключу
Clear() – удаляет все данные
Count – возвращает общее количество элементов данных для текущей сессии
Abandon() – принудительно завершить сессию
SessionID — возвращает идентификатор текущей сессии
IsNewSession – возвращает true если сессия была создана в рамках текущего запроса
Timeout – возвращает число минут, допустимое между запросами, перед тем как сессия завершится по причине таймаута (по умолчанию, 20 минут)

Изменить настройки для сессии можно либо программно в коде посредством членов класса HttpSessionState , либо через конфигурацию приложения (файл web.config). Например:

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

Asp phpsessid buy

Задал вопрос в суппорт хостера:
—-
Как сделать, чтобы от ссылки вида http://alt-shop.ru/index.php?category ?
Раньше это решалось прописыванием в .htaccess следующего:

php_value session.use_trans_sid 0
php_value session.session.use_only_cookies 1

Но после переезда Вами на новую платформу из-за этого сайты перестали работать и эти строки пришлось закомментарить.
—-

Получил от них следующий ответ:
—-
появляется ли строка или нет зависит от того, включены ли у пользователя куки на машине. Если нет-появляется строка. Убрать можно только в глобальных установках сервера, что мы сделать не можем, поскольку у многих отключены куки, а без сессии не будут работать 50% форумов и 90% порталов.
—-

telnet www.alt-shop.ru 80
Trying 70.84.76.254.
Connected to alt-shop.ru.
Escape character is ‘^]’.
GET / HTTP/1.1
Host: www.alt-shop.ru

Сайт выдает PHPSESS >

1. проверка на логин. Если пользователь не залогинен, то id не давать. Я не программист, но в phpbb это делается так.

Найти в папке форума файл includes/sessions.php

if ( $userdata[‘session_user_ > $S . $session_id;
> else <
$S ;
>

как избавиться от идентификатора сессии в phpBB (http://www.ebanners.ru/viewtopic.php?t=66)

2. если хочется давать сессию всем, а не только залогиненым пользователям, то возможно лучше проверять user agent по списку роботов и им сессии не давать.

Как писал Nikolai Popkov
варианты

1. проверка на логин. Если пользователь не залогинен, то id не давать. Я не программист, но в phpbb это делается так.

Найти в папке форума файл includes/sessions.php

Так это в phpbb.

Как писал Aleks Sychev
Задал вопрос в суппорт хостера:
—-
Как сделать, чтобы от ссылки вида http://alt-shop.ru/index.php?category ?
Раньше это решалось прописыванием в .htaccess следующего:

php_value session.use_trans_sid 0
php_value session.session.use_only_cookies 1

Поставь это (только пример!):

# If you are using Apache 2, you have to use
# instead of .
php_value register_globals 0
php_value track_vars 1
php_value short_open_tag 1
php_value magic_quotes_gpc 0
php_value magic_quotes_runtime 0
php_value magic_quotes_sybase 0
php_value arg_separator.output «&»
php_value session.cache_expire 200000
php_value session.gc_maxlifetime 200000
php_value session.cookie_lifetime 2000000
php_value session.auto_start 0
php_value session.save_handler user
php_value session.cache_limiter none
php_value allow_call_time_pass_reference On

На моем хостинге все работает, и портал и форумы. Должно помочь.

Как писал Andreyka

Поставь это (только пример!):

На моем хостинге все работает, и портал и форумы. Должно помочь.
А куда все это надо поставить? Если в .htaccess, то не помогает. Сайт перестает работать.

Сайт выдает PHPSESS > Все сдвинулось, я-же в той теме писал. Просто некоторое время назад хостер что-то у себя изменил и пришлось эти строки из .htaccess изъять, поэтому сессии и появились опять.
Как исправить проблему я так и не понял.

В общем поговорил я с программистом, который к мом сайтам много чего хорошего сделал, и вот что он мне сказал (переписка по аське, его ник изменен на *******. некотрые высказывания, с моей по крайней мере стороны, не совсем точны из-за того, что время позднее уже):

————-
******** (3:19) :
Тебе хостер правильно сказал
******** (3:19) :
у меня ни в обном браузере нет phpsid
******** (3:20) :
потому что у меня включены полностью кукисы
******** (3:21) :
если кукисы будут отключены то твой магазин работать не будет
******** (3:21) :
Это сейчас на всех системах оно через аштарики не отключается

Aleks Sychev (3:21) :
ну и что?
еще раз повторю: мне надо, чтобы ботам поисковиков не отдавались ссылки в таком виде!
Aleks Sychev (3:22) :
ты на форуме внимательно прочитал? перечитай еще раз.

******** (3:30) :
а разве ботам отссылаеться?

Aleks Sychev (3:32) :
http://www.yandex.ru/yandsearch?text=akai+8805&stype=www
номер 3

******** (3:45) :
смотрю
******** (3:52) :
PHPSESSID генериться полностью на 100% сервером
******** (3:52) :
в скриптах нет генерации, все скриптсы пересмотрел
******** (3:54) :
PHPSESSID генериться только при первой загрузки страницы
******** (3:55) :
это как правило

Aleks Sychev (3:56) :
index.php
строка 523
не оно?

******** (3:57) :
а хостер у тебя сволоч

Aleks Sychev (3:57) :
я знаю. просто альтернативы пока не нашел

******** (3:57) :
еще порядочная, он столько ограничений на РНР наложил
******** (3:59) :
session_start();
это стратуеться сессия
если она стартуесться у человека в первый раз то она и создает PHPSESSID если у человека есть кукисы то больше не появляется, а что тебя так волнует этот PHPSESSID
******** (4:01) :
у хостера отрублено
Registered serializer handlers php php_binary wddx
включаеться только через сервер

Aleks Sychev (4:02) :
да мне наплевать, что у человека есть.
мне надо, чтобы БОТАМ ПОИСКОВИКОВ ОНИ НЕ ВЫДАВАЛИСЬ.
поисковики банят те сайты, которые выдают сессии, т.к. это создает бесконечное кол-во одинаковых страниц у них в памяти.

******** (4:03) :
у меня на всех сайтах есть этот сид в поисковиках, и проблем небыло, никто не блокирует кто тебе такую чушь сказал
******** (4:04) :
блокируют совсем другое, поисковый спам! но ни как не сессии

Aleks Sychev (4:05) :
https://searchengines.guru/showthread.php?s=&thread >
******** (4:07) :
та же история про ранк гугла
******** (4:08) :
найди хоть один дубликат своей ссылки
******** (4:08) :
все в одном экземпляре
******** (4:09) :
поисковики совсем не глупые, они знают что такое сессии, и про поиске просто просматривают страницы заного нет страницы удаляют

Aleks Sychev (4:10) :
надоело мне с тобой бороться.
зарегся на форуме и напиши про все это, в топике https://searchengines.guru/showthread.php?s=&thread > посмотрим, что тебе на это скажут.
я спать пошел.

******** (4:11) :
а что со мной то бороться я не вступаю в перепалки тугодумами, это бессмысленно

Aleks Sychev (4:12) :
ты считаешь тугодумами кого — меня или людей, которые уже достаточно долго профессионально занимаются оптимизацией?

******** (4:12) :
блокируют совсем не за это, а за поисковый спам, забыл как он называеться, скрипты которые генерят до 1000000 страниц
******** (4:13) :
кто занимаеться поисковой оптимизацией и не знает про сессии в поисковиках извини я к этому человеку никогда не доверю делать оптимизацию
******** (4:14) :
я очень сомниваюсь в их профессионализме
******** (4:15) :
дорвеи. вот за них блокируют
————-

Asp phpsessid buy

php_value session.use_trans_sid 0
php_value session.session.use_only_cookies 1

telnet www.alt-shop.ru 80
Trying 70.84.76.254.
Connected to alt-shop.ru.
Escape character is ‘^]’.
GET / HTTP/1.1
Host: www.alt-shop.ru

Сайт выдает PHPSESS >

1. проверка на логин. Если пользователь не залогинен, то id не давать. Я не программист, но в phpbb это делается так.

Найти в папке форума файл includes/sessions.php

if ( $userdata[‘session_user_ > $S . $session_id;
> else <
$S ;
>

как избавиться от идентификатора сессии в phpBB (http://www.ebanners.ru/viewtopic.php?t=66)

Как писал Nikolai Popkov
варианты

1. проверка на логин. Если пользователь не залогинен, то id не давать. Я не программист, но в phpbb это делается так.

Найти в папке форума файл includes/sessions.php

Так это в phpbb.

php_value session.use_trans_sid 0
php_value session.session.use_only_cookies 1

Поставь это (только пример!):

На моем хостинге все работает, и портал и форумы. Должно помочь.

Как писал Andreyka

Поставь это (только пример!):

******** (3:30) :
а разве ботам отссылаеться?

Aleks Sychev (3:32) :
http://www.yandex.ru/yandsearch?text=akai+8805&stype=www
номер 3

Aleks Sychev (3:56) :
index.php
строка 523
не оно?

******** (3:57) :
а хостер у тебя сволоч

Aleks Sychev (3:57) :
я знаю. просто альтернативы пока не нашел

******** (4:11) :
а что со мной то бороться я не вступаю в перепалки тугодумами, это бессмысленно