会话被盗？ [英] Session theft?

问题描述

有没有人知道讨论会议中涉及的问题的好资源

盗窃？我读了一对，但没有一个能真正解决这个问题，而不是承认这是一个问题。你似乎无法为b
做很多事情。


是否有人有一些经过试验和测试的措施来阻止会话<是不是已经内置到PHP中的
盗窃？那么，什么措施

_are_已经内置到PHP中？ PHP4

和PHP5之间是否存在显着差异？


损害限制练习，例如在执行

之前重新进行身份验证"重要"行动，这不是我真正关心的问题。我有管理系统

其中几乎每个动作都足够关键，理想情况下我会在每个页面请求上重新验证
，但这不是实用。


相反，我需要确保一开始几乎不可能偷一个会话

键。它不一定是100％安全的，因为没有，

但是我需要它非常接近，并且确切地知道风险在哪里。


此外，对于存储会话密钥的

，/针对cookie和查询字符串的参数是什么？把它放在查询字符串中的明显风险

是有人可以在屏幕上看到它，但我想我可以使用框架和一些脚本阻止那个

。我可以在客户端要求特定的要求，例如

JavaScript和cookie，因为安全性比兼容性要好得多。


- 罗伯特

解决方案

Robert Tweed写道：

有没有人知道讨论所涉问题的好资源在会议中被盗？我读过一对，但除了承认它是一个问题之外，没有一个能真正解决这个问题;你似乎没有能够做很多事情。

有没有人有一些经过试验和测试的措施来防止会话被盗，这些都不是还没有内置到PHP中？那么，什么
测量_are_已经内置到PHP？ PHP4和PHP5之间是否存在显着的差异？

损害限制练习，例如在执行重要之前重新进行身份验证。行动，这不是我真正关心的问题。我有管理系统几乎每个动作都非常关键，理想情况下我会在每个页面请求上重新进行身份验证，但那只是不可行的。
，对于存储会话密钥的/针对cookie和查询字符串的争论是什么？把它放在查询字符串中的明显风险是有人可以在屏幕上看到它，但我想我可以使用框架和一些脚本来阻止它。我可以在客户端要求
特定要求，如JavaScript和cookie，
因为安全性比兼容性更重要。

如果你使用一个足够长的会话代码，用在

查询字符串中，没有人能够通过

查看地址栏来记住它但是有可能以其他方式找到查询字符串

，例如寻找网址的网络嗅探器，以及报告网址的
Googe / Yahoo / Alex / etc工具栏回到服务器。


如果您使用cookies，工具栏将无法使用它们，但是某人

嗅探他们仍然可以获得它们。


如果您使用cookie /查询字符串和IP地址的组合，用户

可能通过代理或其他方式访问网站>
IP地址随每个请求而变化，或者嗅探

会话的人可能在网络中工作使用相同的IP地址，仍然可以获得

in。所以这种方法也必然会失败。


唯一100％可靠的方式我可以看是通过SSL运行会话。

这样，在客户端和浏览器之间加密的查询字符串中传递的任何cookie或会话都是

。


-

Chris Hope - 电动工具箱 - http://www.electrictoolbox.com/

" Chris Hope" < BL ******* @ electrictoolbox.com>在消息中写道

news：cp ********** @ lust.ihug.co.nz ...

如果你使用一个足够长的会话代码，用在
查询字符串中，没有人能够通过
查看地址栏来记住它


几乎没有什么可以依靠的。有人可以简单地走到一台PC，即无人看管
并将其写下来。或者他们可以使用网络摄像头。复制你可以看到的东西非常简单。

但是可以通过其他方式找到该查询字符串，例如网络嗅探器寻找网址，以及Googe / Yahoo / Alex / etc工具栏，它们将网址报告回服务器。


我也同意这是一个更严重的问题。这些也可以访问cookies

，虽然我不知道它们实际上是什么_does_ store。另一个值得关注的是跨站点脚本攻击，但这不是我所知道的非常好的事情。我不确定它是否是唯一可能的东西

