Безопасность - это нормально, чтобы отправить имя пользователя и пароль через HTTP GET?

Question

Мы - организация, которая приобрела систему, которая используется врачами для просмотра результатов анализов пациентов (довольно конфиденциальная информация). Будучи программистом, я совался с системой и обнаружил, что она отправляет имя пользователя и пароль через HTTP-запрос GET. В домене, на котором он запущен, все компьютеры настроены для обхода прокси-сервера, поэтому URL-адрес с запросом не будет сохранен в каком-либо журнале прокси-сервера. Но я бы сказал, что в любом случае это небезопасный способ обработки имени пользователя и паролей.

Производитель будет утверждать, что, поскольку мы никогда не просили об этом, это будет «улучшение», которое потребует дополнительных $$$. (Мы никогда не писали спецификации для системы в первую очередь).

В каком случае я мог бы обратиться к руководству, чтобы они почувствовали, что это не соответствует стандарту и что, вероятно, единственный способ обеспечить безопасность этой системы - через HTTPS?

РЕДАКТИРОВАТЬ: Спасибо за все ваши ответы! Я поднял вопрос с руководителем проекта, ее ответ был в духе «что такое HTTP?». Поэтому я планирую объяснить ей все это более подробно, исследовать юридические последствия и попытаться поставить вопрос перед программистами, непосредственно спрашивающими, почему они пошли по этому пути. Я также постараюсь объяснить ситуацию другим коллегам, которые не имеют прямого отношения, но могут оказать какое-то влияние на этот вопрос.

Answer 1

Если это медицинские данные и вы живете в Соединенных Штатах, есть большая вероятность того, что доступ к ним регулируется правилами HIPAA, включая требования безопасности. Вам следует просмотреть http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806.pdf. Если вы не проживаете в Соединенных Штатах, я бы посоветовал вам указать, что HIPAA относится к домену.

Если ваш поставщик пытается отодвинуться с дополнительной оплатой, скажите: «Вы говорите, что не соблюдаете соответствующие государственные стандарты? Боже, может быть, вам следует предоставить нам полную документацию о ваших стандартах безопасности и конфиденциальности, мерах предосторожности?» и процедуры. Потому что, очевидно, если бы нас ударили штрафом, мы бы пошли за тобой. "(IANAL и все такое.)

На техническом уровне, конечно, предложение управления эфиром, показывающее, насколько легко собирать имена пользователей и пароли, должно быть откровением для вашего руководства. Учитывая то, насколько просто прослушивать обычный сетевой трафик и как легко использовать SSL для транспорта, идея о том, что поставщик оттолкнет , что как «повышение безопасности», возмутительна.

Answer 2

Хороший способ заявить о себе - это найти относительно технического (или умного) менеджера, который поймет, если вы покажете им живой эфирный след логина (посмотрите! Вот пароль для пользователя: MrGreen. Что, дон не верите? Вот попробуй сам!).

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

Проведите прямую трассировку, объясните просто, что вы сделали (это может сделать любой в нашей сети, это так же просто, как установить эту программу). Позже объясните, что в системе практически бесплатно можно включить шифрование, которое предотвратит это, и что приложение едва ли нужно модифицировать как минимум. И что было бы полезно передавать все в зашифрованном виде, чтобы записи были намного безопаснее.

Затем оставьте этого менеджера позаботиться о соответствующих разрешениях / утверждении бюджета / что угодно.

И единственный разумный способ исправить это в целом - это использовать POST (чтобы исправить пароль, отправляемый в URL) и HTTPS.

Что меня больше всего беспокоит, так это то, что люди, отправляющие незашифрованные пароли по сети, вероятно, будут иметь множество других недостатков безопасности.

Answer 3

У вас есть два вопроса: один технический, другой договорный (и, следовательно, юридический). Я не стал бы просить юридического совета по переполнению стека.

Технический ответ очевиден - эти парни, которые сделали вашу систему, являются клоунами, так как они оставили в ней зияющую дыру в безопасности.

Юридически, это будет зависеть от того, в какой стране вы находитесь (я замечаю, что вы из Брисбена, так что привет из другой части страны). У многих будет медицинское законодательство и / или законодательство о неприкосновенности частной жизни, которое может быть нарушено, так что это одна вещь, которую нужно проверить. Законы HIPAA, которые другие предложили изучить, действуют только в США; у нас может быть эквивалент в Австралии, но я вполне уверен, что законы о конфиденциальности здесь, в Озе, могут быть включены в игру.

