Каковы опасности незащищенных статических ресурсов вашего безопасного веб-приложения? - PullRequest
2 голосов
/ 24 марта 2010

Мы создаем типичные веб-приложения, защищенные https. Чтобы иметь возможность кэшировать статические ресурсы, я хотел бы выставлять изображения, файлы JavaScript и т. Д. Через http. В противном случае они не будут привязаны. Это целесообразно с точки зрения безопасности? Какие риски связаны?

РЕДАКТИРОВАТЬ: Я хотел бы, чтобы статический контент кэшировался прокси и браузерами. На самом деле, наиболее важной проблемой здесь является кэширование этого содержимого обратным прокси-сервером, поэтому мне не нужно вручную распространять статический контент на http-сервер (обратный прокси-сервер).

Ответы [ 4 ]

6 голосов
/ 24 марта 2010

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

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

Однако предположим, что у вас (по любой причине) есть изображение с банковскими реквизитами клиента. Вы должны передать это по http? вероятно нет.

EDIT: Кроме того, когда вы смешиваете запросы http и https в некоторых браузерах, ваши клиенты будут получать неприятные всплывающие сообщения, информирующие их о том, что часть содержимого не зашифрована

2 голосов
/ 24 марта 2010

По следующим вопросам возможно кэширование содержимого HTTPS.

Будет ли веб-браузер кэшировать содержимое через https

0 голосов
/ 27 марта 2010

Я хотел бы предоставить изображения, файлы JavaScript и т. Д. Через http. В противном случае они не будут привязаны. Это целесообразно с точки зрения безопасности? Какие существуют риски?

Если вы смешиваете содержимое http и https на странице, то эта страница по своей сути небезопасна. Скажем, ваша страница доставлена ​​через https и имеет форму, которая отправляет данные на ваш веб-сервер. Теперь, когда ваш JS отправляется по протоколу http, посредник может заменить его содержимое и добавить строку, чтобы изменить параметр действия вашей формы. Таким образом, он сможет публиковать данные на своем сервере, а не на вашем.

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

Если вы беспокоитесь о безопасности, не смешивайте http и https. Если вас интересует кеширование - возможно кешировать ответы https. Браузеры делают это, если у вас есть правильные заголовки. Я предполагаю, что промежуточные прокси также сделают то же самое. Возможно, вы можете перечислить используемые вами прокси-серверы, и кто-то может прокомментировать его стратегию кэширования.

0 голосов
/ 24 марта 2010

Используйте https, но http для JavaScript. Как бы это не было плохой идеей ??

Помимо конфиденциальности, https защищает целостность трафика. Оказывается, что почти везде, где вы можете сбросить сетевое соединение, вы можете перерасти этот недостаток в злонамеренное повреждение.

С точки зрения удобства использования (хорошие) браузеры помечают любую страницу https, содержащую компоненты http, как небезопасную.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...