JS和安全性。 [英] JS and security.
问题描述
根据我试图访问的金融网站没有javascript ：
该网站出于安全原因使用JS。
如何使用JS提高安全性？
谢谢。
osfwofujro说以下on 9/1/2005 10:11 AM：根据我试图访问的金融网站没有javascript ：
该网站使用JS进行安全性原因。
如何使用JS提高安全性？
它没有。它显示了那些编程了网站的程序员的无能。
除非他们出于安全原因而使用它们来阻碍那些
一开始就不明白如何打败安检。
-
Randy
comp .lang.javascript常见问题解答 - http://jibbering.com/faq &新闻组周刊
Randy Webb写道：
osfwofujro在9/1/2005 10:11 AM上发表以下内容：
根据我试图访问的金融网站没有
javascript ：该网站出于安全原因使用JS。
<如何使用JS提高安全性？
它没有。它显示了对网站进行编程的程序员的无能。
除非他们出于安全原因而使用它们来阻碍那些不知道如何打败网站的人。首先是安全性。
我认为可能是获取用户的IP地址（如果他们使用代理可能是
）？
" osfwofujro" < jw*@9ewutr.com>在消息中写道
news：6 _ *************** @ newsfe4-gui.ntli.net ...根据我试图访问的金融网站没有javascript ：
该网站出于安全原因使用JS。
如何使用JS提高安全性？
可能有几种方式......但没有一种方法特别好。
对于任何这些来说，这对网站来说意味着什么在启用JavaScript的情况下，只需要
功能。其中任何一个都能运作它的第二个
必须以软运行安全性 - 那些小接口的东西
在一个certiain方向刺激用户，但实际上并没有解决任何实际的硬问题。安全问题。
但是在这个领域还有一些事情可以做：
+）许多网站都在打开他们的财务应用程序二级窗口
（通常无铬）。这样做的好处是，一旦该窗口关闭
主浏览器窗口将不包含子窗口的历史记录。
（当然你可以打开一个新窗口而不用JavaScript，但我们都知道
，JavaScript使得使用子窗口变得更加顺畅。）
+）使用JavaScript / DHTML，网站可能会自动当它b / b
感觉没有任何活动或用户请求时，屏蔽掉（使用不透明元素隐藏或覆盖
）屏幕或屏蔽表单字段或其他
潜在的敏感信息。自动系统可能需要
密码来取消屏蔽信息，虽然这不是实际的安全性。
当然它确实可以阻止随便的观察者。
+）使用AJAX样式的数据采集到JavaScript变量意味着
您的个人信息不会缓存在浏览器或源代码中。
所以甚至，比方说，如果有人要禁用JavaScript并查看你的来源
代码他们实际上看不到你的数据（它被抽象为
变量）。再一次，这不是真正的安全，但它可以防止更多的b / b
潜在的小偷。它当然也意味着，没有任何
的信息可以通过启用JavaScript来查看。
+）JavaScript在推动用户使用时非常有用正确的方向。
离开应用程序时关闭浏览器窗口的活动提醒
（使用onunload（））来防止历史记录挖掘通常是有效的。
+）有人认为使用屏幕键盘（用
JavaScript或Flash等编写的键盘）可以提高安全性。这个想法（至少有一些优点是
）可以防止击键嗅探器获得你的密码。
还有其他一些但很明显，任何能够真正解决软安全问题的选项也几乎肯定会影响网站的可访问性
。此外，他们中没有一个可以解决网络钓鱼活动等问题。
（可以使用相同的功能使他们的虚假网站看起来更加准确）。
>
在尝试通过JavaScript解决硬安全问题时，没有任何意义（尽管我愿意被说服）。数据加密，
密钥管理，凭证管理等等都应该集中管理，并且b $ b严格控制。
同时从理论上讲，应该做的一切都是可以完成的（并且在许多国家都有立法来强制执行这个想法）
所有这些解决方案的地址都是客户端完全。虽然这不是一件糟糕的事情，但是大部分的数据泄露都发生在公司方面。无论网络钓鱼和击键记录如何成功，与一次数百万条记录的损失相比，它们都显得苍白无力。
通过企业安全保障。
仍然 - 如果你知道（并且可以接受）这些限制，肯定会有与脚本有关的事情，这可以_improve_（安全方面）。但
脚本本身无法以任何方式提供真正的安全性。
Jim Davis
According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."
How would using JS improve security?
Thanks.
osfwofujro said the following on 9/1/2005 10:11 AM:According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."
How would using JS improve security?
It doesn''t. It shows the incompetence of the programmers who programmed
the site.
Unless they mean its used for security reasons to hamper the ones that
don''t understand how to defeat the security in the first place.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Randy Webb wrote:
osfwofujro said the following on 9/1/2005 10:11 AM:According to a financial website I tried to access without
javascript: "the site uses JS for security reasons."
How would using JS improve security?
It doesn''t. It shows the incompetence of the programmers who
programmed the site.
Unless they mean its used for security reasons to hamper the ones that
don''t understand how to defeat the security in the first place.
I thought it might be to grab the users IP address (if perhaps they were
using a proxy)?
"osfwofujro" <jw*@9ewutr.com> wrote in message
news:6_***************@newsfe4-gui.ntli.net...According to a financial website I tried to access without javascript:
"the site uses JS for security reasons."
How would using JS improve security?
There might be several ways... but none particularly good.
Firs off for any of this to mean anything the sitew would have to only
function with JavaScript enabled. Second for any of them to function it
would have to operate on "soft" security - those little interface things
that prod the user in a certiain direction but don''t actually address any
real "hard" security problems.
But still there are several things in that arena that might be done:
+) Many sites open their financial applications in secondary windows
(usually chromeless). This has the benefit that once that window is closed
the main browser window will not contain the history of the child window.
(Of course you can open a new window without JavaScript, but we all know
that JavaScript makes working with child windows a lot smoother.)
+) Using JavaScript/DHTML the site might, either automatically when it
senses no activity or on user request, mask out (make invisilble or cover
with an opaque element) the screen or mask out form field or other
potentially sensitive information. Automatic systems might require the
password to unmask the information although this isn''t actual security of
course it does prevent casual observers.
+) Using AJAX-style data aquisition into JavaScript variables means that
your personal information isn''t cached in the browser or the source code.
So even, say, if somebody were to disable JavaScript and view your source
code they couldn''t actually see your data (which is abstracted into
variables). Again this isn''t real security but it prevents a more
sophisticated class of potential thief. It also, of course means, that none
of the information can be viewed with JavaScript enabled.
+) JavaScript is very useful at nudging the user in the right direction.
Active reminders to close a browser window when leaving an application
(using the onunload()) to prevent history mining) are often effective.
+) There is some thought that using onscreen keyboards (keyboards written in
JavaScript or Flash or the like) will improve security. The idea (which has
at least some merit) is that this will prevent keystroke sniffers from
obtaining your password.
There are others but it should be clear that any option that would truly
address softsecurity issues will also almost definitely affect accessibility
for a site. Also none of them can address phishing campaings and the like
(which can just use the same features to make their phony sites look that
much more accurate).
There''s no sense (although I''m willing to be conviced) in attempting to
address hard security issues via JavaScript. Things like data encryption,
key management, credential management, etc should all be centralized and
rigidly controlled.
Also while, in theory, everything that can be done should be done (and
there''s legislation being written to enforce this idea in many countries)
all of these solutions address the client-side completely. While this isn''t
a bad thing the vast (vast) majority of data compromise has occured on the
corporate side. No matter how successful phishing and keystroke logging may
be they pale in comparison to the loss of millions of records at a time
through corporate security gaffs.
Still - if you know (and can accept) the limitations there are definately
things to do with script which can _improve_ (aspects of) security. But
script itself can''t _provide_ real security in any way.
Jim Davis
这篇关于JS和安全性。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
