V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
wenzaiquan199
V2EX  ›  问与答

为安全问题,早上公司热烈讨论

  •  1
     
  •   wenzaiquan199 · 97 天前 · 12174 次点击
    这是一个创建于 97 天前的主题,其中的信息可能已经有所发展或是发生改变。
    场景:用户在前端绑银行卡,实名认证,前端通过 https 请求,明文将数据传给后端,故测试给我提了个 bug 要我前端加密传输,我网上搜了搜,觉得前端目前拿不出什么方案加密比 https 安全

    测试:你这个东西加个密传给后端
    我:有 https ,有一定的安全保障了
    测试:但是我接口请求能看到我的身份证号什么的
    我:你能拦截到别人的请求么
    测试:那肯定有人能拦截到
    我:我随便加个加密可以,我们代码没做混淆,别人看代码直接知道什么加密方法,随便解了,别人能从 https 把这个解析出来,破解我们这个跟玩一样,加了有意义么
    测试:我之前公司都做了啊

    遂测试找前端 leader 说,然后后端 leader 就说前端传过来不用加,后端给前端加密的数据就行了,前端 leader 说要,然后他们吵了半天

    末了前端 leader 跟我说,要有“安全意识”,我直接回你项目混淆都不做,我从加密库找个现成的加密方法,有用么

    遂结束,我也不理 leader 了,来看看大家什么意见
    第 1 条附言  ·  97 天前
    可能大家误解我的意思了,我不是说前端加密没用
    首先这事是我做一个功能时,然后测试给我提的 bug ,她的意思我懂,就是不想要明文传给后端,那我觉得我不懂这一块,总不能上网真搜个什么常用加解密就跟后端搞了吧,所以我就拒绝了,安全的事情让她去找前后端领导让他们决定或者出方案排期,然后前后端领导就吵起来了,后端领导觉得不用,前端领导觉得要用,前端说不过后端,然后跑来找我们撒气,说我们前端开发没有安全意义,给我整毛了,我也没见他平时对我们项目做什么安全方面的要求处理,现在吵不过别人就来找我们撒气,回了他一嘴
    当然我知道加密比不加密有用,但是如果我加密的效果真是 base64 那种方案,那有什么意义呢
    第 2 条附言  ·  96 天前
    我不知道是我没表述清楚还是什么,我没说测试发现这个问题有问题,安全这是一个大问题,但是这是一个 bug ,难道我要来个 base64 糊弄一下么,这是需要完整方案的东西和规范的,要不要加密?怎么加密?加密到什么程度?

    所以我跟她的态度就是这个不是 bug ,是个大东西,这次我修复不了,她不肯,一定要我这次加,我说你一定要我加,去找前后端 leader 给我方案,安全相关的东西我负责不了,经验不够

    然后前后端 leader 开始吵了,后端 leader 的观点是,前端不需要,https 保证了大部分安全的场景,后端方面加密数据给前端就行了,而且我们一没规范,二人员少(开发团队前端+测试+后端+2leader 总共 7 个人),要搞这方面的东西话投入太多,取舍的话就是没必要

    前端 leader 也在那吵,说要,一定要,但是拉着后端老大吵了半小时什么技术方案不给,说来说去就是 https 就不安全么巴拉巴拉,我能怎么怎么破解,最后后端老大不想理前端老大,然后前端老大跑到我们前端面前说我们前端没安全意识,我就烦了,他自己一直没出什么安全方案规范,甚至公司的项目混淆没混淆都不知道,最后丢到我们干活的头上,我就回了
    188 条回复    2022-09-03 22:25:38 +08:00
    1  2  
    xiao109
        1
    xiao109  
       97 天前   ❤️ 2
    他要加密那就加密呗,urlencode 一下。反正是混 KPI 嘛
    wenzaiquan199
        2
    wenzaiquan199  
    OP
       97 天前
    @xiao109 我知道能加呀,我觉得没必要,https 对我们这种项目来说够安全了,然后测试告到前端 leader 那,然后前端 leader 跟后端 leader 吵了一架,然后又说我没安全意识我直接呵呵
    singerll
        3
    singerll  
       97 天前 via Android
    个人感觉还是有用的,至少可以提高入侵的难度,比如有人要爬虫爬你,简单的加密就能过滤很多入门级的爬虫。
    boshi
        4
    boshi  
       97 天前   ❤️ 2
    @wenzaiquan199 做过有些项目确实指定要用国密,客户要得话就加一个,毕竟人家只是看要,不过测试提出来这样也是奇葩
    madNeal
        5
    madNeal  
       97 天前
    前端加密很多地方也是要求做的,最通常的场景是密码,尽管最终可能别人还有办法破解,但安全很多场景是提高攻击者的成本,讲究纵深防御,所以加了肯定比不加好
    dzdh
        6
    dzdh  
       97 天前   ❤️ 7
    不用控件、插件、硬件加密的前端加密都是耍流氓。

    实在不行给他 base64 一下
    XD2333
        7
    XD2333  
       97 天前   ❤️ 1
    混淆也能被破解逆向,加比不加好,提高成本和难度。
    winterbells
        8
    winterbells  
       97 天前   ❤️ 3
    有时测试的想法是挺好玩的,明明自己不懂,还非要别人满足 ta 的想法
    murmur
        9
    murmur  
       97 天前
    该加密加密一下,直接给他上国密算法,到时候国产化合规也算做了

    其实这样不算国产加密合规,国产加密得买专门的密码机
    eason1874
        10
    eason1874  
       97 天前   ❤️ 2
    在业务上加密有用的,可以对抗部分抓包、代理

    之前在信用卡社区看到很多人教别人用抓包 APP 去抓银行 APP 的 HTTPS 请求,有些二次加密的抓了他们也解不了,没有加密的他们抓了就能看到明文数据,从里面看出银行给自己的打分
    R18
        11
    R18  
       97 天前 via Android   ❤️ 1
    前端 leader 说要那就加呗。简单的编码,中等的非对称,高难度硬件加密
    Martin9
        12
    Martin9  
       97 天前   ❤️ 19
    没必要顶你 leader ,你现在没决策权,让你干啥干啥就行了,因为这是公司的项目,不是你自己的。很多事情就算觉得很蠢但也要干。
    人的成长就是慢慢受锤的过程,大家都是这么过来的。
    zr8657
        13
    zr8657  
       97 天前
    赞同#12
    非要扯那肯定是加密好,但是确实没什么意思。base64 糊弄下也就过去了。
    sss495088732
        14
    sss495088732  
       97 天前
    op 都说了没混淆,做了跟没做有什么差.真当逆向的都是傻子了..这是瞧不起谁啊
    没混淆你加不加密能提升多少成本..几分钟都算多了.
    wolfie
        15
    wolfie  
       97 天前
    让测试作为中间人抓个包试试
    xsqfjys
        16
    xsqfjys  
       97 天前
    测试? base64 糊弄之
    dacapoday
        17
    dacapoday  
       97 天前
    前端这个不叫加密,是编码。如果是合规走形式,安全上加分。如果是真攻击,防御收效甚微。
    stoluoyu
        18
    stoluoyu  
       97 天前
    把态度表明,领导让做就做,让他自己协调前后端资源。
    另外这种加密还是有个好处的,有些产品会有半把刀用户,打开浏览器开发者工具一看,「这网络请求里有我明文的信息,不安全啊」投诉。
    DOLLOR
        19
    DOLLOR  
       97 天前 via Android   ❤️ 6
    // 注:以下操作是测试要求加的,但我觉得没卵用。由此产生的一切问题由测试负责。
    twl007
        20
    twl007  
       97 天前 via iPhone
    https 再不安全 把整个互联网就没安全的了

    建议你让测试当场给你表现一下如何解开 https 加密 顺便发个论文更好
    Roanapur
        21
    Roanapur  
       97 天前
    加呗。又没多少成本。感觉没必要争。

    我一般的态度是:告诉他们这玩意没有意义,但如果他们要,我可以加。

    我就一个搬砖的
    456789
        22
    456789  
       97 天前   ❤️ 1
    建议 base64 一下让傻逼舒舒服服的傻逼
    mxT52CRuqR6o5
        23
    mxT52CRuqR6o5  
       97 天前
    老板让你加你就加,具体为什么这么做参考这个回答
    https://www.zhihu.com/question/340109086/answer/1709378074
    cweijan
        24
    cweijan  
       97 天前
    敏感信息加还是有必要的, 主要是防捉包, 加密后能劝退不少不熟悉前端的人..
    shyangs
        25
    shyangs  
       97 天前   ❤️ 7
    「大衛像」剛完成時,當時市政廳官員正好來巡視,其中一人看著大衛像,皺起眉頭對米開朗基羅表示,大衛的鼻子似乎高了點,眾人也跟著附和著。

    一向對自己作品有所堅持的米開朗基羅默默爬上鷹架,一手握著鑿子,另一手卻偷偷抓了一把沙子,他故作聲響地敲打,一邊卻將沙子往下丟,飛塵與沙粒就這樣灑在官員臉上,不到一會兒工夫「修改」完成,官員滿臉粉塵的用那被沙粒弄得睜不開的雙眼,對著米開朗基羅讚許「不錯不錯,這樣好多了!」。

    事實上,大衛的鼻子或任何其它部位仍維持原來樣貌,米開朗基羅趁機捉弄官員一鼻子塵灰。



    --------


    有些人,把 base64 也當加密,你就 base64 一下,測試看看他們是不是外行人唄.
    timethinker
        26
    timethinker  
       97 天前   ❤️ 3
    看来本楼还有很多人不知道 HTTPS 是用来解决什么问题的。
    nekoneko
        27
    nekoneko  
       97 天前
    @twl007 #20 可以伪造证书抓包的, 当然, 这是用户的主动行为
    codingBug
        28
    codingBug  
       97 天前
    没理解“项目混淆都不做”是什么意思,难道开发不用框架?框架打包生产环境的时候会有混淆,明文传输明显就不安全,需要和后端统一加密算法和密钥
    dcsuibian
        29
    dcsuibian  
       97 天前
    没必要,但是可以加。

    如果我是攻击者
    ①先得用假证书或假浏览器之类的把 https 解开来
    ②筛选你们网站的流量
    ③然后再研究从你们的用户输入到请求内容之间的变化路径

    第一步很难了,第二步更是把范围缩小到对你们的定向攻击,相比而言第三步。。。

    很多所谓的“安全做法”就是这样的,你做了,确实可以提高门槛、增加安全性。但收益真的不大。
    peizh2006
        30
    peizh2006  
       97 天前
    Defense in Depth 了解一下,遇到这种前端我也是懒得废话的,有什么好争论的
    ZField
        31
    ZField  
       97 天前
    https 就是加密啊……
    如果 https 都不安全那就说明客户端已经摆烂了,客户端都摆烂了,前端搞再多加密又有什么用。
    之前工作中最心累的就是跟测试聊实现,明明不懂还很有自己的想法。
    456789
        32
    456789  
       97 天前
    @shyangs 异曲同工之妙
    mxT52CRuqR6o5
        33
    mxT52CRuqR6o5  
       97 天前
    @peizh2006 前端是没法验证根证书的,所以在前端层面做的任何措施数学上都是不安全的,前端做的安全措施根本就不能算在 Defense in Depth 里
    fengye0509
        34
    fengye0509  
       97 天前
    都是出来挣钱的,他让加就加,安全不安全的,又不关你的事
    min
        35
    min  
       97 天前   ❤️ 1
    情商高一点啊,怼人干什么。

    公司有标准就按标准来,没标准 leader 们商量一个出来,按照标准执行
    newHunter
        36
    newHunter  
       97 天前
    加完好摸鱼,现在闹这么难看,心累
    shakoon
        37
    shakoon  
       97 天前
    用 cfca 的国密控件就完事了,也不复杂,而且这还是重点行业明文的要求。缺点是,密码框不能粘贴,密码保存软件将无法保存到真正的密码。
    xuelu520
        38
    xuelu520  
       97 天前
    base64 ,假装一下。
    Cbdy
        39
    Cbdy  
       97 天前 via Android
    随便给他 base64 意思一下,打工而已,你又不是老板
    twl007
        40
    twl007  
       97 天前   ❤️ 1
    @nekoneko 用户都能把不信任的根证装电脑上了 人家真想拿数据还用得着这么费劲么

    https 在绝大多数情况下提供了足够的保护了 只要不去用 TLS 1.2 以下的版本 那安全性绝对有保障的 不知道怎么说这个测试…… 就像当年大家问为什么 chrome 密码不加密一样 人家 google 就说了人家都能从你电脑上拿到文件了 还有什么做不到的

    信用卡信息说实话感觉在 log 里面泄露的问题比 https 严重多了
    wenzaiquan199
        41
    wenzaiquan199  
    OP
       97 天前
    @min
    我没怼啊,他测我的东西看见这个给我提了个需求,天天测试就测试,按自己的想法加需求,我就拒绝了,然后说了 https 管用,她不信,然后问前后端 leader ,然后前后端 leader 吵起来了, 哈哈,前端 leader 说不过后端 leader 然后说我们前端平时开发没安全意识 :(
    dearmymy
        42
    dearmymy  
       97 天前
    这种过程做加密,一般增加黑客做自动化成本。或者一些恶意提交。至于接口有没有必要,就得结合实际判断了。
    不要以为 https 就完全安全了。现在攻击方式也多样化了。
    matepi
        43
    matepi  
       97 天前
    真敏感交易,没有防重放么?

    有防重放的话,比较一般的设计都就已经有摘要或加密了。最多搞个盐之类的简单弄弄,说得过去就行了
    abersheeran
        44
    abersheeran  
       97 天前
    总有没有安全知识的傻鸟用自以为安全的方式来满足自己的安全意识。
    different
        45
    different  
       97 天前
    其实我挺赞同前端的观点的。
    https 跟前端加密貌似不完全冲突,两者解决问题的侧重点也不完全一样。
    可以看看百度、腾讯等,基本所有页面的 post 请求都会加密,混不混淆没仔细看。

    前端加密这不就好比验证码吗?我觉得两者的意义很大程度上是一样的,阻挡一波机器人。
    如果你提到的“用户在前端绑银行卡,实名认证”这个功能没有做任何机器人校验,那不安好心的人是否可以轻而易举的搞成自动化流程?

    就好比普通 win 电脑加个密码,防君子不妨小人,会因为电脑资料能被窃取而不锁屏吗?

    以上个人观点。
    saucerman8
        46
    saucerman8  
       97 天前
    身份证这种敏感信息,传输过程中肯定要加密啊,https 是为了防止中间人拦截,前端加密是防止协议被破解,这是两码事啊。
    parad
        47
    parad  
       97 天前 via Android
    PCI DSS
    saucerman8
        48
    saucerman8  
       97 天前
    因为没做混淆,所以就不做加密了,那为什么不提议也同时做个混淆呢?这是纯前端自己摆烂啊
    mxT52CRuqR6o5
        49
    mxT52CRuqR6o5  
       97 天前
    web 端在 https 也不安全的场景下,攻击者可以直接伪造一个长得和你一模一样的页面去钓鱼,根本不用去研究你代码里做了多少种额外的保护措施,因为 web 端的代码也是通过 https 下发的
    桌面端为什么做类似的事有意义,因为桌面端的程序不是在线下发的,我们可以假设这个桌面端程序是可信的
    mxT52CRuqR6o5
        50
    mxT52CRuqR6o5  
       97 天前
    接上一楼,因此在 web 端整这些没用的前端加密,不如去整 OTP ,因为 OTP 不是在线下发的
    darknoll
        51
    darknoll  
       97 天前   ❤️ 4
    不谈要不要加密,他一个测试有什么权利提新的需求
    wenzaiquan199
        52
    wenzaiquan199  
    OP
       97 天前
    @saucerman8
    不,你理解错我的意思了,首先这事是我做一个功能时,然后测试给我提的 bug ,她的意思我懂,就是不想要明文传给后端,那我觉得我不懂这一块,总不能上网真搜个什么常用加解密就跟后端搞了吧,所以我就拒绝了,安全的事情让她去找前后端领导让他们决定或者出方案排期,然后前后端领导就吵起来了,后端领导觉得不用,前端领导觉得要用,前端说不过后端,然后跑来找我们撒气,说我们前端开发没有安全意义,给我整毛了,我也没见他平时对我们项目做什么安全方面的要求处理,现在吵不过别人就来找我们撒气,回了他一嘴
    当然我知道加密比不加密有用,但是如果我加密的效果真是 base64 那种方案,那有什么意义呢
    different
        53
    different  
       97 天前
    @different [45 楼] ,“其实我挺赞同前端的观点的。”->"其实我挺赞同测试的观点的。"
    masterclock
        54
    masterclock  
       97 天前
    应当考虑一下 https 通信结束后进入“系统内部”时的问题,比如有个新来的运维是不是直接就能看见敏感信息了?
    wenzaiquan199
        55
    wenzaiquan199  
    OP
       97 天前
    @different
    这个前后端领导吵架的时候,我们也调研了一下,加密的有,不加密的也有
    主要我是很烦测试测着就来个新需求,她觉得这个安全需求很简单,但是我又不想搞个什么 base64 ,不然就是自己骗自己,让她去找前后端领导自己商量,前端领导吵输了回来说我们开发没安全意识,就给我整毛了,平时没见他给我们做相关要求,自己开发也没搞这些,吵输了来 aoe 我们,我就回了他
    byte10
        56
    byte10  
       97 天前
    这个世界还是土鸡多。OP 可以让他们证明,演练 "不安全的"。 另外楼上提的也挺好,可以 base64 糊弄下,因为土鸡不知道 base64 只是编码。

    如果是在一般的公司,那么大概率就会遇到很多菜鸡,建议躺平吧,你跟不讲道理的人,讲不清楚的,他们认知低,学习能力差。可以去努力 去好的公司,遇到土鸡的概率 较少
    byte10
        57
    byte10  
       97 天前
    OP 可以直接把这帖 转给你们群里,多截图。
    Hse7enD
        58
    Hse7enD  
       97 天前   ❤️ 19
    我就是做安全的,我阐述一下自我观点。
    首先你要明白什么是安全。在编程的世界里没有绝对的安全。
    在编程的世界里没有绝对的安全(项目混淆都没做,我接口参数加密个屁有啥意义,浪费大爷我时间)。你不可能拿着这句话就说不用加密不用处理安全防护机制了。所有的安全都是再说提高破解和逆向分析难度而已。

    人家测试提一下意见没毛病,至于加不加公司和项目组决定。项目没混淆你可以提意见,像测试人员一样发现问题反馈,至于做不做自己无法决定时,可以反馈项目组。项目没任何破解价值那就有精力再考虑。

    可以一步一步做提高项目的安全高度。
    比如:
    1.如果没防护攻击者是 100 人。那 100 人也拦截不了。
    2.如果做一点防护攻击者是 100 人。那可以拦截 20 人。
    3.如果做更多防护攻击者是 100 人。那可以拦截 80 人。
    4.如果做更多更多防护攻击者是 100 人。那可以拦截 99 人。

    没人能做到 100%防护,列如:苹果能被越狱。微信、抖音等 App 可被破解,很多外挂(人家做了多少安全的东西,还是会被他人破解。不能因为少数人破解就不加密不做安全了。主要目的是提高逆向难度)。
    N1ckl32
        59
    N1ckl32  
       97 天前
    提供一个解决办法:
    由信息安全部门牵头搞一套敏感数据加解密方案,并落地实现作为 jar 包嵌入到业务部门系统中,可以解决这个 OP 问题;
    将敏感信息加密传输,可以相对的降低信息泄露的风险。
    wtf12138
        60
    wtf12138  
       97 天前
    安全小白歪楼--为什么说前端加密都没有用啊,非对称加密也能被破解吗?前端用公钥加密这种
    wenzaiquan199
        61
    wenzaiquan199  
    OP
       97 天前
    @Hse7enD
    老哥,我懂你的意思,做肯定是不做有用一点,测试一开始让我加,我觉得这玩意是他自己发现的需求,你目前拿来当个 bug 给我提肯定不合适,因为我不懂,我也没相关处理经验,所以我拒绝了,让她去找前后端 leader 讨论,当然我也可以就 base64 给她转码,但是那不是自欺欺人么?
    安全我觉得是个大的需求,不是测试提一个 bug 可以解决的
    然后就是前后端 leader 吵,前端的吵不过后端的,然后喷我们没安全意识,所以我就回嘴
    wenzaiquan199
        62
    wenzaiquan199  
    OP
       97 天前
    @N1ckl32
    没安全信息部门,前端 4 个人,leader 不写代码,3 个人干活,后端 2 个人
    lindas
        63
    lindas  
       97 天前
    @wtf12138 把 base64 当加密了吧
    pastor
        64
    pastor  
       97 天前   ❤️ 7
    1. https 主要是解决数据链路上的中间人问题,比如各种代理软件、甚至被黑客入侵的 ISP 节点。如果没有 https 、中间人直接看到你内容,太不安全了
    2. 前端加密不全是为了解决中间人问题,比如考虑下公共电脑,上一个用户登录上去了忘记退出或者关闭,下一个用户 F12 一看,哦豁,上一个人的用户名密码都拿到了。甚至,比如你自己电脑,刚好自己上厕所走开一会忘记锁屏了,其他人“一不小心”就知道了你的相关信息。这一层加密至少提高了门槛,能把绝大多数不必要的低级泄露避免掉
    3. 至于前端代码不加混淆,那是他这一层的安全问题,可以建议他们也加上混淆之类的

    我对安全这块研究不深,但觉得 OP 家的测试提出问题说明测试还是挺专业的,至少相比于 OP 家目前的后端团队靠谱。

    在自己舒适圈习惯了的人多数都不喜欢被别人提建议,这种心态不好,建议 OP 和一些楼层放下这种心态,平和一些对待测试。尤其是,更不要去随便鄙视人家,很可能最后发现小丑竟是自己。
    我曾经也像 OP 和一些层主一样,抵触外界干扰,别人说点啥就觉得别人找事、别人菜鸡,但其实是因为自己还太年轻无知,工作久了逐渐意识到自己的缺点,然后花了很长时间去有意识地让自己改正。没什么丢脸的,自己进步了去争取做到海纳百川有容乃大,壁立千仞无欲则刚,于人于己,都挺好的

    说的不一定对,欢迎批评指正或补充
    pastor
        65
    pastor  
       97 天前
    补充问一下:OP 家的数据库里存的也是明文吗?
    xylxAdai
        66
    xylxAdai  
       97 天前
    不重要。leader 让你加你争辩几句争不过随便加了就完事了。工作而已。不用太当真。说白了公司请你来不是让你来当安全顾问的,是让你来按要求做事的。
    littleylv
        67
    littleylv  
       97 天前   ❤️ 2
    @pastor #64 “上一个用户登录上去了忘记退出或者关闭,下一个用户 F12 一看,哦豁,上一个人的用户名密码都拿到了。”

    请问如何做到“下一个用户 F12 ”还能看到上一个用户的请求记录的?据我所知 Chrome 的 F12 的网络页签只显示打开 F12 之后的请求
    ksedz
        68
    ksedz  
       97 天前
    有必要的,中间人可以拿到数据。
    虽然如果能中间人了加密不加密对这个应用没什么影响,但是用户可能不同应用使用相同的密码,加密可以保护用户其他应用账户的安全。
    ysc3839
        69
    ysc3839  
       97 天前   ❤️ 1
    前端加密可以防窃听但防不了针对性攻击,比如后端解密 https 之后经过了某些不可控的负载均衡器之类的,或者客户端有某些恶意浏览器扩展,或者能解密 https 流量的间谍软件,这些软件往往只是广撒网记录所有流量,然后攻击者再人工分析筛选出信息,此时前端加密是有用的,要不要用也是看是否需要防御此类攻击。
    SHOOT
        70
    SHOOT  
       97 天前
    加密随便忽悠一下就是了,很多时候是给客户演示看的,客户可不知道这些,但是在演示的时候客户能看到明文密码就肯定会提意见。打个工而已,如果做个小事能避免冲突那就顺手做一做咯
    newmlp
        71
    newmlp  
       97 天前
    @madNeal 如果别人连 https 都能给你攻破了,你这前端加密能提高多少成本,比 https 破解难度还高吗
    lmhsmart
        72
    lmhsmart  
       97 天前
    可以搜一下 tls 卸载,不加密还是有风险的,有很多黑灰产就是在边缘节点或者运营商节点上加监听产品(流量分析),抓这些账号密码明文
    tutou
        73
    tutou  
       97 天前
    可以用非对称加密
    lmhsmart
        74
    lmhsmart  
       97 天前   ❤️ 1
    补充一下不加密可以被利用的点:
    1. 内网泄露,比如日志打点数据
    2. 传输过程泄露,公网走 TLS ,但是在边缘节点卸载,可通过在机房部署数据采集劫持用户数据。或者 tls 证书泄露
    3. 客户端泄露,木马、手机权限被接管,app 内部漏洞,csrf 、xss 等漏洞,使用不标准的 sso & oauth 协议等
    SimbaPeng
        75
    SimbaPeng  
       97 天前
    @newmlp 谁告诉你需要破解 https 才能拿到数据?
    pkwenda
        76
    pkwenda  
       97 天前
    那既然这个事儿已经上升到这个层面了,那就做透:
    1 、生成公私钥对儿
    2 、前端公钥加密
    3 、加密传输
    4 、后端私钥解密

    让领导评估开发成本,注意:这个时候把决定权让给领导,他说干啥就干啥
    如果用 base64 就用 base64

    你也可以说用 MD5 加密测测他们的智商在不在线(就是可能误伤自己)

    如果领导认可非对称加密方案,就复盘一下公司所有的出口流量敏感数据,提出:组内业务全部调整的想法
    吐过领导够魄力整体调整,KPI 就来了



    嘿嘿
    pkwenda
        77
    pkwenda  
       97 天前
    @pkwenda

    让安全工程师,魔改路由器,管你什么入侵阿里云、拦截路由器、wifi 什么方法,你先拦截到流量,反正一定要模拟真实黑客
    fengci
        78
    fengci  
       97 天前
    看楼上说了那么多。 还是 @Hse7enD #58 说的最靠谱。
    securityCoding
        79
    securityCoding  
       97 天前
    加一下好点,日志也很容易泄露的
    mejee
        80
    mejee  
       97 天前
    看要求。如果为了安全而要加密,这个理论是站得住脚的。

    https 安全,也不安全。举个例子,你用公司的电脑聊微信,如果微信不加密,只用 https ,有一定概率你们公司的网络是可以监听你的微信聊天记录的(公司的电脑被动了手脚),所以还是看场景。

    https 安全的前提是:用户使用的当前设备是没有被做过手脚的。

    所以还是看你们老板的想法,以及你们具体的要求,对安全程度的要求是什么。
    essicaj
        81
    essicaj  
       97 天前
    增加一下破解成本其实还是可以的,至少从用户或者客户的角度去看,加多一层密,就多一分安全。
    ic2y
        82
    ic2y  
       97 天前   ❤️ 1
    不管是不是 https 的,涉及到机密信息,必须要加密。在大公司里,不加密的行为会直接判定为 安全缺陷。

    可以使用非对称加密,增加安全性。

    如果不加密,主要问题是:即使用了 https ,能保证网关之后的安全性么?现在架构都这么复杂,多层网关,再配上微服务。如果哪个 api 网关什么的 不巧记录了日志,而日志里又记录了请求参数,那赫然明文记载了身份证号码等敏感信息,这就跟当年携程的安全事故差不多了。

    可以看看历史新闻:
    https://www.163.com/tech/article/9O14EOS3000915BF.html

    有时候,难保有猪队友。谨慎为好。
    pmispig
        83
    pmispig  
       97 天前
    前端也用 rsa 加密,这样别人就没办法了,哈哈
    dddd1919
        84
    dddd1919  
       97 天前
    敏感信息别放在 url 参数里,全都塞到 request body ,那传输就是加密的,还要咋加密???

    抓包工具和系统证书信任都去了,看看他能抓到 https 的请求内容不
    AndyLuo
        85
    AndyLuo  
       97 天前
    加密算法其实不是“别人知道我用什么就不安全了”。加密算法是“别人知道我用什么依然也解不出来”,或者说“在一定时间内解不出来”(超出这个时间消息无价值,解出来也无所谓,例如某一时刻的 OTP )。
    如果能加真的是加一下比较好?当然是从安全性角度来说
    Al0rid4l
        86
    Al0rid4l  
       97 天前
    前端加密仅对反爬, 不希望用户看见隐藏的数据有意义, 还是在配合其他无头浏览器检测的情况下
    Al0rid4l
        87
    Al0rid4l  
       97 天前   ❤️ 17
    这帖子里喜欢自欺欺人的这么多?
    一问就是都说要加密, 就没一个人来说说加密防谁呢? 不讨论防谁隔这扯加密找心理安慰呢?
    防中间人, 那一通操作下来最多就是自己重新发明 TLS
    防爬虫逆接口, 那为啥只加密这个接口? 其他接口加不加密? 早干嘛去了呢?
    防内鬼, 防内鬼来找前端加密怕不是有什么大病?
    一群人活在自己的剧本里, 我加密了, 那他肯定要来破解我对吧
    这种事情做下来就是, 中间人想的是怎么钓鱼怎么骗用户装证书怎么降级, 尽量直接把数据搞到手, 能搞的怎么都能搞, 不能搞的怎么都搞不了, 和你加密不加密没啥关系
    爬虫想的是能不能不逆这 js 了, 咱直接跑个无头浏览器完事
    内鬼想的是, 害, 我都是内鬼了都能直接接触生产服务器了, 还费这事干嘛

    还有典中典的诸如虽然我研究不深但我觉得他挺专业的, 虽然我不懂, 但加密了应该有用吧
    那你咋不去写单元测试呢, 单元测试也有用也显得专业不是, 哦, 一问成本太高没时间, 属于是真有一头牛了是吧
    且不说测试有没有资格提需求, 提需求开会出文档走流程啊, 让他文档里说清楚哪里不安全, 哪些数据会被盗, 怎么个盗法, 什么「我接口请求能看到我的身份证号什么的」, 你问他是不是弱 X 吧吧友, 让他仔细品一品这话, 我盗我自己是吧

    以前别人说阿三我还跟着笑, 这帖子看下来大半的人和阿三也差不多
    xsen
        88
    xsen  
       97 天前
    @dddd1919 #84 敏感信息明文,这本身就是最大的问题
    pastor
        89
    pastor  
       97 天前
    @littleylv 兄弟,绝大多数 cookie 或者 token 失效前,你先 F12 然后刷新下页面就能这样了
    pastor
        90
    pastor  
       97 天前   ❤️ 2
    @Al0rid4l 你看举的例子了吗?

    前端的加密能防什么?
    TLS 防的是什么?

    这两点我前面说过了,再补充一些:
    数据库为啥不应该存明文密码之类的,是为了防什么?
    因为怕服务被入侵被脱裤之类的,不存明文至少防别人直接拿明文密码来登录然后盗资产之类的
    服务被入侵的事件比例不是很大,但是数量还是很多

    负责每个业务层次该的防的安全事项能做就做上,没什么不对的。如果照这样说,不只是 web 前段,即使是原生.so .a 别人也照样能反编译,只要肯花足够时间破解你,谁也不能保证自家代码百分百安全。后端我上面密码数据库不存明文也说了,自家服务都有被入侵的可能性。
    所以,安全防护根本就做不到百分百!
    那既然没有百分百,是不是就都不用做了?

    我提醒你一下,首先认清自己是在地球,不是三体星,建议等你飞升到三体星在用三体人的思维思考问题,不要自以为懂地上来就一顿喷。
    另外,"还有典中典的诸如虽然我研究不深但我觉得他挺专业的, 虽然我不懂, 但加密了应该有用吧",这是我谦虚的说法而已,再研究不够深入,感觉也比你那一楼的看法要更懂吧!你还真以为自己很懂就来乱批判啊?

    都说谦虚使人进步,我想进步,结果这咋还我谦虚使其他人自以为是了呢!
    我要检讨!我不能再这样谦虚了,否则准被你们这些真小白带歪了节奏!
    Al0rid4l
        91
    Al0rid4l  
       97 天前
    @pastor 是前端不加密你数据库就加不了密了还是咋地? 数据库明文和前端加密有关系? 您别谦虚了, 您只是虚得不行, 谦和您没啥关系
    mytsing520
        92
    mytsing520  
       97 天前
    交给前后端 leader 的 leader 去决定
    hxndg
        93
    hxndg  
       97 天前
    @pastor
    纠正几点东西,tls 的作用是在一个不安全的网络环境进行安全传输,严格来讲 pki 体系才是用来对抗中间人的。
    至于“负责每个业务层次该的防的安全事项能做就做上”,这个是看要提供的安全保证是什么,一般如果没有明确的需求不建议自己定安全需求。
    vivipure
        94
    vivipure  
       97 天前
    加密有用 ,但只有一点点。应付下测试就 ok 了。
    shyangs
        95
    shyangs  
       97 天前
    @pastor

    資料庫存不存明文密碼,這是後端的事,樓主是前端,討論的也是前端加密.

    任何有強度的加密(非對稱、插件、外掛、硬體加密、OTP ),都是後端主責,前端難道能自己決定加密方案,自己實現?都是後端主刀、前端配合.

    現在是測試提需求,前端想主刀?
    dNib9U2o8x
        96
    dNib9U2o8x  
       97 天前
    这个不纯算是技术问题,应该是人情世故
    pastor
        97
    pastor  
       96 天前
    @Al0rid4l #91
    @shyangs #95

    你俩这两楼误解我意思了。我上面举数据库的例子是为了说明任何措施不能保证百分百,还包括社工之类的。
    因为我看 @Al0rid4l 的观点给我的感觉就是”既然前端不能百分百还做它何用“,所以举例子说明:
    不只是前端,后端、数据库同样不能保证百分百,但是后端、数据库仍然要做;
    进一步来反驳 @Al0rid4l “做它何用” 的观点,不是用来论证因为数据库需要密文所以应该由前端开始密文。

    但是话说回来,至少我遇到过的合理的项目,都是从前端开始密文的,前面也举过前端页面别人 F12 的例子了,麻烦 @Al0rid4l 看明白了再来评判
    pastor
        98
    pastor  
       96 天前
    @hxndg 我对 tls 的描述不准确,感谢指出!

    "一般如果没有明确的需求不建议自己定安全需求。"
    这个除了少数安全要求很高的项目,绝大多数场景,都是程序员自己负责了基本的安全策略,不可能每个公司都专门的安全部门去指导业务开发来实施这个,比如我上面举例子的几点,虽然没人明确列出行业规范,但类似的实现也差不多是基操了。所以说没有明确的需求是正确的,但是业务程序员自己不去管安全需求也是不太正确的
    fkdog
        99
    fkdog  
       96 天前   ❤️ 2
    国内的网络环境我建议你还是对敏感数据加一下。
    一是国内很多公司的机器是装有监控类进程的,而且还加了自签根证书。
    二是的确会有很多小白用户不知道中间人攻击直接无视浏览器安全提示。
    sparrowMan
        100
    sparrowMan  
       96 天前
    没有绝对的安全 但是银行卡这种敏感信息 还是加密的好 不要依赖 https 因为放在公网上不可控的因素太多 能多安全点就安全点 前端加密+盐 后端解密 这个接口花不了多长工时的
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3411 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 62ms · UTC 13:13 · PVG 21:13 · LAX 05:13 · JFK 08:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.