Twitter OAuth dance 使用 GET 进行身份验证,但 Apex CSRF 保护仅针对 POST 提供

发布于 2025-01-01 11:30:57 字数 883 浏览 2 评论 0原文

这是我正在尝试解决的一个安全问题。一切都工作正常,我可以让用户从发往 AppExchange 的托管包中通过 Twitter 身份验证。问题在于 Twitter OAuth 1.0 进程(或“舞蹈”)具有从 Twitter 返回到我的应用程序的 GET 发生的通信步骤。虽然这可行,但根据安全测试通过在线以及现在使用 CxViewer 的安全审查流程,这是一个危险信号在 Eclipse 中。

但我需要从 Twitter 获取此信息并以某种方式为每个用户存储它。此问题的示例代码入口点(其中 Twitter 从我的一个 auth_token 请求回调)将是:

Page:

<apex:page controller="AuthController" action="{!completeAuthorization}"/>

Apex:

public PageReference completeAuthorization() 
{
   String token = ApexPages.currentPage().getParameters().get('oauth_token');
   CustomObject__c c = new CustomObject__c(Name = token);
   insert c; // <--- Security flaw here! (except that it's Twitter, not Trojan.com)
}

我已阅读所有提供的有关该主题的 Apex 文档,再次阅读它,浏览论坛并查看不幸的是想出了 zilch/nada。任何帮助将不胜感激!

This is a security issue I'm trying to figure out. Everything works fine and I can get users authenticated to Twitter from inside my managed package destined for the AppExchange. The problem is that the Twitter OAuth 1.0 process (or "dance") has communication steps that occur with GETs coming from Twitter back into my application. Although this works, it's a red flag for the security review process according to security test passes online and now with CxViewer in Eclipse.

But I need to get this information from Twitter and store it somehow for each user. A sample code entry point with this issue, where Twitter is calling back from one of my auth_token requests, would be:

Page:

<apex:page controller="AuthController" action="{!completeAuthorization}"/>

Apex:

public PageReference completeAuthorization() 
{
   String token = ApexPages.currentPage().getParameters().get('oauth_token');
   CustomObject__c c = new CustomObject__c(Name = token);
   insert c; // <--- Security flaw here! (except that it's Twitter, not Trojan.com)
}

I've read all the supplied Apex documentation on the subject, read it again, looked through the forums and unfortunately came up with zilch/nada. Any assistance would be greatly appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

温柔戏命师 2025-01-08 11:30:57

这是我的发现。该问题涉及让 GET 参数指示有关 Salesforce 中所选对象的任何内容,然后将数据保存到该对象。我不相信存在真正的安全问题,并且使用我的新代码,安全测试毫无问题地通过了。发生的事情本质上是这样的:

String token = ApexPages.currentPage().getParameters().get('oauth_token');

CustomObject__c pcs = [
SELECT Id, User__c, Token__c 
FROM CustomObject__c 
WHERE Id = :UserInfo.getUserId() 
AND Token__c = :EncodingUtil.urlEncode(token, 'UTF-8'];

由于整个交换是从我的上下文开始的,我 100% 确定当前用户 (UserInfo.getUserId()),所以我不需要检查这是否是特定的 em> 令牌匹配,因为用户得到保证(至少与我启动此过程有关)。因此,以下选择工作正常:

CustomObject__c pcs = [
SELECT Id, User__c, Token__c 
FROM CustomObject__c 
WHERE Id = :UserInfo.getUserId()];

然后,如果我对此对象进行更新:

update pcs;

它不会抱怨,因为传入的 GET 值与选择用于写入的对象没有任何连接。然而,正如您可能注意到的那样,只要我将其包含

WHERE Id = :UserInfo.getUserId()

到 SOQL 语句中,就从来没有真正出现过问题。原因是,无论攻击尝试在我的代码中注入什么虚假令牌,它仍然会针对当前用户进行验证,并且如果用户不匹配,则在任何情况下都会失败。但在 Salesforce 中,不可能像大多数系统一样让两个并发用户同时登录,因此令牌检查从一开始就显得有些过分了,因为我从不与其他人共享我的用户 ID叽叽喳喳。

需要存储的实际令牌(oauth_token 和 oauth_secret)可以作为 POST 参数检索,因此具有内置的 Salesforce CSRF 保护。这些是这样检索的:

Http h = new Http();
HttpRequest req = new HttpRequest();
req.setMethod('POST');
req.setEndpoint(accessTokenURL);
req.setBody('');
sign(req);
HttpResponse res = new HttpResponse();
String resParams = res.getBody();
Map<String,String> rp = new Map<String,String>();

if(resParams != null)
{
   for(String s : resParams.split('&')) 
   {
      List<String> kv = s.split('=');
      rp.put(kv[0],kv[1]);
   }
}

tK.Secret__c = rp.get('oauth_token_secret');
tK.Token__c = rp.get('oauth_token');

upsert tK; // No problem, it's from a POST body

我正要发布赏金;)

Here's what I discovered. The issue relates to having the GET parameter dictate anything about the object selected in Salesforce and then saving data to that object. I don't believe there was ever a real security issue and with my new code the security test passes with no problem. What was happening is essentially this:

String token = ApexPages.currentPage().getParameters().get('oauth_token');

CustomObject__c pcs = [
SELECT Id, User__c, Token__c 
FROM CustomObject__c 
WHERE Id = :UserInfo.getUserId() 
AND Token__c = :EncodingUtil.urlEncode(token, 'UTF-8'];

Since this whole exchange begins from my context, where I'm 100% certain of the current user (UserInfo.getUserId()), I don't need to check whether this particular token matches since the user is guaranteed (at least as it relates to me initiating this process). So the following select works fine:

CustomObject__c pcs = [
SELECT Id, User__c, Token__c 
FROM CustomObject__c 
WHERE Id = :UserInfo.getUserId()];

Then later if I do an update to this object:

update pcs;

it doesn't complain since the GET value passed in doesn't have any connection with the object chosen for the write. As you might notice, however, there never really was a problem - as long as I included

WHERE Id = :UserInfo.getUserId()

to the SOQL statement. The reason is that no matter what false tokens an attack tried to inject into my code, it was still verifying against the current user and would fail in any case if the user didn't match. But in Salesforce there's no possible way to have two simultaneous users logged in at the same time, like most systems, so the token check was overkill from the start, since I'm never sharing my User Ids with Twitter.

The actual tokens that need to be stored (oauth_token and oauth_secret) can be retrieved as POST parameters and therefore have built-in Salesforce CSRF protection. These are retrieved like this:

Http h = new Http();
HttpRequest req = new HttpRequest();
req.setMethod('POST');
req.setEndpoint(accessTokenURL);
req.setBody('');
sign(req);
HttpResponse res = new HttpResponse();
String resParams = res.getBody();
Map<String,String> rp = new Map<String,String>();

if(resParams != null)
{
   for(String s : resParams.split('&')) 
   {
      List<String> kv = s.split('=');
      rp.put(kv[0],kv[1]);
   }
}

tK.Secret__c = rp.get('oauth_token_secret');
tK.Token__c = rp.get('oauth_token');

upsert tK; // No problem, it's from a POST body

And I was about to POST a bounty ;)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文