2013-05-01 2 views
10

Я создал веб-приложение CORS (только javascript), где I хочу, чтобы его устанавливали и запускали в разных локальных сетях.Защита WIFI для веб-приложения

Я бы хотел поставить SSL, но я не знаю, какая именно конфигурация будет lan и, вероятно, она будет отличаться каждый раз. Итак, я думаю, что я не могу добавить сертифицированный SSL. Есть ли возможное другое решение с SSL? Мне не нравится подход добавления несертифицированного SSL-протокола из-за предупреждений.

Как еще я могу зашифровать пакеты и сделать безопасную аутентификацию запросами? Я использую CouchDB по умолчанию CORS, но пакеты могут быть нюхать, если веб-приложение установлено и используется в открытом WIFI. Приложение использует только javascript, и я не знаю, как я могу защитить его (единственный бэкэнд - это хранилище на диване).

+1

«Приложение использует только javascript, и я не знаю, как я могу его защитить». Я бы сказал, что javascript - это язык на стороне клиента, вы не можете его защитить! –

+1

Какова роль WIFI в этой настройке? – likeitlikeit

+0

Использование SSL (HTTPS) обеспечит безопасную связь (целостность и конфиденциальность), даже если ваше веб-приложение будет доступно через открытый Wi-Fi, поскольку все данные запроса и ответа HTTP зашифровываются перед отправкой по сети. Обеспечение Wi-Fi предполагает использование одного из протоколов для обеспечения безопасности беспроводной сети, Wired Equivalent Privacy (WEP) или защищенного доступа Wi-Fi (WPA) (http://en.wikipedia.org/wiki/Wireless_security), который может независимо от использования SSL, для защиты вашего открытого Wi-Fi. Обратите внимание, что SSL обеспечивает защиту через Интернет между вашим клиентом и вашим веб-приложением. –

ответ

6

Дизайн вашего приложения с поддержкой CORS напрямую не связан с использованием SSL. См. this section of the CORS specification.

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

Вы даже не должны предполагать, что веб-сервер, на котором размещен ваш код, совпадает с веб-сервером, выполняющим SSL, поскольку SSL termination может быть другим устройством, которое затем проксирует запросы обратно на веб-сервер.

Что бы я сделал в случае, таком как этот документ, потенциальную потребность в SSL в ваших инструкциях по установке и позволить людям делать это (или нет) таким образом, который подходит для их среды.

2

Насколько я понимаю ваш вопрос (только для JavaScript), вы можете использовать один хост HTTPS для работы с файлами JavaScript, как и Google's hosted libraries.

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

2

Итак, если я правильно понимаю ваш вопрос:

  • У вас есть веб-приложение, которое можно получить с помощью запросов кросс-происхождения.
  • Это приложение будет развернуто в локальных сетях, то есть будет доступно через негосударственный IP-адрес (аппарат, обслуживающий его в этой сети, я буду называть его «локальным сервером»).
  • Вы хотите защитить связь между клиентом и локальным сервером, предпочтительно используя SSL.

Вы можете это сделать! Сделать, кто имеет контроль над локальным сервером, получить сертификат SSL для somesubdomain.SomeDomainHeControls.com, развернуть этот сертификат на локальном сервере и указать этот поддомен на локальный IP-адрес. Когда приложение будет доступно через этот адрес, вы не получите никаких предупреждений, и соединение будет защищено. Пока клиент только обращается к вашему приложению с использованием этого домена, это безопасно, поскольку только владелец сервера имеет доступ к ключу.

Если вы сами управляете локальным сервером (никто не может извлечь закрытый ключ), вы можете просто получить сертификат wildcart для *.aDomainForThisPurposeThatYouControl.com и создать субдомен для каждого развертывания, указав на соответствующий IP-адрес.

Если вы не контролируете локальный сервер и кто не может получить его собственный сертификат, вы можете получить индивидуальных сертификатов для них. Это означало бы, что вы создаете deployment1.aDomainForThisPurposeThatYouControl.com, укажете его на локальный IP-адрес, создайте обычный сертификат с одним хостом для этого имени и установите его на локальном сервере. В качестве меры предосторожности не используйте этот домен для чего-либо еще, поскольку вы предоставили личные ключи для хостов в этом домене.

Вы также можете разместить приложение непосредственно на внешнем сервере под вашим контролем, если локальные сети имеют доступ к Интернету. Разверните обычный SSL на этом сервере. После того как само приложение было загружено с внешнего сервера надежно, оно может сделать простые HTTP-запросы для получения данных с локального сервера. Это вызовет предупреждение «смешанного содержимого», но не будет ошибки SSL. Затем вы можете использовать шифрование на основе JavaScript для защиты данных. Например, если вы хотите защитить данные, идущие от клиента к серверу, ваш внешний доверенный сервер может предоставить клиенту доверенные JS-крипто-библиотеки и открытый ключ RSA внутреннего сервера (через SSL-аутентифицированное соединение), то вы просто зашифровываете свои данные на стороне клиента перед отправкой через простой HTTP. Теоретически вы даже можете создать SSL-клиент в JavaScript, предоставить сценарий и сертификат доверенного сервера клиенту, использовать туннель HTTP или WebSockets и через этот туннель запустить собственное SSL-соединение между локальным сервером и клиентом JavaScript , Это, конечно, не очень практично, но безопасно (поскольку JS загружается через безопасное соединение). Вы также можете просто загрузить небольшой JavaScript с доверенного сервера, который затем загружает остальное с локального сервера, проверяет подпись/хэш и выполняет его. Megaupload делает что-то подобное.

Смежные вопросы