XSS
请用自己的语言简述:
-
XSS 是什么(举例说明)
-
如何防治 XSS
---------
XSS 是什么?
是英文 Cross-Site Scripting 的缩写,中文名跨站脚本漏洞
简单来说
1. 正常用户 A 提交正常内容,显示在另一个用户 B 的网页上,没有问题。
2. 恶意用户 H 提交恶意内容,显示在另一个用户 B 的网页上,对 B 的网页随意篡改。
造成 XSS 有几个要点:
1. 恶意用户可以提交内容
2. 提交的内容可以显示在另一个用户的页面上
3. 这些内容未经过滤,直接运行在另一个用户的页面上
举例说明
假设我们有一个评论系统。
用户 A 提交评论「小锦你好」到服务器,然后用户 B 来访问网站,看到了 A 的评论「小锦你好」,这里没有 XSS。
恶意用户 H 提交评论「」,然后用户 B 来访问网站,这段脚本在 B 的浏览器直接执行,恶意用户 H 的脚本就可以任意操作 B 的 cookie,而 B 对此毫无察觉。有了 cookie,恶意用户 H 就可以伪造 B 的登录信息,随意访问 B 的隐私了。而 B 始终被蒙在鼓里。
XSS 的成因以及如何避免
继续上面例子,之所以恶意脚本能直接执行,有两个可能
1. 后台模板问题
<p>
评论内容:<?php echo $content; ?>
</p>
$content 的内容,没有经过任何过滤,原样输出。
要解决这个原因,只需要后台输出的时候,将可疑的符号 < 符号变成 < (HTML实体)就行。
2. 前端代码问题
$p.html(content)
或者
$p = $('<p>'+ content +'</p>')
content 内容又被原样输出了。解决办法就是不要自己拼 HTML,尽量使用 text 方法。如果一定要使用 HTML,就把可疑符号变成 HTML 实体。
示例代码
以上,就是 XSS 的简单介绍。
CSRF
CSRF是什么
中文名:跨站请求伪造。
其原理: 攻击者构造网站后台某个功能接口的请求地址,诱导用户去点击或者用特殊方法让该请求地址自动加载。用户在登录状态下这个请求被服务端接收后会被误以为是用户合法的操作。对于 GET 形式的接口地址可轻易被攻击,对于 POST 形式的接口地址也不是百分百安全,攻击者可诱导用户进入带 Form 表单可用POST方式提交参数的页面。
CSRF如何避免
-
服务端在收到路由请求时,生成一个随机数,在渲染请求页面时把随机数埋入页面(一般埋入 form 表单内,)
-
服务端设置setCookie,把该随机数作为cookie或者session种入用户浏览器
-
当用户发送 GET 或者 POST 请求时带上_csrf_token参数(对于 Form 表单直接提交即可,因为会自动把当前表单内所有的 input 提交给后台,包括_csrf_token)
-
后台在接受到请求后解析请求的cookie获取_csrf_token的值,然后和用户请求提交的_csrf_token做个比较,如果相等表示请求是合法的。
CSRF注意
- Token 保存在 Session 中。假如 Token 保存在 Cookie 中,用户浏览器开了很多页面。在一些页面 Token 被使用消耗掉后新的Token 会被重新种入,但那些老的 Tab 页面对应的 HTML 里还是老 Token。这会让用户觉得为啥几分钟前打开的页面不能正常提交?
- 尽量少用 GET。假如攻击者在我们的网站上传了一张图片,用户在加载图片的时候实际上是向攻击者的服务器发送了请求,这个请求会带有referer表示当前图片所在的页面的 url。 而如果使用 GET 方式接口的话这个 URL 就形如: xxxx.com/gift?giftId…
,那相当于攻击者就获取了_csrf_token,短时间内可以使用这个 token 来操作其他 GET 接口。
常见问题FAQ
- 免费下载或者VIP会员专享资源能否直接商用?
- 本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 提示下载完但解压或打开不了?
- 找不到素材资源介绍文章里的示例图片?
- 模板不会安装或需要功能定制以及二次开发?
发表评论
还没有评论,快来抢沙发吧!