Salesforce REST API, как избежать утечки конфиденциальных данных в параметре запроса - PullRequest
1 голос
/ 17 марта 2020

Я пытаюсь выполнить запрос, используя REST API, и столкнулся со следующей проблемой:

При использовании запроса GET на конечной точке запроса открывается вся строка запроса, которая может содержать конфиденциальные данные, такие как SSN, телефон число, и т. д. c ...

https://[instance-url].my.salesforce.com/services/data/v48.0/query/?q=SELECT Id FROM Contact WHERE SSN__c = '123456789'

Как можно выполнить такой запрос с использованием rest api безопасно? Есть ли эквивалентный запрос, который я могу сделать, используя, по крайней мере, POST-запрос с телом сообщения, являющимся запросом? так как эта часть зашифрована по https.

Спасибо за помощь

Ответы [ 2 ]

1 голос
/ 21 марта 2020

У вас есть два варианта.

  1. Параметризованный API поиска . Эта опция доступна из коробки с методом POST в качестве метода. API является RESTful-интерфейсом для текстовой поисковой системы Salesforce. Обычно текстовый поиск использует SOSL в качестве языка запросов. Параметризованный API поиска пропускает SOSL и дает вам более простую опцию для работы.

Если вы поместите следующее тело в /services/data/v48.0/parameterizedSearch

{
   "q": "123456789",
   "sobjects": [
      {
         "name": "Contact",
         "where": "SSN__c = '123456789'"
      }
   ],
   "fields": ["id"]
}

, вы должны увидеть что-то вроде этого: ответ, при условии, что при поиске возвращается одна запись (идентификатор отредактирован):

{
  "searchRecords" : [ {
    "attributes" : {
      "type" : "Contact",
      "url" : "/services/data/v48.0/sobjects/Contact/003..."
    },
    "Id" : "003..."
  } ]
}

Значение ключа q в полезной нагрузке JSON должно совпадать со значением в where ключ / пункт. Вы выполняете полнотекстовый поиск по номеру 123456789 по всем объектам и всем полям поискового индекса. Это может вернуть много записей ... но вы фильтруете поиск структурированным образом, чтобы гарантировать, что вы увидите только Contact записей, где SSN__c = '123456789'. Пока объекты + поля, которые вы пытаетесь получить, присутствуют в индексе, результаты, которые вы увидите с помощью поиска по параметрам в этом конкретном примере c, будут такими же, как и в запросе SOQL через /query

Пользовательский API REST (он же Apex REST / веб-сервис Apex). Это типичный вариант реализации для таких случаев, как ваш. Вы можете отправить любую полезную нагрузку через POST, а затем обработать ее так, как вам нравится.

Класс Apex:

@RestResource(urlMapping='/findcontactbyssn')
global class ContactResource {
    @HttpPost
    global static void findContactBySSN() {
        SearchRequest input = (SearchRequest)JSON.deserialize(RestContext.request.requestBody.toString(),SearchRequest.class);
        Contact c = [SELECT Id FROM Contact WHERE SSN__c = :input.ssn];
        SearchResponse output = new SearchResponse();
        output.id = c.id;
        RestContext.response.responseBody = Blob.valueOf(JSON.serialize(output));
        RestContext.response.statusCode = 200;  
    }

    class SearchRequest {
      public String ssn {get;set;}
    }

    class SearchResponse {
      public String id {get;set;}
    }
}

POST до /services/apexrest/findcontactbyssn с

{
 "ssn": "12345678"
}

, и вы должны увидеть этот ответ:

{
 "id": "003..."
}
1 голос
/ 20 марта 2020

AFAIK, salesforce предоставляет только метод GET для выполнения запросов SOQL. Можно написать свою собственную конечную точку REST в своей организации, которая принимает запрос в теле и выполняет его, но, на мой взгляд, это пустая трата времени.

Параметры строки запроса защищены через https. Это распространенное заблуждение, когда люди думают, что весь URL открыт в текстовом виде при передаче. Когда делается запрос к https URL-адресу, сначала он устанавливает безопасный туннель на [instance-url].my.salesforce.com, а затем передает оставшуюся часть URL-адреса и любые другие данные по безопасному туннелю.

Если вы беспокоитесь о какой-то человек в середине атаки извлекает SSN из вашей строки запроса, не надо. Недостатком является то, что если вы обращаетесь к этому URL-адресу из браузера вместо вызова программы c, то у браузера есть возможность сохранить / кэшировать историю или выполнить автозаполнение, тогда это будет не очень хорошо.

Но я сомневаюсь, что вы сможете сделать это через браузер, поскольку salesforce требует токен-носитель, установленный в заголовке авторизации, и я не знаю простого способа установить заголовки при вводе URL-адреса в браузере или нажатии ссылка.

Чтобы узнать больше о том, как строка запроса защищена по протоколу https, обратитесь к к этому вопросу стекопотока

...