Теги 'коди'

android virus

Android-вірус FakeInst маскується під гаманець Google Wallet і краде дані кредитних карт

На Android-смартфонах з'явився новий троянець FakeInst, який маскується одночасно і під офіційний магазин додатків Google Play, і під додаток платіжної системи Google Wallet, наполегливо вимагаючи у користувача реквізити його банківської карти. Переважна більшість спроб зараження зареєстровано в Росії, слідом з великим відривом йдуть США, а потім країни Європи і Азії.

Маскування шкідливих програм під системні сервіси - поширений прийом зловмисників. У випадку з Android нерідкі випадки видавання шкідливого ПЗ за встановлені системні програми, такі як «Налаштування» і «Ліхтарик», однак автори нового шкідника пішли далі, імітуючи не тільки зовнішній вигляд платіжного клієнта системи Google Wallet, а й використовуваний багатьма легітимними онлайн-сервісами механізм прив'язки банківської карти.

Троянець розповсюджується за допомогою SMS-спаму з пропозицією встановити оновлення Google Play і відразу після запуску запрошує права адміністратора, блокуючи можливість роботи з пристроєм до їх отримання. Домігшись свого, шкідлива програма відображає вікно з вимогою введення реквізитів банківської карти нібито для її авторизації в системі Google Wallet.

«Особлива небезпека зловреда в тому, що його автори використовують досить переконливий прийом соціальної інженерії - запитують реквізити банківської картки, обіцяючи утримати незначну суму для верифікації облікового запису. Справа в тому, що на цей гачок можуть клюнути навіть досвідчені користувачі - вони знайомі з багатьма легітимними онлайн-сервісами, які застосовують схожі механізми підтвердження особи.

Розпізнати троянця можна по напору, з яким він наполягає на введенні фінансових реквізитів, а ще простіше - по повідомленню від захисного рішення класу Internet Security, яке виключить можливість запуску і видалить шкідливу програму з системи», - коментує Микита Бучка, антивірусний експерт групи дослідження загроз для мобільних платформ «Лабораторії Касперського».

Введена користувачем інформація картки перевіряється на відповідність формату BIN (Bank Identification Number) і на приналежність до досить великого списку платіжних систем. Тільки отримавши коректні дані, троянець закриває вікна і відсилає зібрані відомості на сервер зловмисників. Але це ще не кінець - шкідлива програма, не подаючи зовнішніх ознак, продовжує функціонувати на мобільному пристрої, збираючи інформацію про його власника, а отримані на першому етапі роботи права адміністратора пристрою дозволяють трояну вкоренитися в системі.

За повідомленням «Лабораторії Касперського»

Можливо вас зацікавлять подібні статті:

Коментарі

Немає коментарів до цієї статті.

Коментарі

Поля позначені як * потрібні обов’язково. Перед постінгом завжди робіть перегляд свого коментаря.





Боротьба з дублями сторінок на сайті

Боротьба з дублями сторінок на сайтіВласник може і не підозрювати, що на його сайті деякі сторінки мають копії — найчастіше так і буває. Сторінки відкриваються, з їх вмістом все гаразд, але якщо тільки звернути увагу на URL, то можна помітити, що при одному і тому ж контенті адреси різні. Що це значить? Для живих користувачів це нічого, так як їм цікава інформація на сторінках, а ось бездушні пошукові машини сприймають таке явище абсолютно по-іншому — для них це абсолютно різні сторінки з однаковим контентом.

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

Також наявність дублів розмиває посилальну масу, який оптимізатор намагався зосередити на цільовій сторінці. Через дублі, вона може виявитися зовсім не на тій сторінці, на яку масу хотіли перенести. Тобто ефект від внутрішньої перелінковки і зовнішніх посилань може багаторазово знизитись.

