З'єднання HTTPS є "не безпечним" через зображення


14

Зараз я працюю на веб-сайті, і я успішно встановив свій сертифікат SSL.

Засіб перевірки GeoTrust SSL / TLS підтвердив, що ланцюжок сертифікатів (включаючи CA) встановлений правильно. На Chrome все виглядає нормально, але мій замок не зелений, а на Firefox він фактично стверджує, що веб-сайт не захищений, оскільки на ньому є незашифровані елементи.

Я використовував онлайн-сервіс, щоб перевірити, чому це так, і виявилося, що справді мої зображення не вважаються захищеними URL-адресами. Як мені впоратися з цією ситуацією, інакше як безпечно вставляти зображення на свій веб-сайт?

Відповіді:


32

Наразі ваші графічні теги повинні виглядати так:

<img src="http://example.com/images/image.jpg">

Це httpозначає, що зображення НЕ подається надійно. Зловмисник може змінити зображення під час руху та тим самим змінити, як ваша захищена сторінка виглядає в іншому випадку для користувачів.

Натомість ви можете використовувати будь-яке з наведених нижче для безпечного обслуговування зображень:

  • Посилання на httpsявно:<img src="https://example.com/images/image.jpg">
  • Використовуйте відносне посилання на зображення у власному домені: <img src="/images/image.jpg">
  • Використовуйте відносне посилання протоколу, щоб використовувати зображення з інших доменів: <img src="//example.com/images/image.jpg">

Явні httpsзавжди будуть обслуговувати зображення послідовно (навіть коли сторінка не надто надійно подається), а відносне посилання буде обслуговувати зображення надійно, лише якщо сторінка розміщена надійно.

У Firefox та chrome ви можете натиснути на замок і отримати додаткову інформацію про проблему. Зробивши це, ось знімок екрана з Firefox, який показує список усіх зображень на сторінці. Легко відсканувати список і побачити, які з них є http:


2
"Зловмисник може змінити зображення під час руху та тим самим змінити, як виглядає ваша захищена в іншому випадку сторінка для користувачів". - або навіть викликати вразливість у рендері.
Джон Дворак

2
І викрадення файлів cookie, які можуть містити маркери доступу.
Darkhogg

Це дуже схоже на те, що його радять робити. Завдяки вам мені вдалося отримати зелений замок, але друг сказав, що шифрування зображень може уповільнити сторінку. Це питання в моєму випадку?
mti_

3
Звичайно, є певні накладні витрати на шифрування, проте зазвичай це не більше 10%. Цей штраф за ефективність (навіть за зображення) - це ціна, яку ви повинні заплатити за безпечний сайт.
Стівен Остерміллер

whynopadlock.com - це зручний інструмент для швидкого визначення незахищених ресурсів за певною URL-адресою.
Віль

5

Проблема полягає в тому, що на вашій сторінці розміщуються посилання з http-місця на відміну від https. Це пов’язано з використанням абсолютних http-посилань на довідкові ресурси, такі як зображення. Є два кращі методи, які дозволять вам посилатися на посилання на http або https та уникнути цього питання.

Він вимагає від вас знайти ці посилання та змінити їх на:

  1. відносні зв’язки: тобто./wp-content/yourtheme/images/image1.jpg
  2. або розміщуйте // в передній частині домену, як у //example.com/wp-content/wp-content/yourtheme/images/image1.jpg цьому пункті , тоді вони будуть обслуговувати ці ресурси через http або https, залежно від того, який запит був зроблений.

І в Chrome, і в Firefox ви можете натиснути значок замка, а потім натиснути кнопку, щоб переглянути список небезпечних посилань. І якщо ви не можете бачити зображення або інші ресурси, виділені в браузері, але все ще отримуєте помилки, ви можете виявити, що існує дзвінок javascript, який посилається на посилання абсолютно через http .


2
//на початку не n-стандарт, і такі веб-переглядачі, як Lynx, будуть скаржитися.
mirabilos

