一个网站,不管多么的帅气,多么的风骚,如果你不安全,那始终都是一个弟弟啊~
今天又看了下XSS和CSRF攻击的文章,我也想发点什么普及下大家的安全意识,毕竟作为一名拥有伟大梦想的程序员,基本的安全意识还是一定要有的,话不多说,跑起来~
本文参考的文章地址:https://juejin.im/post/59dc2b7a6fb9a0451869ae3a
一、XSS攻击跨站脚本攻击(Cross Site Scripting),一般是在输入的时候,攻击者输入脚本,来进行攻击。
案例:
一个正常的输入表单控件输入 :
这只是一个最善良的恶作剧而已,试想一下,攻击者输入一些盗取COOKIE的脚本或者一些别的恶意脚本,是不是很随意的就可以去拿一些东西,想干什么我就干什么
预防方法:
1. 在COOKIE中设置httpOnly属性后,js将无法读取到COOKIE信息,可以防止XSS攻击盗取COOKIE// koa
ctx.COOKIEs.set(name, value, {httpOnly: true // 默认为 true})
2. 使用HtmlEncode,将一些标签转义
例如将<&#xff0c;>转换成<&#xff0c;>的写法来表示&#xff0c;那么输入的标签就会被解析成
3. JavascriptEncode&#xff0c;给一些字符加上反斜杠例如将\转换成\\&#xff0c;将\n转换成\\n&#xff0c;将"转换成\"
二、CSRF&#xff1a;跨站点请求伪造&#xff08;Cross-Site Request Forgeries&#xff09;&#xff0c;也就是冒充用户请求&#xff0c;用户并不知情&#xff0c;然后搞一些事情
话不多说&#xff0c;先放一张偷来的图
案例&#xff1a;
比如某网站的转账操作受害者张三给李四转账100&#xff0c;通过对银行的网站发起请求 bank.example/transfer?ac… &#xff0c;通常情况下&#xff0c;该请求发出后&#xff0c;服务器端会检查 session 是否合法&#xff0c;并且张三已经登录成功&#xff0c;黑客王五可以自己给银行发送一个请求 bank.example/transfer?ac… &#xff0c;但是这个请求来自王五&#xff0c;而不是张三&#xff0c;他并不能通过安全认证。他需要张三的 session 。王五自己做了一个网站&#xff0c;放入如下代码 bank.example/transfer?ac… &#xff0c;用各种方式诱使张三点击自己的网站。张三登录了银行的网站没有退出&#xff0c;访问了黑客王五的网站&#xff0c;上述的 url 就会向银行发起请求。如果session没有过期&#xff0c;这时悲剧就发生了&#xff0c;张三的账户里少了1000。
预防方法&#xff1a;
1. 验证码的方式&#xff0c;也就是让用户和网站进行交互才能完成一些动作(请求)缺点&#xff1a;用户体验差2. 相对get请求来说&#xff0c;尽量使用post请求(post请求也只是相对安全一点)3. token验证第一步&#xff1a;后端随机产生一个 token&#xff0c;把这个token 保存到 session 状态中&#xff1b;同时后端把这个token 交给前端页面&#xff1b;
第二步&#xff1a;前端页面提交请求时&#xff0c;把 token 加入到请求数据或者头信息中&#xff0c;一起传给后端&#xff1b;
后端验证前端传来的 token 与 session 是否一致&#xff0c;一致则合法&#xff0c;否则是非法请求。
写在最后
XSS 是内容没有做过滤处理&#xff0c;导致浏览器将攻击者的输入当代码直接运行了。CSRF 则是因为浏览器在发送 HTTP 请求的时候会自动携带 COOKIE&#xff0c;而一般网站的 session 都存在 COOKIE里面
写在最最后
若不是你突然闯进我生活&#xff0c;我怎会把死守的寂寞放任了~
因为最近有在抖音听绿色这首歌&#xff0c;所以这次就用绿色包围着你们好了。。。。。。。。。