其中JavaScript沙箱在特​​定浏览器中被破坏，或者它是否是可以实现的东西
在完全没有错误的浏览器中也是如此。

如果你使用cookie /查询字符串和IP地址的组合，用户可能会通过代理或其他方式访问网站/> IP地址随着每个请求而变化，或者嗅探
会话的人可能在使用相同IP地址的网络中，并且仍然可以进入。因此该方法也必然会失败。


这是真的，这就是为什么我不打算完全依赖IP检查。

这绝对是一个很好的衡量标准工作，所以它是什么

我将作为我的库的一部分选择，并打开所有

高安全性网站。在这些情况下，没有任何理由让任何人接受网站在请求之间更改其IP地址。


无法解决问题同一网络上的人共享一个明显的IP地址，但至少这是一个额外的难度;它限制了同一组织内的会议盗窃。如果有一些额外的

方法来解决这个问题，那么这将涵盖所有基础。

我能看到的唯一100％可靠的方法是通过运行会话SSL。
这样，在客户端和浏览器之间对查询字符串中传递的任何cookie或会话进行加密。

不会停止人们在浏览器端窃取他们，这通常是会话盗窃的问题。无论运输是否安全，所有上述盗窃技术都将起作用。显然，对于实际需要此安全性的系统，由于数据的潜在敏感性，无论如何都会通过SSL连接

。还有一些需要防止的其他攻击。甚至可能还有一些我还没想过的b
攻击。


- Robert

Robert Tweed写道：

" Chris Hope" < BL ******* @ electrictoolbox.com>在消息中写道
新闻：cp ********** @ lust.ihug.co.nz ...

如果你使用足够长的时间在
查询字符串中使用的会话代码没有人能够通过
查看地址栏来记住它

几乎没有什么可以依靠的。有人可以简单地走到一台无人看管的电脑上并将其写下来。或者他们可以使用
网络摄像头。复制你可以看到的东西非常简单。

但是可以通过其他方式找到该查询字符串，例如寻找网址的网络嗅探器，和/或Googe / Yahoo / Alex / etc工具栏，它们将网址报告给服务器。

我也同意这是一个更严重的问题。这些也可以访问
cookies，虽然我不知道它们实际上是什么_does_
存储。另一个问题是跨站点脚本攻击，但这不是我所知道的很多东西。我不确定它是否只有在特定浏览器中JavaScript沙箱被破坏的情况下才有可能，或者它是否可能是完全错误的？ - 免费浏览器。

如果您使用cookie /查询字符串和IP地址的组合，
用户可能通过代理或其他方法访问该网站他们的IP地址随着每个请求而变化，或者嗅探会话的人可能在使用相同IP地址的网络中并且仍然可以进入。因此该方法也必然会失败。 / blockquote>

这是真的，这就是为什么我不打算单纯依靠IP检查。它肯定仍然是一个很好的衡量标准，所以
这将是我作为我的库的一部分可选择的东西，并且
为所有高安全性站点启用。在这些情况下，没有任何理由让任何人访问该网站的IP地址在请求之间发生变化。

无法解决人们的问题。相同的网络共享一个明显的IP地址，但至少它是一个额外的难度;它将会话盗窃限制在同一个组织内。如果有一些额外的方法来解决这个问题，那么这将覆盖所有的基础。

我能看到的唯一100％可靠的方法是通过SSL运行会话。这样，在客户端和浏览器之间对查询字符串中传递的任何cookie或会话进行加密。

不会阻止人们在浏览器端窃取它们，这是
一般是会话被盗的问题。无论运输是否安全，所有上述的盗窃技术都会起作用。
显然，对于实际需要这种安全性的系统，无论如何，
连接都将通过SSL进行，因为潜在的
数据的敏感性。还有其他需要防止的攻击。可能还有一些我还没有想到的攻击。<​​/ blockquote>


如果你使用cookie而不是查询字符串传递会话那么

至少让得到会话代码变得有点棘手。我不是

甚至可以肯定在IE或Mozilla中你可以得到一个会话的当前值