2
@mirabilos RFC 1808 є стандартом для URL-адрес і визначає відносні посилання протоколу (починаючи з //) у розділі 2.4.3. Стандарту зараз 15 років і його впроваджують усі основні браузери, включаючи Lynx
Стівен Остерміллер

#mirabilos Перевірте рекомендовані посилання на сховища Google. Ви виявите, що Google використовує їх вже багато років.
garth

1

Це дійсно базово. Коли ви створюєте веб-сайти, що обслуговуються через SSL (https), будь-яка посилання у вашому коді, яка не є попередньою https, підніме попередження щодо безпеки - крім посилань. Зауважте, що більшість (усіх) браузерів також мають відношення посилань до http за замовчуванням. Тож, якщо ви посилаєтесь /uploads/12/5/img.jpg або /js/jquery.js, протокол передачі за замовчуванням буде http - що насправді дратує.

Усі веб-переглядачі обробляють попередження дещо різними, але ви отримаєте якесь повідомлення. Загальним твердженням буде те, що новий браузер тим суворішим буде повідомлення. Деякі старі браузери практично ігнорують ці помилки, тоді як нові браузери можуть діяти так, як ваш світ атакується через відсутні "s".


10
"Більшість (усіх) браузерів також відносно посилання на http" за замовчуванням "Помилка, що? Абсолютно всі веб-переглядачі, якщо вони не порушені, використовуватимуть поточний протокол, якщо явно не вказати новий.
Олег Вікторович Волков

5
Олег має рацію; це не "дратує": це абсолютно неправильно.
Гонки легкості з Монікою

3
Це абсолютно неправильно. Нехтуйте цією відповіддю.
martijnve

@martijnve - Як моя відповідь неправильна?
blankip

4
@blankip див. коментар В. Волкова. Будь-яка посилання, що включає в себе http, неправильна ВСІ інші добре. (протокол відносний, відносний домен, відносний шлях). І вам слід використовувати відносні посилання майже у всіх випадках.
martijnve

1

Якщо жодна з цих пропозицій не допомагає, коли мова йде про неможливість відображення зображень після того, як ви включили SSL на своїй веб-сторінці, перевірте на випадок, якщо налаштування cPanel для Hotlinks, що знаходиться в розділі Безпеки cPanel. Цілком можливо, що в цьому налаштуванні ви маєте наступне: http://example.comі http://www.example.comувімкнено можливість доступу до зображень, поки їх httpsверсія не ввімкнена.


-4

Перевірте безпечну конфігурацію протоколу URL-адреси у своєму cms / wordpress / magento або будь-якій іншій платформі, яку ви використовуєте. Ви також можете поділитися деякими тегами зображень, але основні зображення img src не мають таких помилок.

Структура тегів для зображень є важливою, але фокус вашого питання я вважаю його відносно "типу" сертифіката SSL, встановленого на вашому сайті. Особистий випадок трапився зі мною "Стандартний сертифікат GoDaddy SSL.

На панелі пошуку Firefox (конкретно) ви побачите значок попередження, який говорить про те, що на вашому веб-сайті можуть бути незахищені зображення чи елементи. Наскільки я знаю, це лише питання про те, як Firefox обробляє інформацію про сертифікат або інформацію, що міститься в ньому. Це не відбувається в сафарі, хромі або інших браузерах. Я знайшов рішення для цього, встановивши замість "Стандартного SSL" "Преміум SSL сертифікат або сертифікат розширеної перевірки EVC ", який має більш детальну інформацію про сайти компанії. Ви отримаєте захищений зелений замок на замок.

Однак сертифікат преміум ssl може бути трохи дорожчим, приблизно від 150 до 200 доларів США на рік.

введіть тут опис зображення


5
Це неправда, тому що: 1) теги <img src = "..."> дійсно можуть призвести до такої помилки, якщо ви введете URL-адресу HTTP (на відміну від URL-адреси HTTPS) та 2) тип сертифікату або спосіб його обробки не має до цього абсолютно нічого
fNek

Я використовую для IMG src глобальні медіа-теги, такі як {{media url = "шлях / до / image.jpg"}} з протоколом ssl або без нього, і я не отримую помилок. До речі, я вказую на відображену помилку ssl Стефана Firefox. З повагою
Gaio RoOts

3
Якщо ви використовуєте відносні URL-адреси, проблем немає, оскільки вони відносні. Будь ласка, прочитайте іншу відповідь. Я знаю, що ви посилаєтесь на помилку Стівена. Типи сертифікатів досі не мають нічого спільного.
fNek

Тип сертифіката не впливає на так зване "попередження змішаного вмісту". Також усі сучасні браузери в наші дні демонструють попередження, деякі явно, а інші просто відмовляючись показувати значок блокування.
Martijn Heemels
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.