网站能否通过用户浏览获取用户的mac地址？

Posted 2023-03-22

网站能否仅通过用户浏览该网站获取硬件信息，如mac地址。前提：用户没有安装该网站的任何控件，浏览器也清理了。。那硬件信息还能被网站记录吗？。。如果在该网站注册了，情况会不会不同？？。。跪求懂行的来解答！不懂的别占位子！

当然可以获取用户的mac地址，你打开网站都会有脚本运行，在中国一般网站都会读取用户本地电脑上的信息，来做参考。

如何获得登录用户的MAC地址

在设备管理器里，找到网络适配器，找到你的网卡。



然后选属性，切换到“高级”选项卡。



在网络地址（有的系统是英文名network address）那一项对应的值选“不存在”确定。



MAC地址就会和系统的一致了。

至于你登陆的问题，看你的账号是否是绑定在你的电脑网卡了。

如果MAC已经和你系统一致了，还提示你解绑，那说明账号绑定的网卡不是你这个，需要联系你们的网络中心解绑，然后重新绑定到你这就行了。

参考技术A 默认情况下是不可以的。不过可以有变通的方式，如果网站支持Flash加载，可以嵌入一块Flash代码，Flash代码支持获取mac地址。另外一种方式就是要走OCX插件模式。 参考技术B 正常情况下是不可以的，特殊的可以
http://blog.csdn.net/skiing_886/article/details/7911905
这个就是用JS获取MAC的，但是这个只能自己用于测试使用，希望对你有帮助本回答被提问者采纳 参考技术C 有终端？·····追问

不安装其客户端

追答

对于我来说是没什么办法了!如果他还存留那还可以，可惜什么都没了，基本上是不可能的

某些黑客能否从用户那里窃取 Web 浏览器 cookie 并在网站上使用该名称登录？

【中文标题】某些黑客能否从用户那里窃取 Web 浏览器 cookie 并在网站上使用该名称登录？

【英文标题】：Can some hacker steal a web browser cookie from a user and login with that name on a web site?

【发布时间】：2011-01-30 17:07:43

【问题描述】：

阅读这个问题， Different users get the same cookie - value in .ASPXANONYMOUS

并寻找解决方案，我开始思考，如果有人真的可以通过某种方式窃取 cookie，然后将其放在他的浏览器上并以管理员身份登录。

您知道表单身份验证如何确保即使 cookie 被盗，黑客也不会在实际登录中使用它吗？

还有其他替代的自动防御机制吗？

【问题讨论】：

类似问题：***.com/questions/3720720/…

【参考方案1】：

我不知道有问题的 cookie 的细节，但将用户名和密码都存储在用户 cookie 中通常是不好的做法。您通常只想将用户名与其他非敏感信息一起存储在 cookie 中。这样，只有在登录时才会提示用户提供密码。

【讨论】：

@Jason，cookie 被窃取和使用的方式与在 cookie 中存储用户名和密码无关。 （我不是反对者）。

您不应在 cookie 中存储用户名或密码。使用 cookie 的最安全和最明智的方法是只在 cookie 中插入一个值，例如正确用户名的哈希值、建立连接的 IP 地址和一些服务器端秘密值。将此哈希与用户名一起存储到您的数据库中，并使用它来获取正确的数据。您应该始终假设，如果您允许用户或其他人篡改 cookie 值，它们应该是加密安全的。

我只是想简单地证明将密码存储在 cookie 中并不是一个好主意。我同意 Tuna-Fish 的观点，即哈希是存储用户名的好主意，但我试图传达这个想法只是为了让它们走上正确的轨道，

我放+1只是因为即使cookie上的登录信息是完全加密的，即使系统也不知道密码（哈希检查），并且任何cookie上都没有显示，但是还不错一遍又一遍地说。

@Tuna-Fish：实际上，ASP.NET 的做法更加安全：它存储了一个不容易猜到的任意值。此值用作在服务器端检索会话字典的查找，其中包含有关用户的任何信息（但从不他们的密码）。

【参考方案2】：

会话 ID 可以通过多种方式泄露给攻击者。 XSS 是最常用的劫持会话 ID 的攻击，您应该在应用程序中使用test for XSS vulnerabilities。 .提高会话强度的常用方法是检查 IP 地址。用户登录时，记录下ip地址。检查每个请求的 IP 地址，如果 IP 更改，则可能是被劫持的会话。这种安全措施可以阻止合法请求，但这非常不太可能。

不要不检查 X-Forwarded-For 或 User-Agent，攻击者可以轻松修改这些值。

我还建议在您的 web.config 文件中启用 httpOnlyCookies：

<httpCookies httpOnlyCookies="true"/>

这使得攻击者更难使用 javascript 劫持会话，但仍有可能。

【讨论】：

IP地址检查的问题是现在很多人都在负载均衡器后面，这意味着IP地址对于用户来说是不稳定的。

