【问题标题】:Should I be using a CSRF if I'm planning on implementing a multi-app API?如果我打算实现多应用 API,我应该使用 CSRF 吗?
【发布时间】:2023-03-09 04:36:01
【问题描述】:

我正在创建一个 Laravel API/AngularJS Monster。将它们完全分离(前端、数据库、API)的想法主要是因为我想进入应用程序开发并将所有事物分开,以便 API 可以完成所有繁重的工作。所以在未来我打算制作我将是唯一使用的界面,包括 OS X/iOS/Native 应用程序。

但是,我在网上查找内容并遵循一些设置和教程,我发现 CSRF 是一个好实施、似乎安全且正确的事情......

但它一定适合 API 吗?

哪些安全措施有利于使用 API?

我现在唯一真正了解的是会话 cookie 和在我的应用程序中使用 HTTPS。

【问题讨论】:

  • 我个人不会伪造自己的站点跨站请求...一般不建议攻击自己。
  • 谁在调用您的 API?他们如何进行身份验证?您使用会话 cookie 吗?
  • 我认为这条路线的唯一原因是因为我想使用相同的信息在许多不同的平台上创建接口。这个问题有更好的解决方案吗?
  • 现在身份验证是通过 Laravel 的标准身份验证模型完成的,而不是基本身份验证。我根本没有设置会话 cookie。
  • @PWKad 对于联系位于 su 域上的 API 服务器,您最推荐什么?

标签: angularjs laravel csrf laravel-routing csrf-protection


【解决方案1】:

如果 API 是在客户端访问的,那么是的,您需要 CSRF 保护。

这假定从前端使用 cookie(或其他身份验证机制),从 JavaScript 传递到您的 API,然后启动操作或返回内容。

对于启动动作的项目(即non safe methods - RFC 7231),您将需要发送某种形式的 CSRF 令牌(例如,推荐的 Synchronizer Token PatternDouble Submit Cookies),尽管还有其他有效的方法可以防止 CSRF,例如检查X-Requested-WithOrigin 标头。

无论您选择哪种方法,您都可以在您的应用中实现此身份验证。从自定义应用程序中检索令牌或 cookie 值很简单,或者传递额外的标头也很容易。使这种 CSRF 保护对您的网站起作用的原因在于,浏览器将限制哪些其他域可以读取令牌或发送标头,因为 Same Origin Policy。如果您的 API 在不同的域中,CORS 可用于仅允许从您的网站域进行访问,尽管听起来您已经过了这个阶段。请记住也要使用 HTTPS 保护您的 API,并在任何 cookie 上设置Secure flag,您还应该考虑使用HSTS 来进一步保护您的 API 和网站。

【讨论】:

  • 这对我来说绝对是很多东西,谢谢! “如果 API 被客户端访问”到底是什么意思?措辞并没有让我感到困惑,但是前端完全是带有 Angular 的 javascript,并且没有 PHP 来执行简单的 csrf_token() 方法。似乎没有其他方法可以访问同一会话的令牌。
  • @ShawnStrickland:我说的是一般情况下,以防其他人在谷歌上搜索并找到您的问题 - 对于您的情况,答案是肯定的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-05-08
  • 1970-01-01
  • 2016-07-02
  • 1970-01-01
相关资源
最近更新 更多