В переважній більшості випадків у виникненні дублів винні CMS — через неправильні налаштування та відсутність належної уваги оптимізатора генеруються чіткі копії. Цим грішать багато CMS, зокрема, Joomla. Для вирішення проблеми важко підібрати універсальний рецепт, але можна спробувати скористатися одним з плагінів для видалення копій.

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

Багато фахівців стверджують, що невелика кількість дублів не зашкодить сайту, але якщо їх більше 40-50%, то ресурс при просуванні можуть чекати серйозні труднощі. У будь-якому випадку, навіть якщо копій не так багато, варто зайнятися їх усуненням, так ви гарантовано позбавитеся від проблем з дублями.

Пошук сторінок-дублів

Існує кілька способів пошуку дубльованих сторінок, але для початку варто звернутися до декількох пошуковиків і подивитися, як вони бачать ваш сайт — потрібно лише порівняти кількість сторінок в індексі кожного. Зробити це досить просто, не вдаючись до жодних додаткових засобів: в «Яндексі» або Google досить в рядок пошуку ввести host:yoursite.ru і подивитися на кількість результатів.

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

Шукати дубльовані сторінки можна за URL у видачі пошуковика. Якщо у них повинні бути ЧПУ, то сторінки з URL з незрозумілих символів, на зразок «index.php? S = 0f6b2903d», будуть відразу вибиватися із загального списку.

Ще один спосіб визначення наявності дублів засобами пошукових систем — це пошук за фрагментами тексту. Процедура такої перевірки проста: треба ввести фрагмент тексту з 10-15 слів з кожної сторінки в рядок пошуку, а потім проаналізувати результат. Якщо у видачі буде дві і більше сторінок, то копії є, якщо результат буде всього один, то дублів у даної сторінки немає, і можна не хвилюватися.

