Как защитить веб-службу RESTful php с помощью безопасности SSL / TLS и / или уровня сообщений

У меня есть веб-сервис RESTful, написанный на php, который использует JSON для связи. Некоторые из передаваемых данных действительно чувствительны (пароли), и я ищу способ достичь разумного уровня безопасности для службы. Клиент – приложение silverlight 4.

Я искал четкую информацию о том, как реализовать SSL / TLS (я предполагаю, что проверка подлинности сертификата клиента входит в эту категорию?) И безопасность уровня сообщений, но я не могу найти хороших примеров относительно фактической реализации этих мер безопасности в php + json веб-сервис. Я был бы очень признателен за любые информационные и практические примеры. Я знаю принципы, я просто не очень разбираюсь в php. В настоящее время единственной мерой безопасности, которую я использую, является очень простая система маркеров аутентификации, которая при успешном входе в систему создает сеанс на стороне сервера и предоставляет пользователю токен аутентификации для любой последующей связи (до тех пор, пока сеанс не истечет или пользователь не соединится с другой IP). Я действительно хочу, по крайней мере, обеспечить конфиденциальный трафик, такой как пароли.

Наконец, каковы проблемы безопасности, которые я должен учитывать после внедрения TLS и, возможно, безопасности уровня сообщений, как в уязвимостях и эксплойтах?

Заранее спасибо.

Solutions Collecting From Web of "Как защитить веб-службу RESTful php с помощью безопасности SSL / TLS и / или уровня сообщений"

Предполагая, что HTTPS правильно настроена с использованием SSL / TLS, ваша основная проблема заключается в том, как реализовать аутентификацию для вашего сервиса RESTful. Поскольку HTTPS будет использовать SSL / TLS для шифрования связи между клиентом и серверным шифрованием, вам не о чем беспокоиться. Если вам нужно понять, как правильно настроить SSL / TLS, ознакомьтесь с разделом «Общие сведения о SSL / TLS»

Рекомендации по обеспечению безопасности службы RESTful уже обсуждаются в RESTful Authentication and Best Practices для обеспечения защиты REST API / веб-службы .

Подводя итог, обсуждаются 3 варианта

  • HTTP basic auth over HTTPS
  • Управление файлами cookie и сеансами
  • Аутентификация запроса с дополнительными параметрами подписи.

Другой вариант – изучить OAuth2 для аутентификации. Если это так, вы можете получить хорошее представление об Oauth2 в Руководстве для начинающих по OAuth. Часть III: Архитектура безопасности

Вы должны уже использовать SSL для получения установленной аутентификации.

Затем вы можете использовать тот же токен, который вы получили после аутентификации, в качестве секретного хэша для шифрования / дешифрования данных назад и вперед для этого соединения, пока оно не станет недействительным.

Если системы должным образом заблокированы (внутренние), вы можете пропустить SSL для шифрованной передачи данных, если вам требуется больше скорости (при условии, что исходный токен генерируется через SSL, и система знает, какой IP-токен назначен / etc).

Это может быть слишком элементарно для вашей ситуации, поскольку я ничего не знаю о Silverlight, но как насчет получения SSL-сертификата для вашего веб-API? Как и при создании вашего API, доступ к нему осуществляется только через протокол https: // вместо http: //. Это зашифрует все, что передается между клиентом и сервером.

Помните, что Rest не является протоколом. Вы можете думать, что ваш API похож на веб-страницу (но без интерфейса пользователя). Конфигурация https такая же.

Насколько я понял, у вас есть действующий код. Чтобы было проще, я покажу вам простой пример и то, как все работает с приведенным ниже кодом. Не стесняйтесь использовать только те части, которые вам нужны (что должно быть довольно прямолинейно).

То, как вы в настоящее время создали свое приложение, отлично работает с сеансами на стороне сервера.

В приведенном ниже коде я расскажу о некоторых дополнительных объяснениях и ссылках на ресурсы, которые помогут вам лучше понять код, протестировать и отладить ваше приложение.

