我正在使用Angular的网站上使用基于会话的CSRF。进行HTTP呼叫以要求CSRF令牌是否安全?
例如,如果我将具有有效用户会话的请求发送到了名为/ csrf / get的页面,并且该页面打印了原始令牌,那么对于CSRF功能而言,此安全性是否足够安全?如果没有,在保持JSON检索功能的同时我还能做些什么使其更安全?
这将是所有其他事情之前的第一个api调用,我将其保留在本地存储中,以便在每个http调用中使用它
答案 0 :(得分:4)
简而言之,不。由于csrf/get
端点不受CSRF保护,因此您尝试进行CSRF保护的方式会使您接触CSRF。
本质上,您需要保护自己免受两个主要的攻击媒介:XSS和CSRF。
CSRF涉及您的站点和一个恶意站点,该站点将尝试向您的站点发出经过身份验证的请求。如果有一种方法可以从恶意站点请求CSRF令牌,则您将不受保护。 防止CSRF的常用方法是从身份验证API调用返回一个令牌,并将该令牌存储在浏览器会话中。 此方法的问题在于它使您可以使用XSS 。
跨站点脚本或XSS漏洞与页面上运行的外部脚本有关。这包括攻击者插入的潜在恶意脚本。
本地存储和会话存储并不安全,因此,例如,您不应将令牌存储在常规Cookie中。
为了免受XSS攻击的侵害,您的身份验证响应可以存储使用HttpOnly
cookie无法读取javascript的cookie。
因此,使用与javascript一起存储的令牌可以保护您免受CSRF的侵害,但您可以使用XSS;使用会话cookie可以保护您免受XSS的侵害,但是可以使您获得CSRF的保护。
解决方案是同时使用两种方法:您的身份验证API应该设置一个HttpOnly
cookie来保护免受XSS的侵害,并应返回一个令牌来保护免受CSRF的侵害。
请注意,由于认证方法应返回令牌,因此无需使用csrf/get
api:您只想发送该令牌以交换有效的凭证。请记住,还要在所有经过身份验证的API调用上发送并验证同一令牌。
这是一篇很棒的文章,解释了API安全性,以及为什么和如何做得更加详细: http://www.redotheweb.com/2015/11/09/api-security.html
答案 1 :(得分:1)
首先,使用https,http不安全。
然后,最好不要使用GET。
安全的方法是在成功的身份验证请求(POST)响应中发送令牌。
有关更多信息,请检查:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet