我正在研究哈希计算器课程。这是一个简单的Web应用程序,它在主页面上包含两个提交表单,用户可以在这些表单中提交哈希并获取文本并查看一节经文。
尽管应用程序很简单,但它需要在其中实现安全功能。我设法减轻了SQL和XSS攻击。然后,我决定使用两个漏洞评估扫描仪“Acunetix”和“Nessus”。两个扫描程序都向我显示我的应用程序容易受到CSRF的攻击,对此攻击的保护是在PHP中实现会话和随机令牌。
我已经读过这次攻击以及它的作用。但是,我很困惑,因为这次攻击主要集中在已经过身份验证的用户和cookie上,所以我的问题是?我是否需要在我的应用程序中嵌入会话和令牌,只返回并恢复哈希和明文?如果是,为什么我应该这样做以及潜在的威胁?
非常感谢!
答案 0 :(得分:2)
你的问题是对的,CSRF保护需要有意识的决定。我想你至少可以考虑在你的应用程序中这样做,这就是原因。
CSRF是关于另一个网站能够欺骗用户在访问恶意应用程序时无意中在您的应用程序中执行操作。没错,大多数时候这会利用用户已经登录的事实,但情况不一定如此。
对于您的应用程序,立即浮现的两个与CSRF相关的威胁是:
散列是非常占用CPU的,而另一方面,大型彩虹表中的搜索操作也可能是资源密集型的。这本身已经是一种拒绝服务风险,但您可以通过例如过滤掉具有太多请求的源IP来解决这个问题。但是,如果您的应用程序容易受到CSRF攻击,那么高流量网站可以让访问者在您的应用中执行此类操作,从而有效地执行分布式DoS,这更难以防范。
非常相似,如果您有应用程序的API并且没有针对CSRF的保护(例如,您有access-control-allow-origin:*),那么任何其他网站都可以运行尽可能多的查询他们想要哈希或搜索,这可能导致收入损失或分布式拒绝服务)。
也许这些不适用于您的确切用例,我只是想注意,即使没有任何类型的会话状态,CSRF确实是一个问题,并且系统地揭示这些潜在威胁的工具被称为威胁建模。
答案 1 :(得分:1)
简短的回答:不,你没有,因为你没有“用户”#39; (身份验证)您不需要csrf令牌。