我目前正在使用reactjs构建单页面应用程序.我读到很多不使用localStorage的原因是因为XSS漏洞.由于React逃脱了所有用户输入,现在使用localStorage是否安全？
我正在用支持它的浏览器(除了IE之外的任何人)用localStorage替换cookie .问题是site.com和www.site.com存储自己独立的localStorage对象.我相信www被认为是一个子域名(如果你问我,这是一个愚蠢的决定).如果用户最初在site.com上并决定输入www.site.com在下次访问时,她的所有个人数据都将无法访问.如何让所有"子域"与主域共享相同的localStorage？
首先,我假设一个后端控制输入以防止XSS漏洞.
在这个答案中 @Les Hazlewood解释了如何在客户端保护JWT.
假设所有通信都有100%TLS - 在登录期间和登录后的所有时间 - 通过基本身份验证使用用户名/密码进行身份验证并在交换中接收JWT是一个有效的用例.这几乎就是OAuth 2的一个流程('密码授权')的工作方式.[...]
您只需设置Authorization标头:
Run Code Online (Sandbox Code Playgroud)Authorization: Bearer <JWT value here>但是,话虽如此,如果您的REST客户端是"不受信任的"(例如支持JavaScript的浏览器),我甚至不会这样做:HTTP响应中可通过JavaScript访问的任何值 - 基本上任何标头值或响应正文值 - 可以通过MITM XSS攻击嗅探和截获.
最好将JWT值存储在仅安全的纯http cookie中(cookie config:setSecure(true),setHttpOnly(true)).这可以保证浏览器:
- 只通过TLS连接传输cookie,
- 永远不要将cookie值用于JavaScript代码.
这种方法几乎是您为最佳实践安全所需要做的一切.最后一件事是确保您对每个HTTP请求都有CSRF保护,以确保启动对您站点的请求的外部域无法正常运行.
最简单的方法是使用随机值(例如UUID)设置仅安全(但不是仅限http)cookie.
我不明白为什么我们需要具有随机值的cookie来确保启动对您站点的请求的外部域无法运行.使用同源策略时,这不是免费的吗？
来自OWASP:
检查Origin Header
Origin HTTP Header标准是作为防御CSRF和其他跨域攻击的方法而引入的.与引用者不同,源将出现在源自HTTPS URL的HTTP请求中.
如果存在原始标头,则应检查其是否一致.
我知道OWASP本身的一般建议是同步器令牌模式,但我看不出剩下的漏洞是什么:
更新1: 同源策略仅适用于XMLHTTPRequest,因此恶意站点可以轻松地生成表单POST请求,这将破坏我的安全性.需要显式的原始标头检查.等式将是:
对不起,也许这是许多其他人提出的问题,但我真的很困惑,因为一些参考文献有很多不同的方法.
我使用React SPA,Express,Express-session,Passport,JWT
所以我对Cookies,Session和JWT/Passport感到困惑.
许多网站使用cookie来存储购物车令牌.到目前为止,我已根据会话ID存储购物车数据,而不添加任何cookie.
因此,当用户访问我的网站时,我会将其与他们匹配
req.sessionID,然后检索数据库中的数据,如购物车和用户会话.
所以我的问题是我需要存储cookie吗？因为我可以通过req.sessionID访问它来获取所需的数据.
第二个
我使用了一个身份验证passport-google-oauth20.在我成功登录后,数据被保存到会话中.并将其发送到客户端我必须通过URL查询发送它?token='sdsaxas'.
在这种情况下,我得到了很多意见分歧.有人将其保存到本地存储中,有人通过使用JWT将其转换为令牌将其保存为cookie.
jwt.sign(
payload,
keys.jwt.secretOrPrivateKey,
{
expiresIn:keys.jwt.expiresIn // < i dont know what is this expired for cookies or localstorage ?
}, (err, token) => {
res.redirect(keys.origin.url + "?token=" + token);
});
结论是一切都与会话有关所以我可以用sessionID做所有事情？没有cookies或localstorage
只有通过执行一次或每次页面刷新并检索数据然后保存到redux,因为我使用React SPA
我有一个单页应用程序，包含敏感内容，需要保护。这个问题是专门针对 XSS 和 CSRF 攻击的。
说明：很多地方都提出了建议，例如这里在存储 auth-token 的同时在 localStorage 之上使用 cookie。此处还提供了一个很好的解释来回答另一个问题。
基于这些答案，对于安全内容，建议使用带有“httpOnly”和“secure”选项的 cookie 以避免 XSS；并由我们自己实现 CSRF 保护（类似于asp.net 中的防伪令牌）（请注意，我不是在 Asp .net 上，而是在 java 堆栈上）。
以为这些博客和对话有些陈旧，随着时间的流逝，场景有所改变。现在使用具有严格策略的Contents-Security-Policy 标头 [CSP]，可以显着降低 XSS 攻击的风险。此外，现代浏览器在很大程度上支持CSP 。考虑到 CSP 的 XSS 安全性，现在我觉得使用 localStorage 而不是 cookie 来避免 CSRF 是一个不错的选择。
问题：您认为使用“LocalStorage + CSP（无需手动实现）”有什么缺点/安全漏洞吗？
超过
Cookies [httpOnly and secure] + CSRF 防伪令牌的“手动”实现？
考虑：
除了 CSP 响应标头之外，您还可以考虑按照此处的建议仍然支持 X-XSS-Protection 标头。
您可以考虑该站点是 HTTPS，具有 HSTS、HPKP 安全标头的实现。