oleksandrblazhko
commented
1 year ago Оцінка = 5 балів. Дякую за активність!
Closed VIVAskAVIV closed 1 year ago
oleksandrblazhko
commented
1 year ago Оцінка = 5 балів. Дякую за активність!
Варіант 1. CVE-2022-20607 Запитання № 1.1
Вразливість знайдено у Google Pixel https://uk.wikipedia.org/wiki/Google_Pixel Google Pixel — бренд споживчих пристроїв, розроблений Google, що працюють на Chrome OS або операційній системі Android. Бренд був представлений у лютому 2013 року разом із першим поколінням Chromebook Pixel. Лінійка пристроїв Pixel включає планшети, ноутбуки та смартфони, а також деякі аксесуари. Вразливість є на продуктах з Android. Тому споживачами є досить велика кількість людей, яким потрібен смартфон.
Запитання № 1.2 У стільниковому мікропрограмному забезпеченні Pixel можливий запис поза межами через відсутність перевірки меж. Це може призвести до віддаленого виконання коду з необхідною автентифікацією LTE. Для використання не потрібна взаємодія з користувачем. Продукт: AndroidВерсії: ядро AndroidІдентифікатор Android: A-238914868
Запитання № 1.3 За посиланням у розділі References to Advisories, Solutions, and Tools представлено список вразливостей 2022 року, без уточнення проблеми та програмного коду.
Запитання № 2.1
Приклад погроз аутентифікації Compromised CSP asserts identity of a claimant who has not properly authenticated
Створення/модифікація твердження – суб’єкт загрози може створити шахрайське твердження або змінити вміст твердження (наприклад, твердження про автентифікацію чи атрибути) існуючого твердження, змусивши RP надати невідповідний доступ Підписнику. Наприклад, суб’єкт загрози може змінити твердження, щоб продовжити термін дії; і Підписник може змінити твердження, щоб мати доступ до інформації, яку він не повинен мати можливості переглядати
Міжсайтовий скриптинг Основна мета створення CSP полягає в усуненні XSS-атак та зборі даних про їх спроби. XSS-атаки використовують довіру браузера до контенту, отриманого з сервера. Шкідливі скрипти виконуються в браузері жертви, оскільки браузер довіряє джерелу, навіть коли скрипт поставляється не звідти, звідки здається.
CSP дає можливість адміністраторам серверів знизити або повністю усунути вектора, за якими зловмисники можуть провести XSS, за допомогою визначення доменів, які браузер клієнта повинен вважати довіреними джерелами скриптів, що виконуються. У такому разі браузер, сумісний з CSP, буде виконувати тільки ті скрипти, які були отримані зі списку дозволених джерел, та ігнорувати інші (включаючи вбудовані скрипти та обробники подій, вказані безпосередньо в HTML-атрибутах).
Як крайній захист, сайти, які хочуть заборонити виконання скриптів, можуть налаштувати цю поведінку глобально, за допомогою відповідної опції.
Пакетний сніффінг На додаток до обмеження кількості довірених доменів, з яких дозволяється отримувати контент, можна також обмежити список протоколів, що використовуються; наприклад (в ідеалі і це вкрай бажано з точки зору безпеки), сервер може поставити обмеження на отримання контенту тільки за HTTPS. Завершена стратегія захисту даних повинна включати не тільки примус до використання HTTPS, але також і позначку всіх кук за допомогою спеціального прапора, а також перенаправлення запитів з HTTP на HTTPS. Сайти також можуть використовувати Strict-Transport-Security HTTP-заголовок, щоб забезпечити підключення до них браузерів лише захищеним каналом.
Запитання № 2.2 Загальна вимога щодо захисту як від розкриття твердження, так і від виготовлення/модифікації твердження може бути описана як взаємно автентифікований захищений сеанс або еквівалент між Верифікатором і RP. Будь-який протокол, який вимагає, щоб серія повідомлень між двома сторонами була підписана джерелом і зашифрована для одержувача, надає ті самі гарантії, що й захищений сеанс із взаємною автентифікацією, і може вважатися еквівалентним.
Твердження може бути підписано цифровим підписом верифікатора. RP має перевірити цифровий підпис, щоб переконатися, що його надав законний верифікатор.