@The Rook，你能提供支持你（模糊）陈述的真实数据吗？

那么拥有最多软件产品的公司漏洞数量最多？我认为这只是常识。如果你把这个逻辑推到极致，那么最隐蔽的平台一定是最安全的……隐蔽的安全？不是做出平台决策的好方法。

@The Rook：在我看来，典型的 Web 漏洞，例如 XSS，大多与平台无关。

@Rook：没什么好道歉的。你完全可以不同意我的观点。我只要求你诚实地解释分歧的根源，这样它就不会变成个人的。

【参考方案3】：

Cookie 可能被盗的场景发生在公共无线环境中。虽然您或我永远不会在这样的设置中操作，但可能无法阻止您的客户这样做。

如果攻击者知道您连接到哪个安全站点，则其想法是您的浏览器可能会被诱骗发布到同一 URL 的非安全版本。此时您的 cookie 已被盗用。

这就是为什么除了 httpOnlyCookies 之外，您还需要指定 requireSSL="true"

<httpCookies httpOnlyCookies="true" requireSSL="true" />

我不同意 The Rook 的评论，因为我认为这不公平；

@Aristos 我更新了我的答案。但老实说，如果您使用 Microsoft 开发平台，您的应用程序本质上是不安全的。 – Rook 22 分钟前

安全性不是偶然发生的，也不是“开箱即用”的，至少在我的经验中不是这样。无论平台或工具如何，在设计之前没有什么是安全的。

【参考方案4】：

是否有可能窃取 cookie 和 以管理员身份进行身份验证？

是的，如果 Forms Auth cookie 未加密，则可能有人会破解他们的 cookie 以赋予他们更高的权限，或者如果不需要 SSL，则复制其他人的 cookie。但是，您可以采取一些措施来降低这些风险：

在 system.web/authentication/forms 元素上：

要求 SSL=true。这要求 cookie 仅通过 SSL 传输 滑动过期=假。如果为 true，则可以重新激活过期的票证。 cookieless=假。不要在您试图强制执行安全性的环境中使用无 cookie 会话。 启用CrossAppRedirects=false。如果为 false，则不允许跨应用处理 cookie。 保护=全部。使用 machine.config 或 web.config 中指定的机器密钥对 Forms Auth cookie 进行加密和哈希处理。此功能将阻止某人破解他们自己的 cookie，因为此设置会告诉系统生成 cookie 的签名，并在每次身份验证请求时，将签名与传递的 cookie 进行比较。

如果您愿意，您可以通过在 Session 中放置某种身份验证信息来添加一点保护，例如用户用户名的哈希（绝不是纯文本的用户名或密码）。这将要求攻击者窃取 Session cookie 和 Forms Auth cookie。

【讨论】：

requireSSL=true 是我想念的东西。我认为这是最重要的一项。

【参考方案5】：

我正在研究这个，我想出了一个想法，我不确定它是否 100% 安全，但这是一个想法。

我的想法是每个用户都必须从登录页面通过。如果有人偷了cookie，不是通过登录页面，而是直接进入其余页面。他无法通过登录页面，因为不知道真正的密码，所以如果他通过了，他无论如何都会失败。

所以我放置了一个额外的会话值，用户已成功通过登录页面。 现在在每个关键页面中，我都会检查那个额外的会话值，如果发现它为空，我会注销并再次询问密码。

现在我不知道，也许微软已经做好了一切，需要进一步检查。

为了验证这个想法，我使用了这个直接让用户登录的函数。

FormsAuthentication.SetAuthCookie("UserName", false);

我已经准备好修复和使用的第二个安全措施是，我检查来自同一个登录用户的不同 ip 和/或不同 cookie。我对此进行了很多思考，进行了很多检查（是否在代理之后，是否来自不同国家，要寻找什么，我见过他多少次等等），但这是一般的想法。

This video 准确显示我试图阻止的内容。通过使用我在这里描述的技巧，您不能只设置登录 cookie。

只是分享我的想法...

【讨论】：

不确定我理解你的意思。可能是语言问题。

@Steven 我只是在用户已通过登录页面的会话数据（与登录数据不同）上放置一个标志。

好的，但是如果用户登录然后他们的会话被劫持，标志将被设置。还是我错过了什么？

@Steven 他必须劫持 2 个不同的 cookie，一个用于登录，一个用于会话。一种是仅使用 ssl 传输。我认为破解 2 个不同的 cookie（具有不同的代码/解码/变量方式）比破解一个更难。它是一种将这些 cookie 连接在一起的方法。他不能记录和劫持会话，因为记录保留了权限的关键信息。这是为了防止有人试图破解 cookie 或嗅探它们。

@Steven 这个视频youtube.com/watch?v=yghiC_U2RaM 展示了我试图阻止的内容。