▎各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 218期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。
本期话题抢先看
1. 业务在前端使用了AES加密，而且秘钥硬编码了，大家觉得这是中高危吗？
2. SSL与明文传输的关系是怎样的？
3. 现在能源行业有哪些成熟的安全运营体系建设标准，作为甲方应该如何建设好自己的安全运营？
话题一
业务在前端使用了AES加密，而且秘钥硬编码了，大家觉得这是中高危吗？我想到的风险点就是更好爆破登录接口了。
A1：
防爆破是各种人机验证和验证码吧。
A2：
等于没加密，你看下Https 对密钥生成和分发的原理就知道了。
A3：
听说过Apache Shiro反序列化吗？
A4：
公钥只能放前端啊，Shiro是默认Key。
A5：
前端代码都透明的，前端的对称密钥不Hard-code到代码里还能放哪里？
A6：
如果是要存储不可逆的数据 ，只为了验证尽量使用MD5X 之类的不可逆算法，如果不是，而只是想在前端加密后台能解密，要使用动态分发密钥或者证书。
A7：
要看加密的是什么内容吧。如果是对前端JS代码做加密感觉不算中危。
A8：
我觉得不算高危，有TLS就算加密了。前端代码都是可逆的，在前端加密意义不大。
A9：
不能说意义不大就不去做。安全本身就是攻防成本的问题。
A10：
一般来说Https 是必须的，然后在MD5X就可以存在本地Cookie 或者传输时候使用。传输协议加密只是一部分 还要在客户端使用这个加密值。
A11：
最近新的标准都会副一条。注：禁止使用MD5。
A12：
我感觉唯一的作用就是骗骗安全设备，最近我们上了态势感知，报了明文传输，领导就让我们讨论下是否要整改，是内网环境，而我们又上不了Https，就有同事说干脆前端加密。
A13：
那用非对称加密就完事了，前端加密本身没问题的，密码算法没选对。
A14：
标准有点变态，需然说MD5已经被破解，但是只是数学意义上的破解。
A15：
前端非对称加密，一般是用来加密对称加密的密钥吧。我觉得MD5不能用，本质上还是因为彩虹表的问题。
A16：
这种一般都用哈希算法，不要用非对称。非对称对性能要求高，如果系统并发高还是会有影响。
A17：
是的，如果你要保证一个客户端一个密钥对的话，对性的影响很大。
A18：
标准不让用MD5是因为这个算法被破解了。但这个破解和我们平时用的爆破密码的方法不是一会时。
A19：
哈希在前端怎么实现，比如123456，哈希之后给服务端，服务端无法还原吧。
A20：
这个就看你咋理解了，RSA也是被破解的算法，但是RSA一样是被推荐。
A21：
加盐就好了。
A22：
是的，一般后端还会加盐再保存。
A23：
服务端不需要还原，服务端早就用同样的哈希算法保存了哈希值，只要把前端发过来的哈希值和服务器端保存的哈希值对比是不是一样，就知道前端输入的密码是否正确。
A24：
这个得把后端的加密算法在前端再实现一遍。哪天后端加密算法变了前端还得改，麻烦啊。
A25：
只能这么做的了，哈希是无法逆向的。
A26：
前端不用改，密码对比的密法是在后端完成的。后端只要知道前端传过来的是什么就行，后端可以随便改。例如，如果后端觉得用户密码只做SHA256哈希再加盐还是不够安全，需要再做一次AES加密再保存到数据库，也可以只改后端就行。
A27：
主要暴力破解问题，加个验证码就能解决了，走Https然后接口不出安全漏洞就好了，不用那么复杂。
A28：
前端做了啥希起码可以确保密码没有以明文形式存储在数据库，很多第三方开发的系统我们根本不知道密码是不是以明文存储。如果前端哈希都不想做，我估计这个系统的密码大概率会是明文储存。
A29：
也有可能是传到后端再生成比对的。
A30：
这个是标准做法。
A31：
在客户端用加密，主要是开发人员比较偷懒，就是前端做了，想其他的都不做了。这样想着挺好，觉得前端做完，那通信加密就不做了，后端列加密也不做了，入库表加密也不做了。但其实是一个坑陷入了进去，因为AES Key 在前端，要考虑生成，和客户端服务端分发共享解密，细刨下来发现，原来在前端做确实是一种偷懒人浮于事的做法，还不如老老实实通信后端数据苦做简单。
A32：
所以这个地方也不合规了。解决了数据加密传输，但是有密钥明文传输了。
A33：
所以又要解决这个合规性问题，就用公钥把密钥加密一次，虽然安全性没有增强什么。
话题二
SSL与明文传输的关系是怎样的？我理解是SSL是提供了加密的管道，里面还是可能存在明文传输，但第三方无法窃取了。
A1：
协议加密和数据加密，还是要求开发对数据加密？
A2：
SSL是加密协议，加密了就看不到明文信息，必须要解密才能看到。
A3：
如果渗透测试人员，导入了证书抓包，看到了明文，是否需要整改呢？以前见过的系统都是哈希加盐。
A4：
看数据要求，这个都是企标去定，哈希只针对不需要解密的数据。
A5：
哈希是数据存储加密，SSL是传输加密。
A6：
账号密码咋弄？
A7：
RSA+AES+Hash。找几个大厂的看看就知道了，都写在JS里。
A8：
现在等保，好像Base64就不给过了。
A9：
MD5就可以吗？
A10：
也不行，起码SHA2，不过只用哈希。渗透应该会给你们提账号爆破风险吧。之前内部定义哈希也不算加密因为没有解密。
A11：
正常情况，SSL的密钥是不会泄露的，用SSL就是为了防止直接抓包和嗅探。
A12：
“如果渗透测试人员，导入了证书抓包，看到了明文”。这是证书泄露了？
A13：
SSL 建立过程中就有证书验证过程，证书在网站上也能下载，应该不是证书的问题，感觉被中间人攻击了？
A14：
Burp 抓包。
A15：
BP导入的是网站的证书，解密数据包的，SSL的私钥公钥不是这个。
A16：
BP这个相当于自己创建的中间人攻击环境。实际上SSL就是用来解决中间人的问题的，终端用户遇到中间人攻击，攻击者没私钥的话终端浏览器会报错，无法继续连接。
A17：
BP并不是使用的网站的SSL证书，那个证书是BP自身的证书，相当于BP既做服务端也做客户端。对于浏览器，BP是服务端，对于被访问网站，BP是客户端。
A18：
是的，这个就是BP要先导入证书的原因。
A19：
原理和Https的WAF类似，必须当中间人，不然WAF也看不到明文。
A20：
不一样，WAF是可以导入SSL证书直接解密的。
A21：
WAF是直接解，类似Nginx、F5 解密。BP的是装证书信任（不提示不匹配的问题）。
A22：
WAF代理，我们的WAF 装SSL证书的。
A23：
我们的WAF解密SSL流量性能扛不住，有些流量在入口解密也不合规，蛋疼。
A24：
入口后边加SSL网关卸载证书，然后接IPS WAF，这样WAF压力小一些。
A25：
我记得标准的做法是前置SSL网关统一解密，内网就没有加密流量了，不然镜像流量给安全监测设备，有很大问题。
A26：
我这里有台态势感知，会报明文传输告警，在内网环境明文应该可以的吧。
A27：
密码明文传输？业务上线的时候强制它使用非对称加密。
A28：
非对称对一些业务支持并不好，另外明文与否也看公司的安全需求级别，明文能更有效抓取脆弱性，真的被人打进来可用手段太多，镜像关键流量要求很高。
A29：
F5在前面先做负载均衡顺便解密SSL，后面接WAF，这样防护的时候就看到明文信息了。让WAF做SSL卸载，性能开销太大了。
A30：
对持续大数据量业务用非对称影响有点大。
A31：
这样设计网络会同意吗？增加了一个关键设备，网络事故的风险会上升。
A32：
非对称加密性能很低吧，Https真正加密的时候也是对称的。
A33：
我刚刚去咨询了网络侧，我们就是WAF卸载的，看来我们的厂家很自信。
A34：
WAF做80强制443回源吧，WAF往后就是80口。
A35：
我感觉就不应该在F5上搞啊，为啥要在LB上搞？
A36：
证书放在LB上统一管理，方便。
A37：
那就看你是多大体量的公司和什么样的业务场景了，小公司业务量没那么大，放WAF上解密问题不大。你看大行，还有搞双十一的这些公司，业务流量上来分分钟把你WAF撑爆。
A38：
人家是后端（服务器）+S, 前端+S来解决安全传输问题，你这是中间S。
A39：
服务端不停，就做Https没有任何问题，在LB再套一层，反正想出去，必须用统一的证书，中间就可以看明文了。
A40：
理想架构大家都想，但不是每个公司都可以用。
A41：
对的，现实妥协很多，看需求了。
A42：
为啥不自建一个SSL证书服务器大家通用呢？
A43：
那关键性节点风险项又多了一个，还是看公司业务安全需求情况。
A44：
前面说的F5再怎么样也是商采，自建要考虑的可用性，还有安全防护、漏洞升级运维一堆破事，出问题系统全部没法访问，担不起。
在关于在前端使用AES加密并硬编码秘钥的讨论中大家存在着不同的观点，一些观点认为这样的做法主要风险在于密钥的硬编码容易被爆破，导致登录接口的安全受到威胁。其中，一些建议采取人机验证、验证码、使用动态分发密钥或证书等方法来增强安全性。另一些观点认为在前端加密对于保护前端代码透明性来说意义不大，且前端加密并不能替代HTTPS协议的使用。还有一些观点提到了非对称加密、哈希算法、加盐等加密技术的应用。总体而言，前端使用AES加密且硬编码秘钥存在一定的风险，需要综合考虑安全性、合规性和业务需求来选择合适的加密方案。
在第二个话题讨论中，关于SSL与明文传输的关系，大家总体思维比较发散，但总结起来，SSL提供了加密的通道来保护数据的安全传输，虽然数据在传输过程中可能被抓包、被中间人获取，也是以密文的形式呈现，无法被直接读取，可根据具体需求和安全要求，可以采取适当的措施来保障数据的安全传输。
Q：现在能源行业有哪些成熟的安全运营体系建设标准，作为甲方应该如何建设好自己的安全运营？
A1：
能源行业里面每个细分行业领域，玩法都不一样，但又很重要。
简单说下，能源分为电力、煤炭石油天然气、新能源、能源节约、核电等，电力又分为发电和配电，发电又分五大四小以及风火水核光伏等，其中行业要求有《电力行业网络安全监督管理办法》《电力行业网络与信息安全管理办法》《电力行业网络安全等级保护管理办法》等， 另外能源企业可参考细分行业标准，比如DL-（电力），配电行业可参考GDW，其中比较重要的有电力监控系统安全保护规定等。总之能源行业的网安标准主要针对电力，其中复杂的是发电行业（因为配电行业封闭），发电行业中还有细分，需要你根据本企业类型去查找相关风火水核等标准。
A2：
安全运营体系建设，好像一些厂家都有套书吧，适用性挺强的。能源行业无非就是工控方面可能要针对性的考虑一下，经营管理、日常办公方面的就大同小异吧，通用的安全运营体系应该蛮适用的，而且能源行业基本都是国字头的，有集团公司总部那边统筹开展网络安全运营工作，也不是一张白纸。
Q：模糊测试是黑盒测试，这句话是对的吗？拿AFL来看的话，应该不能说模糊测试是黑盒吧。
A1：
对，CISP是这么说的。
A2：
模糊测试有时属于黑盒测试，有时属于白盒测试，取决于其使用的测试方法，我感觉应该选这个更准确啊。
A3：
白盒带授予的权限，不算模糊了。
A4：
这句话本身就是先定义了模糊测试的范围，但是从模糊测试的思想上来讲，通过拿到源码编译插桩的方式。为什么不叫模糊测试呢？我看现在和供应商聊，更多的把模糊测试定义成灰盒。
A5：
啥叫灰盒？这个词应该存在吗？
A6：
灰盒(Gray Box)是一种程序或系统上的工作过程被局部认知的装置。灰盒测试，也称作灰盒分析，是基于对程序内部细节有限认知上的软件调试方法。测试者可能知道系统组件之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的黑盒。
A7：
按这个解释 其实就只有黑盒和灰盒。很难把所有信息、流程、规则都讲明白，永远到不了1。
A8：
所以我一直认为这白、灰、黑都是相对的，只是一种思想而不是一种方式，所以Fuzz也不能直接定义成黑。
A9：
黑是0，白是1，灰是0-1，问题是1无法界定。
A10：
比如针对XSS的测试。我觉得就是灰，因为可以看到前端JS逻辑 但是看不到后台服务代码的逻辑。
A11：
灰要看到什么程度，最底层的灰就是黑。
A12：
但是在某种工具上对XSS扫描，就定义是黑；知道部分代码或部分逻辑、进程等我认为就是灰；完全盲测，回显都没有的那种 我认为才是黑。感觉这些概念越弄越迷糊了，要好好再理解一次。
Q：《商用密码管理条例》里说的密码，不是说的是用户名密码那种密码吧？
A1：
这提到的都是供应侧+认证管理侧。
A2：
只指加密算法这些吗？
A3：
不是，主要是算法+协议，还有密钥管理。
A4：
我们作为用户能接触或者能避免违规的是点是什么，因为大部分情况我们能接触到的起码是产品吧，算法+协议都太底层了吧？
A5：
1.尽量不用国外的加密算法、加密产品、加密工具系统，甚至强制绑定国外算法的系统；
2.如果必须用，选用国内符合标准（权威的）的算法+产品+系统；
3.定期开展评估+认证审查；
4.多用信创；
等等。
上期话题回顾：
活动回顾：
国家网信办等七部门联合公布《生成式人工智能服务管理暂行办法》
FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。
原文始发于微信公众号（FreeBuf）：前端AES加密算中高危吗；企业内部用中间人解密靠谱吗 | FB甲方群话题讨论
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论