V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  onice  ›  全部回复第 3 页 / 共 59 页
回复总数  1169
1  2  3  4  5  6  7  8  9  10 ... 59  
319 天前
回复了 lynan 创建的主题 分享发现 来说说你们认为信达雅的翻译吧
no alive slave --> 没有活着的奴隶
即使是你用 electron 开发,但大多数普通用户根本不会知道你用什么开发。

大多数时候,GUI 并不会要求性能。所以,我个人来说是支持 electron 的。
可能是被挖矿了。试试: https://www.eset.com/cn/for-home/online-scanner/
325 天前
回复了 balabalaguguji 创建的主题 程序员 这种攻击如何防御?
这种攻击叫 CC 攻击,上 waf 就行了。

https://www.safedog.cn/website_safedog.html
328 天前
回复了 onice 创建的主题 程序员 写了一些关于打工,中年危机等问题的看法
@IxIIxI 方向就是以技术作为切入点,往管理转。参考这篇博文: http://dearlance.cn/2023/02/19/caac5be8f734/
cpu 是 amd 的吗?是不是开了 tpm 呢?

这两个东西都会倒是卡顿。

参阅: https://post.smzdm.com/p/a7d7lxd9/?sort_tab=hot/
17 年成都,实习 1.8K 。转正 4.5K 。
我搭了个 rustdesk
@SaltyMouse 换任何一个拓展坞都是这样子,联想的也是这样。之前问过客服,说是 bios 的 bug 。就是如果插拓展坞开机,bios 不识别拓展坞。
拔掉拓展坞开机,进入桌面后再插拓展坞就好了。

适配器接拓展坞,拓展坞再接笔记本电源接口,最好别这么做。拓展坞没有过载保护,我电脑和你同型号,,这几天刚换了主板。

售后说是适配器坏了,导致主板损坏。如果是适配器接电脑,由于适配器有过载保护,是不会损坏主板的。但由于接拓展坞了,拓展坞没过载保护,所以主板损坏了。
348 天前
回复了 yaott2020 创建的主题 Linux 你倾向于哪个 Linux 桌面发行版?
Either ubuntu or linux mint.
@Forviler 攻击者也是我们的用户之一,,只不过是不怀好意的用户。所以,我们可以把攻击者看成是正常用户。那么,用户输入的数据,我们肯定不能破坏。例如用户输入 abc ,我们不能为了安全把数据改成 bcd 。所以,实体编码是个好办法。用户输入的数据,关键点在于攻击者输入的数据包含恶意代码,所以用实体编码我们既能让用户输入的数据原样显示在浏览器中,又能让即使是包含了恶意代码的数据不被浏览器解析。

那么我使用富文本的时候是必须要将数据当作代码来进行解析的,所以是不能进行实体编码的操作的么,因为浏览器会把它当作文本来显示。

至于富文本,你说得对,的确是这样子。富文本的业务场景下,我们必须要让浏览器解析用户输入的数据。所以实体编码后,富文本的输入数据不被解析,代码就会原封不动的显示在浏览器中。用户的格式设置就会失效,例如文本背景,字体加粗,图片等。

富文本的场景下宜采用白名单的方式。只允许用户输入特定的 HTML 标签,对用户的输入的数据要严格限制。
@Forviler
针对你当前的场景:

document.getElementById('rf').innerHTML= `<img/src=1 >` ; edge 下会显示为文本
document.getElementById('rd').innerHTML = `<img/src=1 >`; edge 下显示为 标签

假如攻击者的代码为:<img/src=1 >,,你在代码中转为&lt;img/src=1 &gt;后,这就是消毒的操作。浏览器页面中会显示<img/src=1 >,但其实浏览器把显示的<img/src=1 >当成&lt;img/src=1 &gt;处理。这么一来,浏览器就不会真的把这串代码当成 img 标签进行渲染了。这样既能够不破坏用户输入的数据,又能够保障代码的安全(不被解析成 js 代码)。

document.getElementById('rd').innerHTML = `<img/src=1 >`; edge 下显示为 标签
这个就是危险的。假如攻击者的攻击代码为:<img/src=1 onerror="alert(xss)">,,由于没有进行编码,这个代码会被当成 js 处理,,浏览器会加载图片,但由于 url 不存在,图片加载失败,触发 onerror 事件,执行 alert 弹窗代码。当然这里仅仅是测试,alert 并不具备危害。但是如果 alert 是窃取 cookie 的代码,这可就危险了。
@Forviler
@onice

再补充下另一本书:web 安全深度剖析,,这本书篇幅短一些。条例比白帽子讲 web 安全清晰一些。建议优先看这本。

只看 XSS 章节即可。

链接: https://pan.baidu.com/s/16s19_V5p3V-bMjsLtZLZMg?pwd=mhxz
提取码:mhxz
@Forviler 是这样子。XSS 的本质,是浏览器解析了攻击者插入到页面中的 JS 代码,,而这些代码恰好是恶意的,例如窃取用户 cookie 。

通过实体编码,我们就可以让攻击者插入的 js 代码原样显示在浏览器中,浏览器会显示尖括号,但并不会解析这些 js 代码。当然,浏览器中显示的是尖括号,但在代码层面,已经被处理为&lt;之类的编码了。

对于大部分前端框架,例如 Vue 和 React ,默认就对 xss 进行防护了。当然, 除非你使用 v-html ,而通过 v-html 渲染的值,用户可以控制。

对于 Java 后端来说,,防御 XSS 的方法也很简单,加一个过滤器即可。把从前端传过来的所有数据,进行判断,如果发现尖括号等敏感的字符,就进行编码,例如转为:&lt;

转换后的数据就是安全的了,转换后方可入库。

XSS 漏洞主要是危害用户的安全,XSS 往往导致用户的登录凭证被窃取,并不危害网站服务器。

大多数时候,XSS 都被划分为低危漏洞。

我上面说得可能也不是很详细,要不你参考下白帽子讲 web 安全,第三章 XSS 的部分。

XSS 漏洞很容易理解,是属于 web 漏洞中比较简单的。

书籍链接为:

链接: https://pan.baidu.com/s/1cmMkJH2_9I16A9DODUt5tg?pwd=xwld
提取码:xwld
防御 xss 最正确的方法是实体编码,而不是黑白名单过滤。
请参阅: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
1  2  3  4  5  6  7  8  9  10 ... 59  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1098 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 18:48 · PVG 02:48 · LAX 10:48 · JFK 13:48
Developed with CodeLauncher
♥ Do have faith in what you're doing.