现实检查：会话劫持 [英] Reality Check: Session Hijacking

问题描述

告诉我这里的断言是否错误：


防止会话劫持的唯一方法是永远不要存储

身份验证信息（例如姓名/在会话中。密码）

好​​吧，永远不要从你从

会话中获得的信息中验证用户。站点上的每个安全应用程序必须向用户挑战名称

和密码，每次用户访问它时（不只是一次

然后将其存储在会话中） ）。如果一个安全的应用程序是多页的，那么你必须只在每个页面之间的隐藏表单字段中传递会话数据，在POST上通过https传递表格。


这是我的主张。是对的吗？如果您不同意，请考虑这个

场景：


1.用户通过http访问网站的主页。该网站记得

他，欢迎，乔。换句话说，有一个他的会话ID，在一个纯文本cookie中的不安全的http上旅行

，任何人都可以使用

数据包嗅探器阅读。


2.用户去编辑一些私人数据，例如他的姓名和地址

或cc号或其他什么，通过https，并且不会因为他的

名称/密码，因为该网站知道他的会员是谁。


3.以上是安全漏洞。有人使用数据包嗅探器可以看到他的会话ID，以及有关他的请求的所有其他内容 -

浏览器，IP地址等，以纯文本形式显示通过http发出请求

。然后，嗅探器可以向显示其私人信息的同一个应用程序发出https请求

。

嗅探器并不知道用户的登录名/密码，而且他不需要b $ b，他从未被要求过。他需要的只是sesid cookie。


如果你同意，那么从zend网站看看这个，并不是因为
从根本上错了吗？ ：

http：// www .zend.com / zend / spotlight / s ... y.php #Hading5

-------------------- ----------------------

签名：

永远不要购买newsfeed.com的服务。我是一个付费用户，但是

我正在使用谷歌发帖子，所以我可以避免他们该死的

广告出现在我发的每个帖子中。 />
------------------------------------------

Tell me if my assertion is wrong here:

The only way to prevent session hijacking is to NEVER store
authentication information (such as name/password) in the session.
Well, to never authenticate a user from information you got from the
session. Each secure app on a site must challenge the user for name
and password, each and every time the user accesses it (not just once
and then store it in the session). If a secure app is multi-page,
then you must only pass session data in hidden form fields between
each page, on forms that POST over https.

That''s my assertion. Is that right? If you disagree, consider this
scenario:

1. User goes to a web site''s homepage, over http. The site remembers
him, Welcome, Joe. In other words, there''s his session ID, travelling
over insecure http in a plain text cookie that anyone can read with a
packet sniffer.

2. User goes to edit some private data, such as his name and address
or cc number or whatever, over https, and IS NOT CHALLENGED for his
name/password, because the site knows who he is from his session.

3. The above is security breach. Someone with a packet sniffer could
see his session id, as well as everything else about his requests-
browser, ip address, etc, in plain text, when he was making requests
over http. Then with that, the sniffer could make an https request to
the same application that displays his private information. The
sniffer doesn''t know the user''s loginname/password, and he doesn''t
have to, he''s never asked for it. All he needs is the sesid cookie.

If you agree, then look at this from the zend site, and isn''t it
fundamentally wrong?:

http://www.zend.com/zend/spotlight/s...y.php#Heading5
------------------------------------------
Signature:
Never buy the services of newsfeed.com. I am a paying customer but
I''m using google to post messages, so that I can avoid their damn
advertisement showing up in every post I make.
------------------------------------------

推荐答案

mrbog< dt ****** @ hotmail.com>写道：

mrbog <dt******@hotmail.com> wrote:

防止会话劫持的唯一方法是永远不要在会话中存储
身份验证信息（如名称/密码）。


错误。劫持是会话中包含的数据的独立。

好​​吧，永远不要根据你从
会话获得的信息来验证用户。站点上的每个安全应用程序必须向用户提出名称
和密码，每次用户访问它时（不只是一次
然后将其存储在会话中）。


Ehhh，这是会话主要用于的事情之一（

阻止）

如果一个安全的应用程序是多页，那么你必须只在每个页面之间的隐藏表单字段中传递会话数据，在POST over https的表单上。


所以不要发送一次并且在会话中存储一些你需要的东西

一遍又一遍地发送易受攻击的数据？ （注意我说

而不是登录/密码）。

那是我的断言。是对的吗？如果您不同意，请考虑以下情况：

1.用户通过http访问网站的主页。该网站记得他，欢迎，乔。换句话说，有一个他的会话ID，在纯文本cookie中的不安全的http旅行，任何人都可以使用
数据包嗅探器阅读。


SessionIDs只不过是随机数据（标准PHP会话

