㈠ 前端是否需要对密码进行加密传输 && HTTPS
最近学习node,写demo登陆和注册功能的时候因为要考虑后台的加密和安全所以也想了下前端的,前端传输密码的时候是否应该加密之后再传输呢
看了一些网站的登陆,csdn、等是明文传输,但腾讯、网络这些一线大站是经过前端加密的,看了些大佬的文章,顺便自己搬个凳子记个笔记
前端的加密本身不能对网站的安全性有任何提高功能,所有的关于网站的安全技术都应该放在后台,但是这也不是完全没有意义,可以增加攻击成本,尽可能降低攻击带来的损失,毕竟丢了密文比丢了明文要强,而且犯罪分子技术参差不齐,简单的加密能够拦截很大一部分菜鸟,至于高手。。。
最后看到比较统一的是隐秘信息传输应该使用https
这篇文章只是想弄懂流程和原理,不会去纠结具体的术语
HTTP协议以明文方式发送内容,不提供任何方式的数据加密,处在同一网络中的其它用户可以通过网络抓包来窃取和篡改数据包的内容,甚至运营商或者wifi提供者,有可能会篡改http报文,添加广告等信息以达到盈利的目的
可以通过和SSL(Secure Socket Layer,安全套接层)组合使用来为浏览器和服务器之间的通信加密。在这条加密线路上进行通信的http被称为HTTPS(HTTP Secure,超文本传输安全协议)。
SSL证书(Secure socket layer),就是遵守SSL协议,由受信任的数字证书颁发机构CA颁发,主要用来提供对用户浏览器和服务器的认证,对传送的数据进行加密和隐藏,确保数据在传送中不被改变保证数据的完整性,加密方式为“非对称加密”和“对称加密”。
1、用户连接到你的Web站点,该Web站点受服务器证书所保护
2、你的服务器进行响应,并自动传送你网站的数字证书给用户,(浏览器内置一个受信任的机构列表和这些机构的证书)用户的浏览器查看该证书是否存在于浏览器的受信任机构列表中,并且通过服务器证书中的信息与当前正在访问的网站(域名等)是否一致来鉴别你的网站,鉴别没成功会提醒用户是否继续该访问
3、鉴别成功后,用户的浏览器产生一把唯一的会话钥匙,用以跟网站之间所有的通讯过程进行加密,会话密钥是随机生成,每次都会有不一样的结果,
4、使用者的浏览器以网站的公钥对交谈钥匙码进行加密,以便只有让你的网站得以阅读此交谈钥匙码
1、使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
2、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。
3、HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
4、谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
1、HTTPS协议握手阶段比较费时,会使页面的加载时间延长近50%
2、HTTPS连接缓存不如HTTP高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响;
3、SSL证书需要钱,功能越强大的证书费用越高
4、SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名
5、HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL证书的信用链体系并不安全,特别是在某些国家可以控制CA根证书的情况下,中间人攻击一样可行。
知乎各位大佬的回答 https://www.hu.com/question/25539382
HTTP与HTTPS的区别 https://www.cnblogs.com/wqhwe/p/5407468.html
㈡ web前端用户的密码提交时应当怎样加密
密码在前端加密完全没有意义,对密码系统的安全性不会有任何提高,反而会引发不必要的麻烦。首先,做前端开发的人需要知道,前端系统的控制权是完全在用户手里的,也就是说,前端做什么事情,用户有完全的控制权。假设如同 @陈轩所说,前端做过了md5,后台就不用做了,这个做法会有什么后果?如果某一天,这个系统的数据库泄露了,黑客就直接拿到了每个用户的密码md5值,但此时,由于黑客知道密码是在前端进行哈希的,所以他不需要爆破出该md5对应的原文是什么,而是直接修改客户端向服务器发出的请求,把密码字段换成数据库中MD5就可以了,由于与数据库中记录一致,直接就会登录成功。这跟直接存储明文密码没有任何区别!!!所以不管前端是不是加密了密码,后台使用安全的哈希算法对内容再次转换是非常有必要的。(MD5可不行,要用bcrypt,我之前回答过一个类似的:随着显卡性能的高速发展,目前的快速Hash算法是否已经变得不够安全了?)这个回答还有一个人赞同,希望大家别被错误答案误导了。另外一个答案 @林鸿所说,在非安全HTTP连接上,可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码,而不是原文,窃听者根本不需要原始密码,只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上,而不能改善该网站的安全性。所以不管前端是不是加密了密码,使用HTTPS安全连接进行登录都是非常有必要的。以上我说的两点,合起来看就是:不管前端是否加密了密码,都不能以此为假设,让后端设计的安全等级下降,否则就会有严重的安全问题。实际上,前端进行密码加密,可以看做帮助用户多进行了一次原文的转换,不管用了什么加密算法,算出来的结果都是密码原文,你该如何保护用户的原始密码,就该如何保护此处的加密结果,因为对你的登录系统来说,它们都是密码原文。以上这些,说明了密码加密是没有什么意义的,接下来,我要说明前端加密会带来什么问题。有些人会认为前端进行了加密,可以降低后台的安全性需求,这种错误的观念会造成系统的安全漏洞。实际上,你不能对前端做任何的假设,所有跟安全相关的技术,都必须应用在后台上。前端进行加密会造成页面需要js脚本才能运行,那么假设你的系统需要兼容不能运行js的客户端,就必须再设计一个使用原文的登录接口。由于前端是不是加密,所有安全机制都必须照常应用,所以为系统增加这样的复杂性是完全没必要的,即使传输明文密码,只要正确使用了HTTPS连接和服务器端安全的哈希算法,密码系统都可以是很安全的。
㈢ Web前端密码加密是否有意义
没有意义
密码前端的加密根本没有意义,密码系统的安全性没有提高,但会造成不必要的麻烦。
首先,前端开发人员需要知道前端系统的控制完全掌握在用户手中,也就是说前端所做的事情和用户拥有完全的控制。据称,前端做了MD5,后台不必做,这种方法会有什么后果?如果有一天,系统数据库泄露,黑客直接获得每个用户的密码的MD5值,但这一次,因为黑客知道密码的哈希的前面,所以他不需要鼓风的MD5对应什么是原创,而是直接修改发送到服务器的客户端请求的在它的数据库密码字段MD5,符合数据库中的记录,你可以直接登录。这与直接存储明文密码没有区别!!!所以不管前端密码是否加密,后台使用哈希算法的安全内容转换都是必要的。(MD5不能使用BCrypt的,我以前回答类似:用图形表现,当前快速发展的快速哈希算法已成为不安全吗?)有一个人同意这个答案,我希望你不要被错误的答案误导。对方的回答,Linh说,是为了防止原始密码被利用在一个不安全的HTTP连接。但问题是,因为你的登录系统接受密码代替原来的,窃听者根本不需要原始密码,只要哈希结果可以伪造请求登录系统。这样做只会防止攻击者在社交攻击时使用原始密码,而不会提高网站的安全性。所以不管前面密码是不是加密的,使用HTTPS安全连接登录都是很有必要的。
㈣ HTTPS通信时,Web服务器收到加密后的“对称加密用的密钥”,使用什么对其进行解
https其实是有两部分组成:http + SSL / TLS,也就是在http上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密,所以传输的数据都是加密后的数据。具体是如何进行加密,解密,验证的,且看下图
㈤ web文件上传能否对文件加密
您可以对用超级加密3000将文件加密后再上传。
㈥ web渗透测试之攻破登录页面
当我们在做渗透测试时,无论厂商项目还是src众测项目,都会遇到给一堆登录系统的URL,然后让我们自己去测,能不能进去全看天的状况,本文将讲一下怎么突破这种封闭的web系统,从而进行更深层次的渗透 ,学完后你会发现,其实你就是系统管理员。
如果能直接绕过登录系统界面,后面的就比较好做了,目前常见的登录系统绕过方法有:
大部分情况下,系统登录页面都不存在xss,目录遍历,SQL注入等漏洞,这时候最常用的方法就是爆破和猜解登录口令,密码猜解最关键的就是字典要高效准确
https:// down.52pojie.cn/Tools/N etwork_Analyzer/Burp_Suite_Pro_v1.7.31_Loader_Keygen.zip
2.准确的用户名,密码字典是高效破解的重中之重 ,一般都是指定几个常见用户名 ,尝试 top500,top1000进行爆破 字典不必要太大,最重要的是针对性要强 ,下面是top1000:
链接: https:// pan..com/s/1-XztuB 8YTfpT5aUBVbmbzA 密码: 56pb
3.如果还是不能猜解成功,就要根据目标信息用字典生成器构造针对性的字典来猜解了,推 荐几个比较好的字典生成工具
pydictor:
LandGrey/pydictor
crunch:
crunch - wordlist generator
Cewl:
digininja/CeWL
Cupp:
Mebus/cupp
因为管理员权限较高,通常我都会先进行管理员口令的猜解,总结了一些常见的管理员用户名字典
<u>链接:</u> <u> https:// pan..com/s/1sOD1-u whnStaw_LfMOf-sQ </u><u>密码: 3yqe</u>
用此用户名字典,再加上弱口令top1000,同时爆破系统管理员用户名密码
链接: https:// pan..com/s/1-XztuB 8YTfpT5aUBVbmbzA 密码: 56pb
常见的普通用户用户名是姓名拼音,总结了普通用户字典
TOP3000姓名
<u>链接:</u> <u> https:// pan..com/s/1qN9kCF tymP4ugvu3FFkKbA </u><u>密码: hkzp</u>
TOP10w姓名
https:// github.com/rootphantome r/Blasting_dictionary/blob/master/top10W.txt
通常可以选择几个弱口令密码,比如:123456,123abc,111111,然后配合top10w来猜解登陆口令,一些初始化的默认密码也很简单,如果能找到配合top10w通常也能爆出登录口令
现在的业务系统口令传输到后端前都会进行加密处理 ,web常见的加密方式有 md5 加密、sha1 加密、RSA 加密,在此基础上总结了两种破解方式:
1.利用burpsuite的payload processing功能,把字典按照加密方式先加密再发包
2.用字典生成工具生成加密好的字典,然后burp直接加载加密字典
这里推荐的字典生成工具是pydictor,encode功能内置了多种加密算法,调用handler工具直接加密自己的明文字典
如果登录系统设置了IP地址白名单,我们可以通过下面的几个http头字段伪造IP地址,用burp抓包后将下面的某个http头字段加入数据包发送到服务器
<pre class="prettyprint hljs css" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 1.5em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto;">Client-Ip: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Forwarded-Host: 127.0.0.1</pre>
如果在系统登陆界面加上了验证码,那么上面的方法基本上就都失效了,那有什么方法可以绕过验证呢
1.图形验证码不刷新
在一段时间内只要不刷新页面,无论登录失败多少次都不刷新验证码,这个时候就可以使用同一个验证码根据上面的方式进行暴力破解
2.验证码失效
不管在验证码表单输入什么样的数据,都会判断通过,但这种情况很少见
3.图形验证码可被识别,抓包直接可以获得验证码
很多网站的验证码都可以在请求数据包中找到,或者隐藏在request的cookie中,response的源码中,可以利用burpsuite的macros来匹配response中的相应数据,具体的爆破方法参见下文:
burpsuite爆破密码(含验证码) - CSDN博客
4.图形验证码参数直接绕过
对于request数据: user=admin&pass=1234&vcode=brln,有两种绕过方法:
一是验证码空值绕过,改成 user=admin&pass=1234&vcode=;
一是直接删除验证码参数,改成 user=admin&pass=1234。
5.万能验证码
渗透测试的过程中,有时候会出现这种情况,系统存在一个万能验证码,如0000、9999,只要输入万能验证码,就可以无视验证码进行暴力破解。
6. 验证码可被识别
有些图形验证码加入的像素线条过于简单,使用图形验证码识别工具可以识别出每次更换的验证码,在平常的漏洞挖掘过程中,如果我们发现登录的验证码非常简单且易于识别,那我们就可以尝试使用自动化工具来进行登录破解了,如 PKAV 的 HTTP Fuzzer
7.使用机器学习算法识别验证码
主要是对特定网站的图形验证码训练识别模型,达到一定的准确率就可以调用进行模拟提交图形验证码的值了。可参考以下三篇文章进行学习:
使用KNN算法识别验证码:
http:// nlao.github.io/2016/0 9/22/%E9%AA%8C%E8%AF%81%E7%A0%81%E7%A0%B4%E8%A7%A3%E6%8A%80%E6%9C%AF%E5%9B%9B%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BD%BF%E7%94%A8K%E8%BF%91%E9%82%BB%E7%AE%97%E6%B3%95/
卷积神经网络识别验证码
http:// nlao.github.io/2016/0 9/23/%E9%AA%8C%E8%AF%81%E7%A0%81%E7%A0%B4%E8%A7%A3%E6%8A%80%E6%9C%AF%E5%9B%9B%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BD%BF%E7%94%A8%E5%8D%B7%E7%A7%AF%E7%A5%9E%E7%BB%8F%E7%BD%91%E7%BB%9C/
使用 TensorFlow 训练验证码
http:// nlao.github.io/2017/0 4/10/%E4%BD%BF%E7%94%A8TensorFlow%E8%AE%AD%E7%BB%83Weibo-cn%E9%AA%8C%E8%AF%81%E7%A0%81/
对于网站要求输入手机号,接收手机短信并校验短信验证码是否正确进行登录的系统,突破的主要思路有:
1.短信验证码生命期限内可暴力枚举
在验证码还未过期的时间段内,可枚举全部的纯四位数字、六位数字等较简单的短信验证码;
2. 短信验证码在数据包中返回
和图形验证码一样,在response中可以直接获取到短信验证码。
3. 修改请求数据包参数或 Cookie 值绕过
比如有 post 数据包:mobile=12435437658&userid=123456, Cookie中有:codetype=1
在特定步骤,修改 mobile=自己的手机号,自己手机就可以收到别人的验证码,后面再用别人的手机号和接收到的验证码登录;
修改 Cookie 中可疑的参数和值,进行绕过,比如上面修改 codetype=0;
4. 修改返回包绕过
提交错误的短信验证码,返回包中有: status=false,在Burpsuite中修改为 status=true,即可绕过前端判断,成功进入系统。具体还要结合实际的场景,灵活操作。
web系统登陆页面看似铜墙铁壁,但其实只要梳理一遍思路,右键看过每一行网站源码,弄懂每个参数的意义,查看每一个js文件,就会发现其实自己就是系统管理员,只是我把密码忘了,现在我要用上面的方式进入。
㈦ 确保Web安全的HTTPS
很多人说“不用HTTPS就是裸奔”
HTTP的不足:
通信使用明文(不加密),内容可能会被窃听(wireshark/fiddler)
不验证通信方的身份,因此有可能遭遇伪装
无法证明报文的完整性,所以有可能已遭篡改
TCP/IP 是可能被窃听的网络
1.通讯的加密:
SSL(Secure Socket Layer,安全套接层)或TLS(Transport Layer Security,安全层传输协议)
有兴趣深入SSL/TLS: https://www.jianshu.com/p/3e5f01360827
用 SSL 建立安全通信线路之后,就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS(HTTP Secure,超文本传输安全协议)或 HTTP over SSL。
2.内容的加密:
为了做到有效的内容加密,前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意,由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理,所以内容仍有被篡改的风险。
不验证通讯方的身份就可能遭遇伪装
无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息,只想发给特定用户通信的权限。
无法判定请求是来自何方、出自谁手。
无法证明报文的完整性,可能已遭篡改
如何防篡改?
可以使用MD5和SHA-1等散列算法,但这仍然无法百分百保证结果的正确,因为散列码如果同时被修改的话,用户还是无法意识到文件已经被修改。还是用HTTPS吧。
HTTP+ 加密 + 认证 + 完整性保护=HTTPS
HTTP是身披SSL外壳的HTTP
相互交换密钥的公开密钥加密技术 :
共享密钥加密的问题:
证明公开密钥的正确性的证书:
也可以通过设置->高级->管理HTTPS证书来查看所有已经安装的证书(chrome浏览器)
HTTPS的安全通信机制:
步骤 1: 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。
步骤 2: 服务器可进行 SSL 通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3: 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
步骤 4: 最后服务器发送 Server Hello Done 报文通知客户端,最初阶段的 SSL 握手协商部分结束。
步骤 5: SSL 第一次握手结束之后,客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
步骤 6: 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7: 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准。
步骤 8: 服务器同样发送 Change Cipher Spec 报文。
步骤 9: 服务器同样发送 Finished 报文。
步骤 10: 服务器和客户端的 Finished 报文交换完毕之后,SSL 连接就算建立完成。当然,通信会受到 SSL 的保护。从此处开始进行应用层协议的通信,即发送 HTTP 请求。
步骤 11: 应用层协议通信,即发送 HTTP 响应。
步骤 12: 最后由客户端断开连接。断开连接时,发送 close_notify 报文。上图做了一些省略,这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。
问题:为何不完全使用非对称加密算法,而是使用非对称加密算法传送密钥,对称加密算法加密内容?(性能问题)
常见对称加密算法:AES/DES
常见非对称加密算法:RSA
对称加密算法和非对称加密算法速度对比:
https://blog.csdn.net/wowotuo/article/details/80295586
要进行 HTTPS 通信,证书是必不可少的。而使用的证书必须向认证机构(CA)购买。证书价格可能会根据不同的认证机构略有不同。通常,一年的授权需要数万日元(现在一万日元大约折合 600人民币)。
https不是只有信徒,google的霸道也引来了很多的反抗者~
1.chrome浏览器将非https站点默认标注为“不安全”的
2.SEO,不https就掐掉流量。。。
RSS 之父 Winer 炮轰 Google 反客为主强推 HTTPS:
https://www.oschina.net/news/97660/dave-winer-criticize-google
搭建一个https服务端:
https://www.jianshu.com/p/c59ea7d0230e
windows server上的一个简单https例子(不想乱搞测试环境,就没弄Linux):