小编use*_*973的帖子

我的团队交出了一些生成随机令牌的服务器端代码(用Java),我对此有一个问题 -

这些令牌的目的是相当敏感的 - 用于会话ID,密码重置链接等.所以他们确实需要加密随机,以避免有人猜测它们或蛮力强制它们.令牌是"长",所以它是64位长.

代码当前使用java.util.Random该类来生成这些令牌.文档([ http://docs.oracle.com/javase/7/docs/api/java/util/Random.html] [1 ])java.util.Random清楚地说明了以下内容:

java.util.Random的实例不具有加密安全性.相反,请考虑使用SecureRandom来获取加密安全的伪随机数生成器,以供安全敏感应用程序使用.

但是,代码当前使用的方式java.util.Random是 - 它实例化java.security.SecureRandom类,然后使用该SecureRandom.nextLong()方法获取用于实例化java.util.Random类的种子.然后它使用java.util.Random.nextLong()方法生成令牌.

所以我现在的问题 - 鉴于java.util.Random正在使用种子,它仍然是不安全的java.security.SecureRandom吗？我是否需要修改代码以便它java.security.SecureRandom专门用于生成令牌？

目前代码种子是Random启动时的一次

我们有一台运行Linux的设备,我们需要在此上运行不受信任的应用程序.我们正在努力减轻以下安全问题 -

1. 不受信任的应用程序不应该对核心OS数据和二进制文件产生负面影响
2. 不受信任的应用程序不应该对另一个应用程序的数据和二进制文件产生负面影响
3. 不受信任的应用程序不应该消耗过多的CPU,内存或磁盘,并导致DoS /资源不足,如核心操作系统或其他应用程序

从不受信任的应用程序角度来看,它只需要能够读取和写入自己的目录,也可能是已安装的USB驱动器

我们正在考虑使用以下方法之一 -

方法1 - 使用SELinux作为沙箱

• 这可能吗？我已经阅读了一些SELinux,它在设置策略文件和在运行时强制执行等方面看起来有点复杂.SELinux可以这样做并限制不受信任的应用程序只读/写自己的目录,也能够设定配额限制？

方法2 - 自己创建一个新的沙箱

• 在安装期间

  • 为每个不受信任的应用程序创建新的应用程序用户
  • 使用权限标记整个应用程序目录和文件,以便只有应用程序用户可以读写
  • 使用ulimit/quota为应用程序用户设置配额

• 在运行时,使用启动不受信任的应用程序

  • 关闭所有打开的文件描述符/句柄
  • 使用chroot将root设置为应用程序目录
  • 在应用程序用户的上下文中启动应用程序

关于上述的想法？哪种方法比另一种更安全？还有其他方法可能更好吗？由于某些原因,我们无法选择移动Android,因此我们无法使用Android本身提供的沙盒功能...

让我知道

谢谢,

我试图找出Firefox存储sessionStorage内容的位置,但一直无法找到.我希望它存在于SqLite数据库中,就像存储了localStorage内容,但我一直无法找到它.

到目前为止,我已经搜索了配置文件夹中的所有典型的".sqlite"文件,例如cookies.sqlite和content-prefs.sqlite等,但它们似乎没有sessionStorage数据.

我还尝试打开Firefox据称创建的特殊内存数据库 - https://developer.mozilla.org/en/XPCOM_Interface_Reference/mozIStorageService#openSpecialDatabase%28%29但我找不到枚举表中存在的表的方法数据库.我可以连接到内存数据库,但我不知道如何找出内存数据库中存在的表等...

任何帮助表示赞赏

谢谢,

我需要在iOS和Android本机应用程序中集成OAuth2.我一直在研究OAuth2和移动应用程序,并发现了这个文档 - Google API - 使用OAuth 2.0来安装应用程序

上述文档基本上详细介绍了如何在移动应用程序中使用Goolge OAuth 2.0端点.

这是文件所说的 -

1. 注册应用程序时,指定应用程序是已安装的应用程序.这会导致redirect_uri参数的值不同.
2. 注册期间获得的client_id和client_secret嵌入在应用程序的源代码中.在这种情况下,client_secret显然不被视为秘密.
3. 授权代码可以在浏览器的标题栏中返回到您的应用程序,也可以返回到http://localhost查询字符串中的端口.

假设用户的智能手机上安装了2个应用程序.

App1 - 使用Google OAuth2.0端点的合法应用

App2 - 恶意应用

真的我不确定的是,在本机移动应用程序中集成/使用OAuth2.0端点的上述技术是不安全还是我遗漏了一些东西.这是我的问题 -

• redirect_uri可以是一个http://localhostURL,可以包含任何端口号.端口号不是初始API配置的一部分,因此它可以是任何有效的端口号.此外,client_id(不应该是秘密)和client_secret并不是真正的秘密,因为它们嵌入在移动应用程序源代码中.

使用上述条件,不是以下可能性 -

1. 用户启动App2
2. App2会将用户重定向到Google OAuth2.0端点,但在请求中,App2包含App1的client_id,并包含App2正在侦听的本地端口号.
3. 当用户被重定向并向Google OAuth2.0端点进行身份验证时,Google会向用户表明"App1(合法应用程序)要求代表用户访问Google API /数据"这似乎是一种网络钓鱼攻击,因为用户可能会单击是,认为是要求访问的App1.
4. 然后,Google OAuth2.0将向App2发出授权代码,然后App2可以发出下一个请求,包括App1的client_id和client_secret,并获取access_token和refresh_token,并继续从Google访问用户数据.

• redirect_uri也可以是 - urn:ietf:wg:oauth:2.0:oob这意味着 -

此值向Google授权服务器发出信号,表明授权代码应在浏览器的标题栏中返回.当客户端无法在没有重要客户端配置的情况下侦听HTTP端口时,这非常有用.Windows应用程序具有此特性.

使用此值时,您的应用程序可以感知页面已加载,并且HTML页面的标题包含授权代码.如果要确保用户永远不会看到包含授权代码的页面,则应由您的应用程序关闭浏览器窗口.执行此操作的机制因平台而异.

以上意味着授权代码在浏览器窗口的标题中返回.

我的问题是 - App2也可以感知页面已经加载并捕获授权代码,然后使用它(在App1之前)以及client_id和client_secret来获取access_token和refresh_token.浏览器实例是否是全局的,任何应用程序都可以监视它并且上述攻击情形是有效的,或者浏览器实例是否以某种方式特定于应用程序,以便只有App1可以感知/监视更改？

我的理解是正确的还是我错过了什么？我是否错过任何减轻上述威胁的缓解措施？或者鉴于我们是在移动操作系统平台上,上述风险是否有效但是被接受？

在移动应用程序中使用OAuth2.0的安全方法是什么？ - 在浏览器页面中显示授权代码并让用户在应用程序中手动输入它？在这种情况下,浏览器实例是私有的,以便其他应用程序无法监视它并在用户将其键入合法的apication之前获取授权代码本身？

任何帮助表示赞赏

感谢致敬,