Точно так же вам нужно просмотреть договор (независимо от того, разработали ли вы его или нет, я предполагаю, что вы (или ваш предшественник) подписали его, в противном случае вы не обязаны платить им вообще), чтобы убедиться, что конфиденциальность была требование. Даже если это не так, компетентный юрист может утверждать, что это неявное требование.

Возможно, вам придется смириться с этим и заплатить дополнительные деньги - я работал на некоторые крупные компании, и они, как правило, снимают с себя всю ответственность за все, что не указано в результатах для клиента (это обычно записывается в контракт). Если ваш поставщик компетентен (с точки зрения бизнеса, а не удовлетворенности клиентов, конечно), он сделает именно это.

Но сначала , обратитесь за советом к юристу. Они - подонки с подонками :-), но они - люди, которые будут знать, что делать, и они лучше всего могут изучить контракты и посоветовать вам лучшие варианты, открытые для вас. Я использовал его около 10 лет назад, чтобы выйти из автомобильного контракта, который я больше не мог себе позволить, и, хотя он стоил несколько тысяч долларов, это было намного лучше, чем альтернатива.

Если они не посещают SO, совет, который вы здесь получите, либо искажен с технической стороны (в лучшем случае), либо совершенно опасен в юридическом смысле (тем более, что он будет в основном основан на законодательстве США) , Не желая рекламировать юристов, я знаю, что вы можете найти один здесь .

Удачи.

Answer 4

Даже при использовании SSL помните, что когда имена пользователей и пароли отправляются с помощью GET, они включаются в URL-адрес.

Это будет означать, что любые журналы сервера будут содержать имена пользователей и пароли как часть процесса регистрации. Поэтому вам необходимо защитить эти журналы или, по крайней мере, предотвратить запись строки запроса.

Answer 5

Я думаю, что для вашего случая вы должны настаивать на https, даже если он находится в «безопасной» сети.

Это похоже на http basic (basic позволяет это в заголовке - что предпочтительно, но вы также можете поместить его в URL в определенном формате, см. rfc2617 для получения дополнительной информации). *

с SSL / https, имя хоста будет открытым (очевидно, так как оно должно найти сервер), но остальные части URL должны быть надежно зашифрованы.

Answer 6

Имена пользователей и пароли никогда не должны передаваться в незашифрованном виде по сети, поэтому настаивайте на HTTPS для как минимум аутентификации. Я предпочел бы, чтобы имя пользователя и пароль принимались только через POST (чтобы он вообще не появлялся в URL), но вы могли бы зашифровать и закодировать пароль, чтобы его можно было вставить в запрос GET. Я не могу представить себе причину, по которой я бы сделал это вместо POST.

[РЕДАКТИРОВАТЬ] Как указали другие, если у вас есть данные, относящиеся к пациенту, вам может понадобиться зашифровать все коммуникации с сервером. Если вы находитесь в США, я настоятельно призываю вас ознакомиться с правилами HIPAA , чтобы выяснить, что здесь применимо в отношении защиты данных, особенно в части 164.306 правила конфиденциальности . (PDF).

Answer 7

Это не менее безопасно, чем встроенный обычная http-аутентификация.

Это правда, за исключением одного тонкого пункта, что имя пользователя и пароль, в зависимости от того, как устроена система, могут появиться в адресной строке окна браузера.

По крайней мере, я думаю, что они должны разместить эту информацию на сервере.

Answer 8

Это не менее безопасно, чем встроенная базовая HTTP-аутентификация. Просто убедитесь, что имя пользователя / пароль не кешируются клиентскими веб-браузерами (это в истории вашего браузера?)

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

Если вам необходимо разрешить доступ HTTP (хотя я не уверен, почему это так), то это абсолютно небезопасно. Вместо этого вы должны реализовать что-то вроде аутентификации доступа к дайджесту HTTP .

Я не думаю, что повышение безопасности - это то, что вы должны получить бесплатно от человека, занимающегося кодированием. Это, если только u / p не появляется в истории браузера.

Поскольку вы имеете дело с информацией о врачах и пациентах, мне также кажется, что сам контент должен быть зашифрован, а не только аутентификация. Так что вы действительно должны использовать HTTPS в любом случае.

Answer 9

Было ли это специальное программное обеспечение или что-то используемое другими? Если последнее, рассмотрите возможность присоединения или запуска группы пользователей, представляющей всех тех, кто использует программное обеспечение.