V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  GeruzoniAnsasu  ›  全部回复第 17 页 / 共 149 页
回复总数  2961
1 ... 13  14  15  16  17  18  19  20  21  22 ... 149  
2023-10-10 22:48:43 +08:00
回复了 PatrickLe 创建的主题 问与答 小团队文件同步方案该怎么做呢?
有没有想过 svn
2023-10-05 23:03:57 +08:00
回复了 richangfan 创建的主题 问与答 星际旅行有什么意义?
@z1645444 都是用你出生时的公民 ID 做随机种子算好的,你只管赚够信用分就能换到。
2023-10-01 14:09:53 +08:00
回复了 James369 创建的主题 问与答 PhotoShop 是否支持一定的编程或脚本自动化能力?
2023-09-30 15:55:58 +08:00
回复了 n2l 创建的主题 问与答 儿童保护电蚊拍
三层网只防误触不防作死,他要伸指头进去玩照样被电

所以教育>保护

你让他看着蚊子怎么被电成烟的,拿个螺丝刀什么的放一放电噼里啪啦吓唬一下,教育他这东西很危险不能碰他自己是不会敢去玩的。

如果是还不懂事的很小的小孩,那最好的办法是收起来别让他看见。
放弃微不足道的手感问题

买那种办公用的超薄笔记本式键盘,那种玩意怎么敲都没声音
2023-09-26 13:17:00 +08:00
回复了 cheetah 创建的主题 程序员 在 HTTPS 时代对请求进行签名是否还有必要?
其实对请求签名防范的最核心问题是,你有些时候并不能保证请求内容和 token 来自同一可信源。举个底层逻辑相同但作用和机制完全不同的例子:CSRF token. 为什么明明用户都已经登录了,请求者拥有该用户的一切身份证明,为什么服务器还是不能完全信任这个请求?就因为服务器不能确定用户提供的身份证明能否证明他发起过请求内容。而通过下发 csrf token ,可以保证持有 session 凭证的所有者才能发起合法请求,这就能确认身份证明与请求内容是同一人发出的。


签名同理。
2023-09-26 13:11:07 +08:00
回复了 cheetah 创建的主题 程序员 在 HTTPS 时代对请求进行签名是否还有必要?
@musi 我通过一个*SRF 漏洞修改你的账号发言权重
2023-09-25 22:11:29 +08:00
回复了 cheetah 创建的主题 程序员 在 HTTPS 时代对请求进行签名是否还有必要?
@julyclyde 证书就是签名,双向证书==双向签名,机制稍有差异而已


----

我问个问题。

你是腾讯的服务器,现在有人请求修改 onwer A 的资源,你需不需要确认请求者就是 A ,如何保证?
2023-09-25 13:29:33 +08:00
回复了 richangfan 创建的主题 游戏 我想开发一款空气游戏,一行代码都不写
玩过,一句话,除了不好玩其它都挺好的
2023-09-24 12:12:33 +08:00
回复了 seanzxx 创建的主题 微信 自以为是的微信
我最近买的新手机号能收到银行发来的欠款通知短信,银行还打过来问我是不是 XXX (实名)


但我登录不了这个人的微信,就因为有这个好友验证。
@studyrun 链路上的同网段机器不需要经过路由器转发。所以桥接和 NAT 不应该会有区别。

我的 wsl 和宿主机就是桥接的:

https://i.imgur.com/4oIsQJq.png
2023-09-22 17:34:03 +08:00
回复了 murmur 创建的主题 程序员 一个外包同事,插入 200 条数据,调用了四万次人员查询接口
@bk201
> 人家就是混口饭吃,也是朝不保夕,被开了还没赔偿,你还能对对方有什么要求。

你知道 wuli 外包哥哥有多努力吗,你们非得看到他进监狱才开心吗
2023-09-22 02:36:15 +08:00
回复了 nowheremanx 创建的主题 程序员 科班程序员对于专业课知识掌握得怎么样?
> 曾经纠结了一两周的问题,科班程序员因为知识面的原因,一天就搞定了

