【付费】前端密码传输,支付请求等等类对安全性比较高的数据传输安全问题?

发布于 2022-09-06 05:57:20 字数 332 浏览 26 评论 0

  1. http 下, 前端传输是怎么相对安全一点的(看了很多回答,都说不安全,但互联网上各种需求层出不穷,我也看到很多还没上https的网站,,我想着应该有方法比明文传输安全一点点的办法吧。) 所以想了解下这方面的处理方法。
  2. https 下呢,据我了解,会自动加密。 那我的理解是对开发者来说不用额外处理,就当明文传输就可以了,我这样这样理解对吗,还是也需要一定的安全措施呢。
  3. 以上付费解答。原因是,我的提问似乎太过于【伸手党】,但其实是我查过资料,有些地方看得不太懂,没有实战过这些,不自信到底是不是这样。或者说都是些零散的知识,而我希望想走捷径。 望大师小师前辈同行们解答。 谢谢大家?。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

分分钟 2022-09-13 05:57:20

先说 HTTPS, HTTPS在 TCP 和 HTTP 协议之间添加了一层用来加密(加密原理就不说了),上层不用考虑具体下层的实现,服务器(发送页面,AJax通信等)不用考虑底层的实现,也就是说你写 PHP 的代码,所有数据都是加密发送出去的,可以保证所有的数据不被窃听不被篡改,所以你可以不用考虑任何与加密相关的事情就可以认为通信是安全的。

这种安全仅仅是指防止链路上的窃听和篡改,只是说服务器和客户间的路由器无法篡改和解密两台机器间的通信数据,路由器做的只能是转发。 HTTPS并不保证在服务器或是客户的电脑上数据的安全。就是说,你电脑上的恶意软件依旧可以窃听和篡改数据。 一种可能需要我们注意的情况是,一个HTTPS 页面,引用了一个非 HTTPS 的 JS(或者其他页面), 那么这个 JS 就是不安全的,有可能被篡改并在客户的浏览器里执行,而这个 JS 是可以访问这个页面所有的数据的,此时如果有敏感数据被这个 JS 读取并发送出去也是可能做到的。

HTTP 所有报文都是明文发送,两台电脑间的所有数据都可以被中间的路由看到,并且可以随意的修改,因此他是不安全的。涉及到密码的传输,如果是仅仅是密码验证的话可以使用简单的方式做到比较安全。 具体做法是,首先选一个hash函数,比如sha1。 服务器生成一个随机数n1(随机字符串),客户端也生产一个随机数n2,相互发送给对方。 然后,客户端求得sha1("密码"+"n1"+"n2") 之后发送给服务器,服务器使用相同的算法计算这个值,如果相同则验证成功。(当然,服务器上一般不明文保存密码,但是这个没有关系)。 生成随机数的目的是防止重放攻击。

如果服务器,客户端和中间的恶意路由(或者其他监听者)一开始知道的信息都一样,那么无论服务器和客户端怎么通信都不会获知额外的恶意路由不知道的信息,此时,怎么通信都是不安全的。 加密就是使用“坏人”不知道的一些信息,利用这一部分信息来加密。 HTTPS就是事先服务器生成一对公钥,“坏人”无法获知私钥的信息(“坏人”知道的信息少),用户在电脑上保存并且绝对信任这个公钥而实现的加密。如果“坏人”事先获知了服务器的私钥,或是用户电脑信任了“坏人”已知私钥的公钥,那么HTTPS也是不安全的。所以,如 @奔跑的香蕉 所说的那样,有服务器生成公钥发送给浏览器也是可以完成对敏感数据加密的。

少女的英雄梦 2022-09-13 05:57:20

前端菜鸟, 分享个经验, 不一定是最好的, 意在抛砖引玉

可以用jsencrypt, 搜索下非对称加密这个关键词了解下概念先.
大概说明:

  1. 服务端生成公钥私钥
  2. 公钥明文给前端,
  3. 前端再用这个公钥密码加密, 发送到服务端
  4. 服务端用之前生成的私钥解密
  5. 因为只有服务端私钥, 所以只有服务端能比对加密结果是否一致.

我单位是用这个做登陆的加密, 实施也很简单.
https://github.com/travist/js...

碍人泪离人颜 2022-09-13 05:57:20
  1. 前端不会放敏感信息,如果说敏感信息,应该是cookie了,敏感信息都放在服务端的session,但是session_id由前端传入,一般基于cookie传输,也有基于url传输的。说下登录场景的密码传输问题,一般都是明文传输到服务器,大站可能会有jsmd5这种库,这样在网络上传输的已经是md5密文。
  2. https可以防止中间人攻击,保证浏览器到服务器这条链路是可信任的传输。除非你手动信任了中间人证书,我想没什么人这么傻,服务器开启ssl即可。加密成本最小,应用不用更改。
小…楫夜泊 2022-09-13 05:57:20

作为一个前端小白,我之前碰到这个问题为了加密post这种传输的数据,一般是把参数数据的按照约定格式排序然后加上时间戳,在加上一个约定的key再使用别的加密方式加密例如md5这种方式加密,生成一个key若是与后台生成的一致则可以成功请求,大概思路是这样的,但我想说靠前端加密就是个笑话呀╮(╯▽╰)╭

别再吹冷风 2022-09-13 05:57:20

我说说我的见解呀,我是一个后端来着,我前端懂一点点,就是前端加密我觉得是没必要的,比如传输数据,你用js加密的,就好像把钥匙挂在门口一样。没必要,https是一个必然的趋势,我觉得没有一个网站是绝对安全的,只要能够防住98%的入侵,就相当不错了。目前来说就是证书比较安全实用吧。。。

围归者 2022-09-13 05:57:20

https可以保证传输安全,数据从浏览器到达服务器的路上任何人不能窃取。

http与https 的安全区别简单点来说就是, 你在路由器上, http你可以看到发出去的明文报文和接收到的明文报文。所以https是必须的,
启用https之后, 在需要安全校验的地方,加入手机验证码,回答问题,支付密码等,身份验证,防止账号被盗用。

浏览器安全控件是保证从键盘传输到浏览器页面安全的,但是一般安全空间体验极差,跨平台不完善,手机端不支持等问题,不建议使用

巨坚强 2022-09-13 05:57:20

其实在前后端交互过程中,你主要防御的是数据传输过程中防止有人中途截包解密的问题,如果你是说从浏览器开始防御基本不可能的,直接F12看的清清楚楚的。
而https你可以理解为它会为你自动加密,当然实际上肯定没有这么简单
http下面的加密你可以看一下非对称加密。

谁的年少不轻狂 2022-09-13 05:57:20

前后台都还可以,前后台都能看懂和修改大部分的开源代码,也在安全公司待过。
https已经相对安全,数据已经加密,可以防止中间人,密码在上传之前再进行hash一下,sha256或者md5。

迷你仙 2022-09-13 05:57:20

密码加密后再post请求

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文