企业官网建设流程全解析

中山网站推广词,整站优化的公司,泸西县住房和城乡建设局网站,泉州网站建设的步骤一、前言 之前面试经常被问到 CSRF#xff0c; 跨站请求伪造大概流程比较简单#xff0c; 大概就是用户登录了A页面#xff0c;存下来登录凭证#xff08;cookie#xff09;#xff0c; 攻击者有诱导受害者打开了B页面#xff0c; B页面中正好像A发送了一个跨域请求 跨站请求伪造大概流程比较简单 大概就是用户登录了A页面存下来登录凭证cookie 攻击者有诱导受害者打开了B页面 B页面中正好像A发送了一个跨域请求并把cookie进行了携带 欺骗浏览器以为是用户的行为进而达到执行危险行为的目的完成攻击上面就是面试时我们通常的回答 但是到底是不是真是这样呢? 难道这么容易伪造吗于是我就打算试一下能不能实现二、实现接下来我们就通过node起两个服务 A服务端口3000和B服务端口4000 然后通过两个页面 A页面、和B页面模拟一下CSRF。我们先约定一下 B页面是正常的页面 起一个 4000 的服务 然后 A页面为伪造者的网站 服务为3000先看B页面的代码, B页面有一个登录和一个获取数据的按钮 模拟正常网站需要登录后才可以获取数据bodydiv正常 页面Bbutton onclicklogin()登录/buttonbutton onclickgetList()拿数据/buttonulclassbox/uldivclasstip/div/div/bodyscriptasyncfunctionlogin(){constresponseawaitfetch(http://localhost:4000/login,{method:POST,});constresawaitresponse.json();console.log(res,writeCookie);if(res.datasuccess){document.querySelector(.tip).innerHTML登录成功 可以拿数据;}}asyncfunctiongetList(){constresponseawaitfetch(http://localhost:4000/list,{method:GET,});if(response.status500){document.querySelector(.tip).innerHTMLcookie失效请先登录;document.querySelector(.box).innerHTML;}else{document.querySelector(.tip).innerHTML;constdataawaitresponse.json();lethtml;data.map((el){htmldiv${el.id}-${el.name}/div;});document.querySelector(.box).innerHTMLhtml;}}/script在看B页面的服务端代码如下constexpressrequire(express);constappexpress();app.use(express.json());// jsonapp.use(express.urlencoded({extends:true}));// x-www-form-urlencodedapp.use((req,res,next){res.header(Access-Control-Allow-Origin,*);// 允许客户端跨域传递的请求头res.header(Access-Control-Allow-Headers,Content-Type);next();});app.use(express.static(public));app.get(/list,(req,res){constcookiereq.headers.cookie;if(cookie!userallow){res.sendStatus(500);}else{res.json([{id:1,name:zhangsan},{id:2,name:lisi},]);}});app.post(/login,(req,res){res.cookie(user,allow,{expires:newDate(Date.now()86400*1000),});res.send({data:success});});app.post(/delete,(req,res){constcookiereq.headers.cookie;if(req.headers.referer!req.headers.host){console.log(should ban!);}if(cookie!userallow){res.sendStatus(500);}else{res.json({data:delete success,});}});app.listen(4000,(){console.log(sever 4000);});B 服务有三个接口 登录、获取列表、删除。再触发登录接口的时候会像浏览器写入cookie 再删除或者获取列表的时候都先检测有没有将指定的cookie传回如果有就认为有权限然后我们打开http://localhost:4000/B.html先看看B页面功能是否都正常我们看到此时 B 页面功能和接口都是正常的 cookie 也正常进行了设置每次获取数据的时候都是会携带cookie到服务端校验的那么接下来我们就通过A页面起一个3000端口的服务来模拟一下跨域情况下能否完成获取 B服务器数据调用 B 服务器删除接口的功能A页面代码bodydiv伪造者页面Aform actionhttp://localhost:4000/deletemethodPOSTinput typehiddennameaccountvaluexiaoming//formscript// 这行可以放到控制台执行便于观察效果// document.forms[0].submit();/script/divulclassbox/uldivclasstip/div/bodyA页面服务端代码bodydiv伪造者页面Aform actionhttp://localhost:4000/deletemethodPOSTinput typehiddennameaccountvaluexiaoming//formscript// 这行可以放到控制台输入// document.forms[0].submit();/scriptscript srchttp://localhost:4000/list/script/div/body于是在我们 访问http://localhost:3000/A.html页面的时候发现 发现list列表确实请求到了 控制台输入document.forms[0].submit()时发现确实删除也发送成功了 是不是说明csrf就成功了呢 但是其实还不是 关键的一点是 我们在B页面设置cookie的时候 domain设置的是localhost那么其实在A页面 发送请求的时候cookie是共享的状态 真实情况下肯定不会是这样 那么为了模拟真实情况 我们把http://localhost:3000/A.html改为http://127.0.0.1:3000/A.html, 这时发现以及无法访问了 那么这是怎么回事呢 说好的cookie 会在获取过登录凭证下 再次访问时可以携带呢。于是想了半天也没有想明白 难道是浏览器限制严格进行了限制 限制规避了这个问题难道我们背的面试题是错误的有知道的小伙伴欢迎下方讨论三、 sameSite 设置其实上面的问题无法实现 CSRF 是由于 SameSite 的设置问题 其实关键是要设置SameSiteNone简单看一下下面三个设置的区分None: 通常用于处理第三方提供的资源或服务白话就是不受域的限制不同域间可以传递身份验证凭证可以做单点登录 但是要配合Secure标志 即实用 HTTPS 协议Strict: 严格模式完全禁止只有自己网站的请求发送cookieLax浏览器的默认值 用户从外部导航到你的网站时可以发送cookie接下来我们就把上面的 B 服务进行改造 再设置cookie的时候 同时设置 sameSite 和 Secureapp.post(/login,(req, res){res.cookie(user,allow,{expires: new Date(Date.now()86400*1000), sameSite:none, secure: true,});res.send({data:success});});然后再次打开http://127.0.0.1:3000/A.html会发现 cookie 正常设置到了浏览器我们再次在控制台 输入document.forms[0].submit()发现删除操作也正常执行了如图我们就完成了 CSRF 攻击四、总结CSRF —— 跨域请求伪造 顾名思义攻击是发生在第三方页面 利用了浏览器在跨域的情况下在一些跨域的请求时如 script 、 img、 form 表单提交、 a标签等可以携带cookie的特性 使得一些伪造的构建请求可以执行成功 进而对正常网页造成危害的行为。我们通过代码也能看出来 其实现代浏览器对跨域cookie的限制比较多了 但是在一些情况下依然可以发生 比如设置sameSite: None时虽然会增加安全风险 但是 samesite为 None 又有一些场景需要跨域下可以共享cookie比如单点登录、内嵌广告、资源时 所以无法完全禁止 由此我们就可以总结一些避免CSRF攻击的手段了使用同源策略 限制不同来源直接资源共享检查 Refer 头部 设置白名单并不保险比如 a标签可以设置 rel“noreferrer” 绕开refer检查使用 CSRF Token 每个用户会话设置一个不可预测 唯一的 token每次请求校验尽量使用 POST 和 其他安全的HTTP方法 不在 GET 请求中实现数据写入操作敏感操作增加验证码二次验证服务端把 Cookie 的SameSite 属性设置为 Lax表单提交增加 csrfToken 隐藏字段额外由于CSRF攻击原理是浏览器自动携带 Cookie 如果放开跨站Cookie有CSRF 风险但是不放开又无法做单点登录 所以对于SPA应用来说 JWT 认证的方式更好一些token 会在Authorization头部进行传递网络安全学习资源分享:给大家分享一份全套的网络安全学习资料给那些想学习 网络安全的小伙伴们一点帮助对于从来没有接触过网络安全的同学我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线大家跟着这个大的方向学习准没问题。因篇幅有限仅展示部分资料朋友们如果有需要全套《网络安全入门进阶学习资源包》请看下方扫描即可前往获取