通过使用晦涩的域名来确保网站安全



一位非技术性的、对安全偏执的员工坚持认为,保护我们网站的有效方法是将应用程序分为三个部分:前端、API 和员工的后端管理区域。

API 和管理系统都位于只是一组随机字符的域名上。

该应用程序保存敏感数据,但是,所有应用程序都在同一台服务器上。

我面临的问题是,在应用程序处于这种状态时调试或添加功能会使工作变得非常困难,因为不清楚应用程序的哪个部分做什么。(没有文档,以前的开发人员已经离开了公司。

他坚持认为未来的项目遵循相同的套件,具有自己独立的API和管理区域,我认为这对于相对简单的应用程序来说是不必要的。

第二个问题是,我知道通过默默无闻的安全性不一定是安全性,而且我认为使用一个复杂的域来托管部分或全部网站没有意义。

所以我的问题是这样的:

1) 使用这样的 API 会带来任何安全优势吗?是否有其他方法可以确保应用程序及其数据的安全,从而不会影响开发速度。

2) 是否有必要使用模糊的域来确保应用程序的安全?同样,是否有其他方法同样有效,对未来的开发人员来说不会那么奇怪?

3)管理系统使用用户名和密码进行保护。拥有管理系统是否同样安全 website.com/admin 而不是 randomcharacters.com?

  1. 使用这样的 API 会带来任何安全优势吗?是否有其他方法可以确保应用程序及其数据的安全,从而不会影响开发速度。

API 应由身份验证机制(如 OAuth 访问令牌 (AuthN))保护。然后,谁可以在该 API 上执行操作应由访问令牌 (AuthZ) 中的声明确定。身份验证和授权应该在这些术语中考虑。

"我是校长,我可以证明这一点,因为我有你发给我的令牌,你可以验证只有你能发的。我有很多信息,你可以用它来决定我被允许做什么。

  1. 是否有必要使用模糊的域来保证应用程序的安全?同样,是否有其他方法同样有效,对未来的开发人员来说不会那么奇怪?

不,使用晦涩的域名不会提供任何级别的安全性。它们只是通过 DNS 条目转换为 IP 地址的字母 - 要使用 my-website-address.com 或 hdsfiuycxzuyecgfr.com,您必须将其传达给某人,此时它们同样安全!

  1. 管理系统使用用户名和密码进行保护。拥有管理系统是否同样安全 website.com/admin 而不是 randomcharacters.com?

要问的问题是,谁是系统不同部分的用户,谁应该有权访问什么?前端应用程序是否在互联网上公开可见,是否可以被各种客户端使用?管理体系是否属于同一类别,或者这更像是一种内部工具?确定组件的用例,并考虑是否通过应用程序逻辑(如 OAuth 令牌)或基础结构限制(例如,只有特定 IP 地址范围/子网内的计算机才能访问管理工具)来保护它们。它通常是应用程序和基础结构安全性的组合,可提供最佳级别的保护。

将前端应用程序和管理工具托管为不同的应用程序可能允许您在它们周围应用不同的安全边界,这可能很有用。

但是,这是一个确定您的威胁参与者是谁并相应地进行设计的问题。

一个晦涩难懂的域名只需要在某个地方泄漏一次; 一旦任何攻击者得到域名的风声,它就不再是默默无闻的,也不会提供任何好处。如果你有一个公共网站对"模糊"的后端进行API调用,那么这个域名已经被很好地宣传了。

不,为了安全起见,使用一个晦涩难懂的名字几乎没有意义。如果您的 API 不安全并允许未经授权的访问,那就是您的安全弱点;而不是域名可能已知的事实。

最新更新