Логічно, що якщо сайт складається з великої кількості сторінок, то така перевірка може перетворитися на нездійсненну рутину для оптимізатора. Щоб мінімізувати тимчасові витрати, можна скористатися спеціальними програмами. Один з таких інструментів, який напевно знакомий досвідченим фахівцям, — програма Xenu`s Link Sleuth.

Щоб перевірити сайт, необхідно відкрити новий проект, вибравши в меню «File» «Check URL», ввести адресу і натиснути «OK». Після цього програма почне обробку всіх URL сайту. По закінченні перевірки потрібно експортувати отримані дані в будь-який зручний редактор і почати пошуки дублів.

Крім перерахованих вище способів в інструментарії панелей «Яндекс.Вебмастер» і Google Webmaster Tools є засоби для перевірки індексації сторінок, якими можна скористатися для пошуку дублів.

Методи вирішення проблеми з дублями сторінок

Після того як всі дублі будуть знайдені, потрібно їх усунути. Це теж можна зробити декількома способами, але для кожного конкретного випадку потрібен свій метод, не виключено, що доведеться використовувати різні способи.

  • Сторінки-копії можна видаляти вручну, але такий спосіб скоріше підійде тільки для тих дублів, які і були створені ручним способом по необачності вебмайстра.
  • Редірект 301 відмінно підходить для склеювання сторінок-копій, URL яких відрізняються наявністю і відсутністю www.
  • Вирішення проблеми з дублями за допомогою тега canonical можна застосовувати для нечітких копій. Наприклад, для категорій товарів в інтернет-магазині, які мають дублі, що відрізняються сортуванням за різними параметрами. Також canonical підійде для версій сторінок для друку і в інших подібних випадках. Застосовується він досить просто — для всіх копій вказується атрибут rel = "canonical", а для основної сторінки, яка найбільш релевантна, — не вказується. Код повинен виглядати приблизно так: link rel = "canonical" href = "http://yoursite.ru/stranica-kopiya" і стояти в межах тега head.
  • У боротьбі з дублями може допомогти настройка файлу robots.txt. Директива Disallow дозволить закрити доступ до дубль для пошукових роботів.

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

Можливо вас зацікавлять подібні статті:

Коментарі

Немає коментарів до цієї статті.

Коментарі

Поля позначені як * потрібні обов’язково. Перед постінгом завжди робіть перегляд свого коментаря.





Помилка «strict standards non-static method» в Textpattern

strict standards non-static methodТак, що ж це така за помилка «non-static method»  в Textpattern і як з нею справитись? Взагаліто в даному конкретному випадку з Textpattern 4.4.1 така помилка виникає із-за певних відмінностей (а їх таки вистачає, причому суттєвих) між PHP 5.3.x та PHP 5.4.x . Зокрема в PHP 5.4.4 E_ALL тепер включає помилки рівня E_STRICT в конфігураційній директиві error_reporting. А в текстпаттерні якраз і присутні кілька кодів, що генерують помилку рівня E_STRICT. Раніше ми її просто не помічали, а на версії PHP 5.4.4 вся адмінка текстпаттерна рясніє помилками «Strict Standards: Non-static method theme::init() ...» Виникає вона через те, що у файлах /textpattern/index.php та /textpattern/lib/txplib_misc.php деякі не статичні методи визиваються як статичні.. Зовні на роботу сайту це ніяк не впливає, усе ніби працює (якщо не працює — значить включений режим «тестування» або «відлагоджування»), от тільки в адмінці працювати неможливо.

Звісно розробники знайшли досить простий вихід з цієї ситуації, хоча сумніваюсь що він є досить хорошим (правильним). Проте яким би він не був — головне, що у Textpattern 4.4.1 це працює. А полягає він в простій фільтрації помилок E_STRICT в директиві error_reporting. Отож ближче до коду ;)

Перед редагуванням файлів — рекомендую зробити їх резервні копії. На всяк випадок :) Щоб позбутись помилок типу «strict standards non-static method» в Textpattern 4.4.1 необхідно виправити наступні два файли:

в файлі /textpattern/index.php шукаєм код:

error_reporting(E_ALL);

і заміняєм наступним кодом:

// We need to violate/disable E_STRICT for PHP 4.x compatibility                                              
// E_STRICT bitmask calculation stems from the variations for E_ALL in PHP 4.x, 5.3, and 5.4

error_reporting(E_ALL & ~(defined('E_STRICT') ? E_STRICT : 0));                                             

у файлі /textpattern/lib/txplib_misc.php шукаєм код:

error_reporting(E_ALL /* TODO: Enable E_STRICT in debug mode/PHP5.x? | (defined('E_STRICT') ? E_STRICT : 0) */);

і заміняєм на:

// We need to violate/disable E_STRICT for PHP 4.x compatibility
// E_STRICT bitmask calculation stems from the variations for E_ALL in PHP 4.x, 5.{0,1,2,3}, and 5.4+
// E_STRICT is defined since PHP 5.x and is set in E_ALL in PHP 5.4

error_reporting(E_ALL & ~(defined('E_STRICT') ? E_STRICT : 0));

шукаєм:

// default is 'testing': display everything except notices
error_reporting(E_ALL ^ (E_NOTICE));

заміняєм на:

// default is 'testing': display everything except notices and strict
error_reporting((E_ALL ^ E_NOTICE) & ~(defined('E_STRICT') ? E_STRICT : 0));

От і усе, зберігаємо зміни і юзаєм текстпаттерн на PHP5.4.4 Інформація щодо змін з сторінки релізів початкового коду r3679 Доречі, у бета версії Textpattern 4.5.0 цю проблему виправлено аналогічним методом.

Можливо вас зацікавлять подібні статті:

Коментарі

  • Avatar textmaster

    Користувався версією Textpattern 4.4.1 після вимушеної зміни хостингу виникла аналогічна проблема…
    Дякую за рекомендації, допомогло!

  • Avatar savio

    дякую! допомогло, не знав що PHP 5.4 в E_ALL включає помилки рівня E_STRICT

Коментарі

Поля позначені як * потрібні обов’язково. Перед постінгом завжди робіть перегляд свого коментаря.