За життя

Is Facebook Tracking Everywhere You Go Online? | WebProNews

Про те, як [саме] Facebook відслідковує всі ваші дії в вебі. Набагато настирливіше, ніж Google.

Upd: схоже, що вже виправили.
Брюс Шнайер описывает простой способ собирать конфиденциальную информацию: регистрация доменов, которые могут быть введены пользователем при наборе адресов электронной почты. Причем приводимый пример (countrpane.com instead of counterpane.com) особенно печален тем, что количество таких опечаток в принципе достаточно велико. Простых решений "сходу" я не вижу, т.к. невозможно зарегистрировать все домены с похожими наименованиями, как предлагает делать автор.
Якщо ви читали інтерв'ю із Джоанною Рутковською, то ви знаєте, що жорсткий диск - не єдиний притулок для шкідливого коду. А ось і чергове підтвердження.
А Сфінкс із своїми загадками - це просто система голосової авторизації.
10 найпоширеніших passcode'ів в iPhone. Я завжди казав, що у людей, котрі обирають iPhone, є певні проблеми з головою.
Passwords Getting to the Treasure
Вчора прийшло попередження, що один з ліцензіатів Comodo (InstantSSL) навидавав фішерам фальшивих сертифікатів для відомих сайтів (гугль,амазон, ebay, yahoo etc). Такі сертифікати потрібні для DNS poisoning'а і інших видів атак, пов'язаних із підміною сайтів. Ці сертифікати вже були відкликані через CRL (Certificate Revocation Lists), але додатково основні гравці (MIcrosoft, Google, Mozilla etc) випустили оновлення, щоб примусити свої продукти скачати свіжі CRL з сервера. Що потрібно зробити вам -- поставити доступні оновлення від основних виробників мережевого ПЗ. Microsoft вже роздає цей апдейт через Windows Update, решту софта треба перевіряти. Також не забувайти включати в мережевих програмах опції (де наявні) "перевіряти статус сертифікатів в онлайні" і "отримувати листи відкликання сертифікатів" (ці опції можуть називатись по-різному в різних програмах. Нагадаю, що від DNS Poisoning'а із використанням такого фальшивого сертифікату ви так просто не врятуєтесь, хіба що у вас локально записані справжні адреси цих сайтів (але це ідея погана і складна в реалізації для пересічного громадянина)
Це мало колись статись. Дослідники детально вивчили можливості отримання інформації виходячи з розміру шифрованих пакетів. Як з'ясувалось, в багатьох випадках з факту наявності пакетів певного розміру можна зробити обгрунтоване припущення про певні факти. Таким чином саме лише шифрування даних при їх передачі в web applications не дає потрібної приватності. На жаль, на сьогодні універсального рішення цієї проблеми немає.
Некая организация провела опрос, по итогам которого составила детальный список наиболее опасных (часто встречающихся и существенных по последствиям) ошибок в программировании веб-приложений и разработке веб-сайтов. Список включает в себя детальное описание каждой ошибки с примерами. Читать полезно как разработчикам, так и начинающим хакерам :)
Американские ученые из Кембриджского университета нашли простой способ обходить защиту кредитных карт пин-кодом (еще информация тут). Пересказывать не буду, ибо описано подробно по ссылкам. Но сама проблема старая - пин не шифрует данные, а лишь служит для идентификации владельца. Соответственно, такая "защита" обходится в точке проверки совпадения введенного и "карточного" пина. Решение тоже простое - пин-код должен использоваться для шифрования данных карты (хотя бы xor'ом).
Шнайдер приводит заметку о производителях железа, которые сели в лужу сами и посадили туда FIPS сертификаторов.

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

Ну и вопрос в том, что же проверяли и как сертифицировали эти флешки.
В Windows Vista нашли очередную прореху (или, точнее сказать, нашли очередную возможность напакостить). Дело не новое, прорех таких еще будет.

Очень умилил комментарий горе-искателя: "The software company should have done more software quality assurance (SQA) on the networking components, he said in an e-mail interview with SecurityFocus. If they did, they would have easily found the issue -- it took his fuzzer only 15 packets to crash the component, he said." .

Я это понимаю так: человек посылал некоторое количество мусора и на определенной комбинации получающая сторона не смогла данный мусор обработать как следует. Но данный искатель явно не писал софт - чтобы найти прорехи такого рода, софт нужно бомбардировать разными комбинациями запросов неделями, а то и месяцами. У нас при разработке файловой системы баги вылазят до сих пор, но это баги типа "при размере страницы в 512 байт, если имя потока равно 22 символа, при этом имя файла, к которому относится поток, превышает 432 байта, то у имени файла потеряется один байт". Теперь представьте, сколько длин имен файлов и потоков нужно перебрать, чтобы отловить такую ошибку. А это я пример из простых привел.

Вообще, с поиском дыр задача очень интересная. Компания строит дом. Для жилья. Понятно, что двери в доме можно вынести бульдозером, или можно отобрать ключи у вышедшего на прогулку жильца. Но дом построен для жилья, а не для защиты от всех напастей на свете. От последних построено бомбоубежище, но согласитесь ли вы в нем жить?

Прикрутил к сайту, использующему продукт Bitrix: Управление Сайтом, правильную работу через HTTPS.

Дано: сайт на Apache + nginx, SSL сертификат.

Требуется: сделать так, чтобы логин и доступ к некоторым секциям сайта происходили только по HTTPS.

Решение:

1. При использовании nginx, по крайней мере так, как нам его настроил хостер, HTTPS запросы обрабатывает сам nginx, который посылает запросы апачу по обычному соединению (чтобы не плодить ненужных сущностей). Поэтому у сервера не будет определена $_SERVER["HTTPS"]. Решением является прописать в nginx.conf, в секцию, посвященную SSL'у, строки "proxy_set_header X-HTTPS 'on'; " . Этот кастомный заголовок потом увидит скрипт, приведенный ниже.

Если у вас нету nginx'а, а SSL запросы обрабатывает апач, то вышеприведенное не нужно, а нижеследубщий скрипт нужно будет изменить.

2. В /bitrix/php_interface/init.php прописываем

AddEventHandler("main", "OnBeforeProlog", "OnBeforePrologHandler", 10, $_SERVER['DOCUMENT_ROOT'].'/my_scripts/check_ssl.php');

3. В check_ssl.php пишем (обязательно читайте комментарий ниже!!!)


function OnBeforePrologHandler(&$arFields)
{
if(defined("NEED_AUTH") && NEED_AUTH)
{
if ($_SERVER["HTTP_X_HTTPS"] != "on")
{
$link="https://" . $_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"];
if ($_SERVER["QUERY_STRING"] != "")
$link = $link . "?" . $_SERVER["QUERY_STRING"];
LocalRedirect($link);
}
}
}
?>

Комментарий: переменная HTTP_X_HTTPS устанавливается как описано в шаге 1. Если у вас Апач честно ставит переменную $_SERVER["HTTPS"], то вы должны анализировать ее.

4. В нужных местах в коде страниц перед включением пролога пишете define("NEED_AUTH", true);

5. Следующий этап необходим, если у вас есть сторонние скрипты, которые проверяют HTTPS через $_SERVER["HTTPS"], а у вас nginx, как описано в шаге 1.
В httpd.conf или в аналогичный файл настроек apache'а пишем строку

php_value auto_prepend_file /path/to/prefix_file.php

А в prefix_file.php пишем

if ($_SERVER["HTP_X_HTTPS"] == "on")
$_SERVER["HTTPS"] = "on";
?>

Этот префиксный файл будет исполняться перед всеми PHP скриптами, и будет устанавливать $_SERVER["HTTPS"]


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

UPD: хостер написал еще такой вариант:

nginx передает заголовок X-HTTPS=on
В apache в нужном сайте (eldos.com) добавь

>--------------- код -------------------
SetEnvIf SSL SSL HTTPS=on
>---------------------------------------

Это скажет php, что делать с SSL


Не проверялось.
Поштова скринька завалена спамом з вірусами. І вони все валяться і валяться десятками на годину. Цікаво, це чергова 0-day vulnerability чи щось інше?..
Оскільки, як виявляється, ще не всі знають, що це таке, то наводжу посилання на сайт, присвячений цьому питанню. І краще знайомство із цим методом вести суто теоретичне :).
Багато сучасних автомобілів підтримують відкриття / закриття дверей кнопкою і блокування можливості заведення двигуна за допомогою ключа дистанційного доступу. Такий ключ лежить в кишені і, коли людина підходить до автомобіля, автомобіль "бачить" ключ і дозволяє людині відкрити центральний замок.

Компанія Phoenix (автор відомого AwardBIOS в PC ком'ютерах) пропонує програму Freeze, яка дозволяє зробити схожий ключ зі звичайного телефона з Bluetooth'ом. Якщо людина відходить від комп'ютера з телефоном в кишені, програмне забезпечення автоматично заблокує роботу комп'ютера та опціонально переведе його в standby режим.

Ідея дуже цікава, але не без недоліків. Тримати Bluetooth ввімкненим в сучасних смартфонах малореально - дуже швидко сяде батарея. Та й в ноутбуці bluetooth теж не задарма працює ...

Як на мене, RFID-ключі для автентифікації користувача були б також цікаві, хоча це й вимагає встановлення додаткового "заліза" в ноутбуки, в той час, як bluetooth є в багатьох ноутбуках. І носити ключ треба буде (хоча це не проблема, - його можна тримати в гаманці разом з кредиткою).
  • Архів

    «   Жовтень 2021   »
    Пн Вт Ср Чт Пт Сб Нд
            1 2 3
    4 5 6 7 8 9 10
    11 12 13 14 15 16 17
    18 19 20 21 22 23 24
    25 26 27 28 29 30 31