想多了。

但是, 你纠结一辈子也想不出任何入门方向的问题,科班的确实能受益于知识储备结构起码找到研究方向。

之前有过这样一个帖子:
https://www.v2ex.com/t/845892#r_11550945

我描述了一点科班出身的工程师解决问题的小优势。

最近几天我又见识了几个新问题,你可以尝试思考一下这个问题你有没有思路:





我要开发一款能分析二进制程序漏洞的自动化扫描器,我需要先搜索哪些论文?
2023-09-18 15:47:11 +08:00
回复了 thisismr2 创建的主题 程序员 问: A 和 B 通过 S 中转来进行消息传递是否安全
@thisismr2 这样的描述还是有点模糊,由于细节你是没法全部表述清楚的,我也不可能很快地完整理解整个系统的结构,所以没法下确定性的判断。

但总之
1. 预设服务器不可能攻破并不十分可靠,无论是逻辑缺陷还是旁站业务还是侧信道都有可能从中提取信息,相比之下终端反而安全很多,甚至在考虑存在 0day 的情况下通常也需要 1-click 才会发生入侵
2. C 和 S 不需要共享任何信息,作为攻击者,他的做法可以分别获取想要的信息再重建关联。再说了,「 C 泄露的 K 是 S 上的某个通信密钥」这个关联已经很强了
3. TLS 只能保证链路安全,无法保证端点上的安全,除非 S 是一个单纯的流量转发器,不解析 TLS 中的内容,那么信道没有在 S 上落地,可以认为在 S 点上安全,但描述并非这么回事。
4. A 和 B 的认证 cookie 没有没有包含在信道建立的步骤中,因此没有作用,除非你的设计是登录后创建的信息与 AEAD 加密的 key 强关联,那么登录状态能同时保证消息完整且可认证,这样是可以确认消息只能由持有登录状态的人发出/解出的。


我就假设一个攻击手段好了
1. 想办法批量获取全网的 C ,记录在线时间和 K ,记录为 R
2. 在 S 上取得一组 AB 通信记录,查询对应时间区间的 R ,用 R 对应的 K 解密

如果你真的非要假设 S 绝对安全 —— 安全是基于可信的。S 安全意味着 S 可信,那么你其实不用避免 S 得知 K ,因为 S 理应拿着 K 也不会做任何事。

如果你不担保这点,就是在假设 S 存在「主动向 C 获取 K 来解密他自己正在中转的消息的行为」的可能性,这是你系统设计外的非预期行为,如果系统设计要考虑容许这个非预期也就意味着还要容许诸如「 S 中转的消息被泄露」之类的其它非预期。所以我对你「假定 S 安全」的前提持怀疑态度。
2023-09-18 11:53:18 +08:00
回复了 thisismr2 创建的主题 程序员 问: A 和 B 通过 S 中转来进行消息传递是否安全
你要从攻击者的角度来看这个问题。

K 可由 C 泄露,消息可从 S 截获,这意味着 A 到 B 并未建立起安全的点对点通信,可以通过欺骗或攻陷 C 和 S 来取得完整消息。

从进攻方视角来说,这个体系存在暴露面。(毕竟你只预设 A 和 B 的终端是可信的,S 和 C 没有包含在内)
2023-09-16 22:38:33 +08:00
回复了 a412501665 创建的主题 酷工作 爬虫工程师兼职 (远程岗位) 3K 到 5K
@Features 输入:「由于不一定从一个网站采集,所以找个兼职」
2023-09-16 13:34:44 +08:00
回复了 zzzkkk 创建的主题 C++ fsantinize 弱智
我此时很想看到那个秒杀 nginx 的哥们来点拨一下 OP
嵌入式落后业界 20 年不是瞎说的
1 ... 13  14  15  16  17  18  19  20  21  22 ... 149  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3172 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 51ms · UTC 13:57 · PVG 21:57 · LAX 05:57 · JFK 08:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.