字符串是128位六弦（32chars））。

2用户可以通过https编辑一些私人数据，例如他的姓名和地址
或cc号码等等，而且不会因为他/她的名字/密码而被挑战，因为该网站知道他是谁他的会议。

3.以上是安全漏洞。有人使用数据包嗅探器可以在纯文本中查看他的会话ID，以及其他关于他的请求的内容 -
浏览器，IP地址等，当他通过http发出请求时。然后，嗅探器可以向显示其私人信息的同一应用程序发出https请求。
嗅探器不知道用户的登录名/密码，而且他没有必要，他从未被要求过。他需要的只是sesid cookie。


正确。所以这必须要防止。此时，对于劫持者读取用户数据没有太多可以做的事情，只有扼杀者改变数据才能防止这种情况发生。简单的方法

这是要求在这些点上输入个人识别码，只需要通过安全（例如ssl）连接就可以获得需要PIN码的外线交易。

如果你同意，那么从zend网站看看这个，并不是从根本上错了吗？：

http://www.zend.com/zend/spotlight/s...y.php #Heading5

The only way to prevent session hijacking is to NEVER store
authentication information (such as name/password) in the session.
Wrong. Hijacking is independend of data contained in a session.
Well, to never authenticate a user from information you got from the
session. Each secure app on a site must challenge the user for name
and password, each and every time the user accesses it (not just once
and then store it in the session).
Ehhh, that is one of the things sessions are mainly used for (to
prevent)
If a secure app is multi-page, then you must only pass session data in
hidden form fields between each page, on forms that POST over https.
So instead of sendig it once and storing something in session you want
to send the vulnerable data over and over again? (Note that I said
something instead of login/password).
That''s my assertion. Is that right? If you disagree, consider this
scenario:

1. User goes to a web site''s homepage, over http. The site remembers
him, Welcome, Joe. In other words, there''s his session ID, travelling
over insecure http in a plain text cookie that anyone can read with a
packet sniffer.
SessionIDs are nothing more than random data (standard PHP session
string is a 128bit hexstring (32chars)).
2. User goes to edit some private data, such as his name and address
or cc number or whatever, over https, and IS NOT CHALLENGED for his
name/password, because the site knows who he is from his session.

3. The above is security breach. Someone with a packet sniffer could
see his session id, as well as everything else about his requests-
browser, ip address, etc, in plain text, when he was making requests
over http. Then with that, the sniffer could make an https request to
the same application that displays his private information. The
sniffer doesn''t know the user''s loginname/password, and he doesn''t
have to, he''s never asked for it. All he needs is the sesid cookie.
Correct. So this has to be prevented. At this point there isn''t much one
can do about the hijacker reading the userdata, only thing that has to
be prevented is the hijacker changing data, The most simple way to do
this is to ask for a PIN at these points, offcourse transactions that
ask for a PIN should only be done over secured (eg ssl) connections.
If you agree, then look at this from the zend site, and isn''t it
fundamentally wrong?:

http://www.zend.com/zend/spotlight/s...y.php#Heading5

我没有看到任何错误。

I dont'' see anything wrong with this.

authdata不包含

用户/密码组合，它是假的或数组（包含

登录名）。


-


Daniel Tryba

authdata doesn''t contain a
user/password combo, it''s either false or an array (containing
loginname).

--

Daniel Tryba

" Daniel Tryba&q UOT;写了

"Daniel Tryba" wrote

如果一个安全的应用程序是多页的，那么你必须只在每个页面之间的隐藏表单字段中传递会话数据。 /> POST over https。

If a secure app is multi-page, then you must only pass session
data in hidden form fields between each page, on forms that
POST over https.

所以不要发送一次并在会话中存储一些你希望
一次又一次地发送易受攻击的数据的内容吗？

So instead of sendig it once and storing something in session you want
to send the vulnerable data over and over again?

<单个（甚至是GET）参数可能很有用：只需在会话和该参数中存储一些随机值

，然后比较两者。这使得随机的

会话劫持（其中一个人会试图猜测一个会话ID而没有任何

嗅探，这确实很困难）要困难得多。当

刷新每个页面的随机值时，这可用于控制后退按钮使用

或避免在提交按钮上多次点击（但

不是与会话或安全相关的。）


Adriaan

A single (even GET) parameter can be usefull: simply store some random value
in both session and that parameter, and compare the two. This makes random
session hijacking (where one would try to guess a session id without any
sniffing, which indeed is difficult) a lot more difficult. And when
refreshing the random value for each page this can be used to control the
use of the Back button or avoiding multiple hits on a submit button (but
that is not session or security related).

Adriaan

这篇关于现实检查：会话劫持的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！