$Web_Service_URL = 'https://website.tld/webservice.lang?wsdl'; $debug = false; $proto = 'https'; // eg str 'https' $agent = 'Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.0'; $download = false; // just to make a call and fetch nothing set to false //$download = '/location/my_file.html'; to fetch content and save to file set the file location // Init the cURL session $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $Web_Service_URL); /** * * Start Fix SSLv3/TLS connectivity problems * * CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER prevent MITM attacks * WARNING: Disabling this would prevent curl from detecting Man-in-the-middle (MITM) attack * */ /** * @param CURLOPT_SSL_VERIFYPEER * * FALSE to stop CURL from verifying the peer's certificate. * Alternate certificates to verify against can be specified with the CURLOPT_CAINFO option or a certificate directory can be specified with the CURLOPT_CAPATH option. * CURLOPT_SSL_VERIFYHOST may also need to be TRUE or FALSE if CURLOPT_SSL_VERIFYPEER is disabled (it defaults to 2). * Setting CURLOPT_SSL_VERIFYHOST to 2 (This is the default value) will garantee that the certificate being presented to you have a 'common name' matching the URN you are using to access the remote resource. * This is a healthy check but it doesn't guarantee your program is not being decieved. * */ curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); /** * @param CURLOPT_VERBOSE * Set the on/off parameter to 1 to make the library display a lot of verbose information about its operations on this handle. * Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, * or the stream set with CURLOPT_STDERR. * You hardly ever want this set in production use, you will almost always want this when you debug/report problems. */ curl_setopt($ch, CURLOPT_VERBOSE, $debug); /** * * @param CURLOPT_SSL_VERIFYHOST * * Check the existence of a common name in the SSL peer certificate. * Check the existence of a common name and also verify that it matches the hostname provided. * * @value 1 to check the existence of a common name in the SSL peer certificate. * @value 2 to check the existence of a common name and also verify that it matches the hostname provided. * In production environments the value of this option should be kept at 2 (default value). * Support for value 1 removed in cURL 7.28.1 */ curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); /** * * Force use of TLS * */ if($proto == 'https') { /** * * Let's explain the magic of comparing your TLS certificate to the verified CA Authorities and how does that affect MITM attacks * * Man in the middle (MITM) * Your program could be misleaded into talking to another server instead. This can be achieved through several mechanisms, like dns or arp poisoning. * The intruder can also self-sign a certificate with the same 'comon name' your program is expecting. * The communication would still be encrypted but you would be giving away your secrets to an impostor. * This kind of attack is called 'man-in-the-middle' * Defeating the 'man-in-the-middle' * We need to to verify the certificate being presented to us is good for real. We do this by comparing it against a certificate we reasonable* trust. * If the remote resource is protected by a certificate issued by one of the main CA's like Verisign, GeoTrust et al, you can safely compare against Mozilla's CA certificate bundle, * which you can get from http://curl.haxx.se/docs/caextract.html * */ //TODO: If TLSv1_1 found insecure and/or unreliable change to TLSv1_1 or TLS1_2 curl_setopt($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2); // CURL_SSLVERSION_TLSv1_1; CURL_SSLVERSION_TLSv1_2 curl_setopt($ch, CURLOPT_HEADER, 0); // Don't return the header, just the html if (strtoupper(substr(PHP_OS, 0, 3)) == 'WIN') { $crt = substr(__FILE__, 0, strrpos( __FILE__, '\\'))."\crt\cacert.crt"; // WIN } else { $crt = str_replace('\\', '/', substr(__FILE__, 0, strrpos( __FILE__, '/')))."/crt/cacert.crt"; // *NIX } // The cert path is relative to this file curl_setopt($ch, CURLOPT_CAINFO, $crt); // Set the location of the CA-bundle /** * Fix Error: 35 - Unknown SSL protocol error in connections * * Improve maximum forward secrecy */ // Please keep in mind that this list has been checked against the SSL Labs' WEAK ciphers list in 2014. $arrayCiphers = array( 'DHE-RSA-AES256-SHA', 'DHE-DSS-AES256-SHA', 'AES256-SHA', 'ADH-AES256-SHA', 'KRB5-DES-CBC3-SHA', 'EDH-RSA-DES-CBC3-SHA', 'EDH-DSS-DES-CBC3-SHA', 'DHE-RSA-AES128-SHA', 'DHE-DSS-AES128-SHA', 'ADH-AES128-SHA', 'AES128-SHA', 'KRB5-DES-CBC-SHA', 'EDH-RSA-DES-CBC-SHA', 'EDH-DSS-DES-CBC-SHA:DES-CBC-SHA', 'EXP-KRB5-DES-CBC-SHA', 'EXP-EDH-RSA-DES-CBC-SHA', 'EXP-EDH-DSS-DES-CBC-SHA', 'EXP-DES-CBC-SHA' ); curl_setopt($ch, CURLOPT_SSL_CIPHER_LIST, implode(':', $arrayCiphers)); } curl_setopt($ch, CURLOPT_TIMEOUT, 60); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true); if($debug == true) {curl_setopt($ch, CURLOPT_HEADER, 1);} // Get HTTP Headers Code curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); // ini_set('user_agent', 'NameOfAgent (http://www.example.net)'); curl_setopt($ch, CURLOPT_USERAGENT, $agent); /** * DEBUG cURL Call * Don't forget to uncomment the CURLOPT_HEADER' */ // Get HTTP Headers Code // Show Http Header if($debug == true) { echo "<pre>"; echo curl_getinfo($ch, CURLINFO_HTTP_CODE); } // TODO:Check if any cURL connection error occurred // see http://php.net/manual/en/function.curl-errno.php /** if(curl_errno($ch)) { echo 'Curl error: ' . curl_error($ch); } */ // Send the request and check the response if (($result = curl_exec($ch)) === FALSE) { die('cURL error: '.curl_error($ch)."<br />"); } else { //echo "Success!<br />"; } /** * @function cURL_GetInfo * other debug info, if needed * * The var_dump output: * array(26) { * ["url"]=> string(61) "https://www.example.com" * ["content_type"]=> string(24) "text/html; charset=UTF-8" * ["http_code"]=> int(200) * ["header_size"]=> int(2462) * ["request_size"]=> int(493) * ["filetime"]=> int(-1) * ["ssl_verify_result"]=> int(0) * ["redirect_count"]=> int(2) * ["total_time"]=> float(0.286363) * ["namelookup_time"]=> float(7.1E-5) * ["connect_time"]=> float(0.011754) * ["pretransfer_time"]=> float(0.082954) * ["size_upload"]=> float(0) * ["size_download"]=> float(119772) * ["speed_download"]=> float(418252) * ["speed_upload"]=> float(0) * ["download_content_length"]=> float(262) * ["upload_content_length"]=> float(0) * ["starttransfer_time"]=> float(0.156201) * ["redirect_time"]=> float(0.076769) * ["certinfo"]=> array(0) { } * ["primary_ip"]=> string(14) "xxx.xxx.xxx.xxx." * ["primary_port"]=> int(443) * ["local_ip"]=> string(12) "192.168.0.15" * ["local_port"]=> int(54606) * ["redirect_url"]=> string(0) "" * } */ $info = curl_getinfo($ch); $arrCodes = array( "client_error" => array("400", "401", "402", "403", "404", "405", "406", "407", "408", "409", "410", "411", "412", "413", "414", "415", "416", "417"), "server_error" => array("500", "502", "503", "504", "505") ); // Return the error code, if any and exit if(in_multi_array($info['http_code'], $arrCodes)) { file_put_contents("logs/dberror.log", "Date: " . date('M j Y - G:i:s') . " --- Error: " . $info['http_code'].' URL: '.$info['url'].PHP_EOL, FILE_APPEND); return $info['http_code']; exit; } curl_close($ch); // If download is defined download to the specified file if($download!= false) { $f = fopen($download, "w"); fwrite($f, $result); fclose($f); echo 'Web content downloaded to a file'; } echo $result; 

