Вход в систему/сеансовые куки, Ajax и безопасность

1. cookie должен быть сгенерированной серверной стороной, потому что сессия связывает клиент с сервером, и поэтому маркерный обмен должен пойти от сервера до клиента на некотором этапе. Действительно не было бы полезно генерировать клиентский cookie, потому что клиент недоверяемая удаленная машина.

   возможно установить cookie во время вызова Ajax. К серверу (и сеть) вызов Ajax является просто HTTP-вызовом, и любой ответ HTTP сервером может установить cookie. Таким образом да, возможно инициировать сессию в ответ на вызов Ajax, и cookie будет сохранен клиентом как нормальный.

   Так, можно использовать Ajax, чтобы сделать, вход в систему процесса в том же состоял в том, поскольку Вы, возможно, просто полагались на POST от формы на странице. Сервер будет видеть их тот же путь, и если сервер установит cookie, то браузер сохранит его.

   В основном, клиентский JavaScript никогда не должен быть в состоянии знать значение cookie (и для безопасности лучше, если это не делает, который может быть достигнут с помощью "httponly" расширения cookie, которое соблюдают недавние браузеры). Обратите внимание, что дальнейшие HTTP-вызовы от клиента к серверу, являются ли они нормальными запросами страницы или они - запросы Ajax, будет включать тот cookie автоматически, даже если он отметил httponly и почести браузера то расширение. Ваш сценарий не должен 'знать' о cookie.

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

2. (см. 1. Я сортирую объединенных их)

3. , Учитывая, что cookie установлен сервером в его заголовках ответа HTTP, да это надежно. Однако для создания этого перекрестным браузером совместимый все еще необходимо удостовериться, что вход в систему возможен, когда Ajax недоступен. Это может потребовать реализации альтернативы, которая замечена только, когда нет никакого JavaScript или если Ajax не доступен. ( Примечание: теперь в 2014 Вы не должны больше волноваться о поддержке браузера для Ajax ).

4. Это не изменило бы безопасность. Не было бы никакой потребности в нем, за исключением того, что я видел скрытый iframes, используемый прежде, чтобы 'моделировать' Ajax прежде - т.е. выполнить асинхронные вызовы к серверу. В основном однако Вы делаете это не имеет значения, это - настройка сервера cookie, и клиент примет и возвратит cookie, делает ли это это Ajax или нет.

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

Ответ обновил сентябрь 2014