cookie（但我*知道你可以在Konqueror中）。


我亲自使用过cookie和IP地址的安全会话

限制技巧之前，使用与你相同的reaasoning

访问系统的人将始终使用相同的

IP地址，来自该IP地址的任何人将成为

有效用户。 />

-

Chris Hope - 电动工具箱 - http://www.electrictoolbox.com/

Does anyone know a good resource discussing the issues involved in session
theft? I''ve read a couple, but none that really address the problem apart
from acknowledging that it is a problem; you just don''t seem to be able to
do much about it.

Does anyone have some tried-and-tested measures for preventing session
theft, that aren''t already built into PHP? For that matter, what measures
_are_ already built into PHP? Are there significant differences between PHP4
and PHP5?

Damage-limiting exercises, such as re-authenticating before performing an
"important" action, aren''t really my concern here. I''ve got admin systems
where virtually every action is sufficiently critical that ideally I would
re-authenticate on every page request, but that just wouldn''t be practical.

Instead, I need to ensure that it is virtually impossible to steal a session
key in the first place. It doesn''t have to be 100% secure, since nothing is,
but I need it to be very close, and know exactly where the risks are.

Also, what are the arguments for/against cookies versus querystring for
storing the session key? The obvious risk of putting it in the querystring
is that someone can read it off the screen, but I suppose I can block that
with frames and a bit of scripting. I can demand specific requirements like
JavaScript and cookies on the client side, since security is a greater
concern than compatibility.

- Robert

解决方案

Robert Tweed wrote:

Does anyone know a good resource discussing the issues involved in
session theft? I''ve read a couple, but none that really address the
problem apart from acknowledging that it is a problem; you just don''t
seem to be able to do much about it.

Does anyone have some tried-and-tested measures for preventing session
theft, that aren''t already built into PHP? For that matter, what
measures _are_ already built into PHP? Are there significant
differences between PHP4 and PHP5?

Damage-limiting exercises, such as re-authenticating before performing
an "important" action, aren''t really my concern here. I''ve got admin
systems where virtually every action is sufficiently critical that
ideally I would re-authenticate on every page request, but that just
wouldn''t be practical.

Instead, I need to ensure that it is virtually impossible to steal a
session key in the first place. It doesn''t have to be 100% secure,
since nothing is, but I need it to be very close, and know exactly
where the risks are.

Also, what are the arguments for/against cookies versus querystring
for storing the session key? The obvious risk of putting it in the
querystring is that someone can read it off the screen, but I suppose
I can block that with frames and a bit of scripting. I can demand
specific requirements like JavaScript and cookies on the client side,
since security is a greater concern than compatibility.

If you use a sufficiently long enough session code that''s used in the
query string there''s no way someone will be able to remember it by
looking at the address bar but it is possible for that query string to
be found in other ways eg a network sniffer looking for urls, and
Googe/Yahoo/Alex/etc toolbars which report urls back to the server.

If you use cookies the toolbars won''t be able to use them but someone
sniffing for them can still get them.

If you use a combination of cookie/querystring and IP address the user
may be accessing the site through a proxy or other method where their
IP address changes with each request, or the person sniffing the
session may be in a network using the same IP address and can still get
in. So that method is bound to fail as well.

The only 100% reliable way I can see is to run the session through SSL.
That way any cookies or sessions passed in the query string are
encrypted between the client and browser.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

"Chris Hope" <bl*******@electrictoolbox.com> wrote in message
news:cp**********@lust.ihug.co.nz...

