首页
学习
活动
专区
圈层
工具
发布

nginx cookie有效期讨论

修改cookie有效期 通常情况下,我们的web应用服务都会通过nginx进行发布,这个时候,我们可以通过在nginx上面进行配置文件的修改来改变cookie的有效期,由于笔者最近在基于openresty...正好趁此机会展开对Cookie有效期的状态测试. 上文在Cookie的生命周期中提到为了有效期的安全性,我们可以为Cookie设置合理的有效期。如为0或者负值,那么其效果是怎样的呢?...有效期为创世纪 这里将expires设置为有效期是-1,这里可以观察到cookie使用的时间的是1970年,也就是UNIX纪元的元时间 local cookie = resty_cookie:new...是要被关进小黑屋探讨人生价值的,用户遇到这样的Cookie配置是无论如何都无法登陆成功的 [有效期为元时间] 有效期为当前 因为ngx.cookie_time会返回一个格式化的字符串,可以用作Cookie...Cookie只在当前页面上有效,一旦关闭浏览器,这个Cookie就会被浏览器清除,此时不用再考虑安全性问题。

2.1K00
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    CSRF 不是漏洞,是浏览器的特性——从 Cookie 自动提交说起的安全困局

    这就是 CSRF 的本质:不是服务器的认证有问题,也不是用户密码被破解,而是浏览器在跨域请求中自动提交 Cookie 这个"特性",被恶意利用了。 为什么说 CSRF 不是漏洞,是"特性"?...它的逻辑是: 我在 Cookie 里放一个随机值,同时也要求你在请求体或请求头里带上同一个值。如果两者都对上了,说明这个请求来自真正的用户。 为什么这样也能行?...这是怎么实现的: app.get("/login-success", (req, res) => { const csrfToken = generateCSRFToken(); // 在 Cookie...里存一份 Token res.cookie("csrfToken", csrfToken, { httpOnly: false, // 注意:必须允许 JS 读取 sameSite...这就是为什么我说 CSRF 是个"困局"。

    34510

    python接口自动化12-案例分析(csrfToken)

    前言: 有些网站的登录方式跟前面讲的博客园和token登录会不一样,把csrfToken放到cookie里,登录前后cookie是没有任何变化的,这种情况下如何绕过前端的验证码登录呢?...3.抓包后cookies信息在登录前后没任何变化,这里主要有三个参数: --businessUsername:这个是账号名称 --JSESSIONID: 这个是一串字符串,主要看这个会不会变(一般有有效期...)copy出来就行 --csrfToken: 这个是一串字符串,主要看这个会不会变(一般有有效期)copy出来就行 二、get请求 1.像这种登录方式的get请求,请求头部cookie没任何变化,这种可以直接忽略登录...三、post请求遇到的坑 1.post请求其实也可以忽略登录的过程,直接抓包把cookie里的三个参数(businessUsername、JSESSIONID、csrfToken)加到头部也是可以的。...丢失,所以回到登录页面了 # 解决办法,禁止重定向,获取重定向的url后,重新发重定向的url地址请求就行了 # 三个主要参数 csrfToken = '获取到的csrftoken,一般有有效期的'

    1.3K71

    koa2实现网站csrf防御

    先说常见的登陆鉴权: 用户在你的网站登陆后,一般把登陆凭证(token)存储在cookie里,之后每次调接口都会自动携带,后端根据这条cookie鉴权,判定是登陆状态,进而允许进行安全操作。...防御csrf攻击 思路: 由于csrf攻击者只能拿到cookie去干坏事,但它无法知道cookie里有什么,也拿不到其他有效信息。我们只需要除cookie外再加一道它做不到的验证就可以了。...前端首次加载页面的时候,调接口让后端植入一条csrfToken到cookie里。然后前端每次请求从cookie里取出然后放到请求头里给后端传输。...后端将植入给前端的csrfToken存储在session,然后一些安全接口(一般是除了get请求外的接口),请求时,需要先进行csrf比对,取出request请求头里的csrfToken和自己session...里的csrfToken进行比对,完全一致才放行 代码实现 前端(react) 1//App.tsx 2//根组件,判断cookie里有没有csrfToken,没有就请求后端种植 3 useEffect

    1.6K20

    【SpringSecurity新手村系列】(3)自定义登录页与表单认证

    (2)为什么需要它CSRF(跨站请求伪造)的典型攻击方式是:用户已在你的站点登录(浏览器里有有效会话Cookie)用户访问了攻击者网站攻击者网站偷偷向你的站点发起一个“状态变更请求”(比如转账、改密码、...发帖)因为浏览器会自动带上Cookie,后端如果只认Cookie,就可能误以为这是用户本人操作。...SpringSecurity的做法是:除了Cookie,再要求请求里必须带一个后端签发的随机token。攻击者站点拿不到这个token,所以伪造请求通常会失败。...(4)为什么GET一般不需要带SpringSecurity默认认为GET/HEAD/OPTIONS/TRACE是“只读”请求,不会修改服务端状态,所以不强制CSRFtoken。...如果是前后端分离(SPA),通常会:后端把CSRFtoken放在响应头或Cookie前端在后续AJAX请求头里回传(如X-CSRF-TOKEN)(6)如果你去掉这行会怎样登录表单使用POST提交时,CsrfFilter

    37210

    011_Web安全攻防实战:CSRF攻击原理、绕过技术与多层防御策略深度指南

    登录网站A → 获得Cookie → 访问恶意网站B → 恶意网站B → 构造请求 → 自动携带Cookie → 发送到网站A → 网站A服务器 → 验证Cookie有效 → 执行恶意操作 2.2 CSRF...获得有效的会话Cookie T3 攻击者 发送钓鱼链接 诱导用户点击 T4 用户 访问恶意网站 浏览器自动提交表单 T5 银行服务器 接收转账请求 验证Cookie有效 T6 银行服务器 执行转账操作...双重提交防护:同时在Cookie和请求参数中提交Token,增加安全性 5.2 SameSite Cookie属性 SameSite是Cookie的一个安全属性,可以有效防御CSRF攻击。...为什么选择这个设置?你认为对于不同类型的网站,SameSite策略应该如何选择?...绕过技术 尽管SameSite Cookie属性提供了有效的CSRF防御,但在某些情况下仍可能被绕过。

    1.5K11

    【玩转全栈】—— Django 连接 vue3 保姆级教程,前后端分离式项目2025年4月最新!!!

    由于请求是从你的浏览器发出的,同时包含有效的会话Cookie,银行服务器无法区分这个请求是合法的还是伪造的,从而可能导致资金被非法转移。...具体工作流程如下: 生成Token:当用户访问一个包含表单的页面时,Django会在响应中设置一个名为csrftoken的Cookie,并且在HTML表单中插入一个隐藏字段,其值为相同的CSRF Token...安全性保障:这种方法有效地阻止了第三方网站直接构造请求并利用已登录用户的会话信息执行未授权操作的可能性,因为它们无法获取到正确的CSRF Token。...问题 Django 默认启用了 CSRF 保护机制,要求所有非安全 HTTP 方法(如 POST、PUT、DELETE)必须包含有效的 CSRF Token。...CSRF cookie not set.

    2.8K10

    让我们来深入了解下 CSRF

    使用者能做的其实有限,合理有效的防御手段还是后端那边! 后端的防御 CSRF 之所以可怕是因为 CS 两个字:Cross Site,你可以在任何一个网站底下发动攻击。...这个 csrftoken 由后端生成,并且一段时间的 session 就应该要更换一次。 那这个为什么可以防御呢?...但不同的点在于,除了不用把这个值写在 session 以外,还需要让前端设置一个名叫 csrftoken 的 cookie,值就是生成的 token。...当使用者按下 submit 的时候,后端会比对 cookie 内的 csrftoken 与 form 里面的 csrftoken,检查是否有值并且相等,就知道是不是使用者发的了。 为什么呢?...所以他发来的请求的 cookie 里面就没有 csrftoken,就会被挡下来。

    71610
    领券