Как вы можете видеть в коде, вы можете определить несколько безопасных шифров, но только один параметр версии SSL. Я бы не использовал ничего раньше, чем TLS 1.1. Любая ранняя версия SSL уязвима для атаки. Начните с самого безопасного TLS 1.2 и теста, если ваше приложение работает (как правило, у вас не должно быть никаких проблем. Если у вас возникли проблемы с подключением, попробуйте TLS 1.1. Версия TLS версии 1.1 также уязвима, единственная безопасная (на данный момент, пока они не обнаружат некоторую уязвимость) является TLS 1.2.

Если приоритетом является безопасность, перейдите к самой доступной версии TLS (TLS1.2). Совместимость с клиентами – это не ваша проблема, когда есть ответственность за безопасность поставщика услуг.

Некоторые другие параметры cURL для просмотра:

  • CURLOPT_SSL_VERIFYHOST
  • CURLOPT_SSL_VERIFYPEER
  • CURLOPT_CAINFO (cURL предоставляет cacrt.crt на своем веб-сайте CA CERT )
  • CURLOPT_SSL_CIPHER_LIST

Шифры были проверены против сильного списка Qualys SSL Labs (2014) и были удалены слабые шифры. Не стесняйтесь добавлять / удалять любые шифры.

  1. Прежде чем принять решение, взгляните на проекты Qualys SSL Labs о безопасности.
  2. Взгляните на эту статью SSL Labs о совершенной секретности и передовой практике.
  3. Тестируйте свой клиент (веб-браузер) для любых уязвимостей с помощью веб-инструментария SSL Labs . Это даст вам представление о том, что посмотреть и что улучшить и защитить на вашем сервере и приложении.
  4. Проверьте свой веб-сайт / веб-сервис с помощью SSL- сервиса Qualys SSL Labs.

Уязвимости и атаки: Longjam, FREAK, POODLE, вы называете это! Кто знает, какие другие атаки или уязвимости не обнаружены? Да! Все они влияют на ваш выбор SSL / TLS-соединения.

Возможные параметры CURLOPT_SSLVERSION можно найти на официальной странице cURL: http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html

Вот также хорошее руководство OWASP для создания безопасного слоя вокруг вашего приложения.

OWASP и Qualys SSL Labs – отличные ресурсы для начала. Я бы даже сделал некоторые исследования по cURL и OpenSSL, чтобы ознакомиться с недостатками, возможными вариантами безопасности и лучшими практиками.

Есть точки безопасности, о которых я не упоминаю и их не хватает, но мы не можем охватить все.

Если у вас возникнут какие-либо вопросы, я буду рядом, чтобы ответить, если смогу.