If you use a sufficiently long enough session code that''s used in the
query string there''s no way someone will be able to remember it by
looking at the address bar
Hardly something you can rely on. Someone could simply walk up to a PC that
had been left unattended and write it down. Or they could use a webcam. It''s
very simple to copy something you can see.
but it is possible for that query string to
be found in other ways eg a network sniffer looking for urls, and
Googe/Yahoo/Alex/etc toolbars which report urls back to the server.
I also agree that is a more serious concern. These could also access cookies
too, although I have no idea what any of them actually _does_ store. Another
concern is cross-site scripting attacks, but this is not something I know a
great deal about. I''m not sure if it is something that is only possible
where the JavaScript sandbox is broken in a particular browser, or if it is
something that can be possible in a fully bug-free browser also.
If you use a combination of cookie/querystring and IP address the user
may be accessing the site through a proxy or other method where their
IP address changes with each request, or the person sniffing the
session may be in a network using the same IP address and can still get
in. So that method is bound to fail as well.
That is true, which is why I had not intended to rely solely on IP checking.
It''s definitely still a good measure where it will work, so it''s something
I''m going to make optional as part of my libraries and turn on for all
high-security sites. In those cases there would be no good reason for anyone
acccessing the site to have their IP address change between requests.

Doesn''t solve the problem of people on the same network sharing an apparent
IP address, but at least it''s one extra step of difficulty; it restricts
session thefts to within the same organisation. If there is some additional
way to tackle that problem, then that would cover all the bases.
The only 100% reliable way I can see is to run the session through SSL.
That way any cookies or sessions passed in the query string are
encrypted between the client and browser.

Doesn''t stop people stealing them at the browser end, which is generally the
problem with session theft. All of the aforementioned theft techniques would
work whether the transport is secure or not. Obviously, for systems that
actually require this security, the connection will be over SSL anyway
because of the potential sensitivity of the data. There are still these
other attacks that need to be prevented. There are probably even a few more
attacks that I haven''t thought of yet.

- Robert

Robert Tweed wrote:

"Chris Hope" <bl*******@electrictoolbox.com> wrote in message
news:cp**********@lust.ihug.co.nz...

If you use a sufficiently long enough session code that''s used in the
query string there''s no way someone will be able to remember it by
looking at the address bar

Hardly something you can rely on. Someone could simply walk up to a PC
that had been left unattended and write it down. Or they could use a
webcam. It''s very simple to copy something you can see.

but it is possible for that query string to
be found in other ways eg a network sniffer looking for urls, and
Googe/Yahoo/Alex/etc toolbars which report urls back to the server.

I also agree that is a more serious concern. These could also access
cookies too, although I have no idea what any of them actually _does_
store. Another concern is cross-site scripting attacks, but this is
not something I know a great deal about. I''m not sure if it is
something that is only possible where the JavaScript sandbox is broken
in a particular browser, or if it is something that can be possible in
a fully bug-free browser also.

If you use a combination of cookie/querystring and IP address the
user may be accessing the site through a proxy or other method where
their IP address changes with each request, or the person sniffing
the session may be in a network using the same IP address and can
still get in. So that method is bound to fail as well.

That is true, which is why I had not intended to rely solely on IP
checking. It''s definitely still a good measure where it will work, so
it''s something I''m going to make optional as part of my libraries and
turn on for all high-security sites. In those cases there would be no
good reason for anyone acccessing the site to have their IP address
change between requests.

Doesn''t solve the problem of people on the same network sharing an
apparent IP address, but at least it''s one extra step of difficulty;
it restricts session thefts to within the same organisation. If there
is some additional way to tackle that problem, then that would cover
all the bases.

The only 100% reliable way I can see is to run the session through
SSL. That way any cookies or sessions passed in the query string are
encrypted between the client and browser.

Doesn''t stop people stealing them at the browser end, which is
generally the problem with session theft. All of the aforementioned
theft techniques would work whether the transport is secure or not.
Obviously, for systems that actually require this security, the
connection will be over SSL anyway because of the potential
sensitivity of the data. There are still these other attacks that need
to be prevented. There are probably even a few more attacks that I
haven''t thought of yet.

If you use cookies rather than the querystring to pass sessions then it
at least makes it a little trickier to get the session code. I''m not
even sure in IE or Mozilla you can get the current value of a session
cookie (but I *do* know you can in Konqueror).

I have personally used the secure session with cookie and IP address
restriction trick myself before, using the same reaasoning as you that
the people accessing the system will always be coming through the same
IP address, and anyone coming from that IP address is going to be a
valid user.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

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