Троянско прасе и Политика за сигурност на съдържанието на заглавката

Троянско прасе и заглавка на политиката за сигурност на съдържанието.

троянско

Тъй като малко по-рано засегнахме темата за любовта на търсачките към сайтове, които работят правилно с трудни заглавки (документ за If-Modified-Since като пример), би било логично да говорим за други, не по-малко трудни заглавки, които също имат много по-голямо влияние върху класирането на сайта.

Единственото лошо нещо е, че малко хора знаят за тези заглавки. Е, какво да се прави, ще ни светне.

Не е ясно защо разумните уеб администратори трябва да мислят за всичко това. Те нямат нищо подобно на сайта си, нали?

Вие не контролирате съдържанието на вашия сайт.

Например кликандъри, всякакви измами и всякакви други пикантерии, характерни за тийзърите, почти гарантирано ще бъдат нарисувани.

В този момент всички си помислиха: „Спрете, как е? Ако сайтът е гарантирано, че няма всички тези неща, защото уеб администраторът дава зъб, откъде ще дойдат такива връзки? Уебсайтът е повреден? Продавате нефилтрирани връзки? Дали показателят лъже безбожно?

Не, тези предположения не са верни. Цялото това безобразие е привлечено от сърфистите от собствените им браузъри. Когато ги намерите на абсолютно всеки сайт. И на вашия също.

От този момент нататък започваме да знаем, че в един модерен браузър множество добавки (значителна част от които всъщност са фалшиви и изобщо не са написани за това, което са посочили в срещата) могат лесно и просто да променят показвания HTML код на страницата, както желаете. Буквално.

И не можете да направите нищо по въпроса.

Малка илюстрация на това как работи фалшивият плъгин.

Нека бъде така - всичко може да се кликне:

съдържанието

Ако сега дадем на браузъра „арха-полезен“ плъгин, който уж прави нещо, същата страницасе превръща в тиква

политика

Виждаме как в горния десен ъгъл се появи ъгъл на примамка със светкавица вътре, изскочиха някои банери и след това изскачащи прозорци се втурнаха да се отворят - тази снимка вече не може да се покаже.

Ясно е, че екранизираната страница е избрана с причина - това е лицето на услуга, която ви позволява да видите целия шаманизъм, който плъгинът е вкарал в страницата. Списъкът на това зло буквално пада на пода:

сигурност

Защо това е лошо?

Тъй като има такъв параметър за класиране като поведенчески фактори. Плюс това, постулираната неприязън на търсещите към всякакви глупости на страниците, цитатът за това, което от Yandex беше по-висок (Google има всичко същото, само по-строго). И най-общо казано, нито една търсачка няма да разбере произхода на всякакви глупости на страниците на вашия сайт. Генерира трафик на вашия сайт за порно тийзъри - добре, това е.

Проблемът е, че днес вече не е толкова важно какво всъщност има на страниците на вашия сайт. Аудиторията на вашия сайт е важна. Ако изведнъж, по някаква причина, глупаци започнат да посещават сайта, тогава те ще донесат изобилни доставки от различни глупости със себе си.

Техните браузъри ще черпят от документите на вашия ресурс цялата непристойност, която съществува в природата. С подходящи преходи и персонализирано поведение.

Ще навреди ли на сайта? Без съмнение. Yandex директно обещава това.

И какво може да се направи по въпроса?

Има само два начина - или да се надявате, че магазинът за приложения на Google Chrome по някакъв начин ще филтрира злонамерени разширения, или да предотвратите възможността за вграждане от всеки и каквото и да било в HTML кода на вашите страници от страна на клиента.

Вторият начин очевидно е по-обещаващ и пряк.

За щастие такъв механизъм дори е предвиден. Просто е измисленоза този случай тя се нарича Политика за сигурност на съдържанието. Наръчници, по които лесно се търси в гугъл, включително и вече на български.

Същността на Политиката за сигурност на съдържанието.

Накратко, всички съвременни браузъри разбират и поддържат CSP инструкции, в които разработчикът на сайта посочва от кои хостове могат да се зареждат определени ресурси (по тип – изображения, скриптове, iframe и др.). Всъщност това е истински бял списък.

Плъгините и разширенията на браузъра задължително подлежат на такива инструкции, така че дори „заразен“ браузър няма физическата възможност да нарисува нищо на страницата. Освен ако, разбира се, този браузър не е първоначално от офис на изделия - бъдете внимателни към родословието на вашия софтуер.

Така че въпросът дали си струва да се занимавате с тънкостите на Политиката за сигурност на съдържанието дори не си струва. Ще трябва да вградите CSP в сайта по всякакъв начин. Просто трябва да разберете как да го направите с най-малко усилия.

Метод на свързване на политиката за сигурност на съдържанието.

Това обикновено се прави чрез израз във файла .htaccess, като се използва модулът mod_headers. Изглежда просто, но.

Нещо ми подсказва, че ако хоствате сайта си локално (локален уеб сървър като Denver или подобен), ще искате Правилата за сигурност на съдържанието да работят по същия начин, както в мрежата. Какво е разумно и правилно - удобно е да отстраните грешки в политиката за сигурност в локалната област, за да не се прецакате публично.

Но е малко вероятно някой да иска да премине през мисията, за да разпознае версията на Apache в Denver, да намери точно същата версия за Windows на външния сайт на Apache, да избере инсталатора на модула „mod_headers.so“ от msi и след това да го включи в Denver и придружаващата регистрация в конфигурациите.

Освен това,няма гаранция, че модулът mod_headers ще присъства на вашия сървър. Лесно може да отсъства, защото изпращането на хедъри от силите на Apache очевидно не е мейнстрийм.

Е, като цяло създаването на допълнително натоварване на Apache не е напълно правилно. Освен това катерене с неизмити ръце във файла .htaccess, което изисква нежно боравене. Където да се намесвате, без да познавате перфектно синтаксиса на малките цензурирани изрази там, обикновено е забранено.

Така че умишлено ще забравим за общоприетия начин за използване на Content Security Policy във файла .htaccess. И ние ще свържем политиката, така че изобщо да не са необходими допълнителни модули на сървъра.

Самурайски подход към политиката за сигурност на съдържанието.

Всеки двигател трябва да има файл, от който се инициира зареждането на всички необходими компоненти. Един вид сборен пункт.

Ако вземем нещо познато за специфика, например същия прословут Lasto Blog, тогава това ще бъде индексен файл в основата. Той просто открива версията на PHP на хоста и зарежда съответния файл на двигателя за тази версия на PHP (да, целият двигател живее в един файл - това е концепцията за преносим софтуер).

php /* Не трябва да има нищо над този ред във файла */

# Регистриране на отчети за правилата за сигурност на съдържанието:

if (isset( $_GET [ 'content-security-policy' ])) header ( 'HTTP/1.0 204 Няма отговор');

$report = file_get_contents ('php://input'); $report = json_decode ($report, true); ако (празно ($отчет)) умира;

$line = "\n" ; foreach ( array( ' blocked: ' => 'blocked-uri' , ' директива: ' => 'violated-directive' , ' document: ' => 'document-uri' , ) като $k => $v ) $line .= "\n" . $k .(isset( $report [ 'csp-report' ][ $v ]) ? $report [ 'csp-доклад' ][ $v ]: '' );

date_default_timezone_set ('Etc/GMT-6'); file_put_contents ( './data/csp/' . дата ( 'd-m-Y'). '.txt' , $line , FILE_APPEND LOCK_EX ); умре; >

# Отправка заголовка Правила за сигурност на съдържанието:

заглавие ( # "Content-Security-Policy-Report-Only: " // Отладка "Content-Security-Policy: " // Работа . " report-uri ./index.php?content-security-policy=ok;" . " default-src 'self';" . " img-src data: counter.yadro.ru *.gstatic.com 'self'; " . " script-src 'unsafe-inline' 'self';" //'unsafe-censored' . " frame-src *.google.ru *.google.com kset.kz *.youtube.com 'self';" . " object-src st.kset.kz www.youtube.com 'self';" . " connect-src https://translate.googleapis.com 'self';" . " style-src 'unsafe-inline' 'self';" . " media-src *;" . " font-src 'self';" . " form-action 'self';" );

$n =масив(); preg_match_all ( '

switch(isset( $n [ 1 ][ 0 ]) ? $n [ 1 ][ 0 ]: 'na' ) case 2 : case 3 : case 4 : include( './data/php_5_' . $n [ 1 ][ 0 ]. '.php' ); почивка; по подразбиране: die( 'Проверете PHP версията! ' . phpversion (). ' не се поддържа.' ); >

/* Ниже този ред във файла нищо не трябва да бъде. */ ?>

Виждаме, че сега всяка страница на Lasto Bloga изпраща браузъра доста сложен и странен хедер (заголовок), формиран във втория блок. По сути дела, това е обикновена текстова строка в доста неудобен синтаксис - виждаме, че у разработчиките не се хваща, но веднага се оперира сериализиран индексиран масив. И, съответно, сега много поколения уебмастери обречени да изучат птичий език.

Заголовъкът на хедера Content-Security-Policy-Report-Only задокументиран чебурашкой лев, и е алтернативна заглавка Content-Security-Policy (можете да хакнете този ред, като хакнете предишния). В текущото писане браузърът ще блокира всички ресурси, които противоречат на Правилата за сигурност на съдържанието, а като алтернатива само емулира работата, позволявайки ви да идентифицирате всички нарушители и да ги запишете в дневника.

Това е съответно режим на работа и режим на отстраняване на грешки.

Най-интересното в кода е директивата report-uri, която изпраща доклад за нарушение на политиката за сигурност към същия файл, но към първия блок от неговия код. Ако не е необходим такъв доклад, поставяме чебурашка пред строя.

Сега за докладите за нарушения на политиката за сигурност на съдържанието. Те се записват за всеки ден в папката ./data/csp/ (тя трябва да бъде създадена в блога на Lasto с права за запис) или в друга папка, която записвате в кода на първия блок.

Най-любопитното ще бъде точно в тези доклади.

Кой и какво вмъква в HTML кода на страниците на нашите файлове?

Както се оказа, различни разширения на браузъра, които искат да вмъкнат нещо в страниците на сайтовете, които преглеждате, са просто в насипно състояние. Такива разширения се откриват лесно в регистрационните файлове за домейни, в корена на които изобщо нищо не се отваря от браузъра.

Има и много реализации на dl.metabar.ru" и mc.yandex.ru - това е начинът, по който браузърите събират статистика.

Най-епичното нещо е, когато някой заблуден в компютъра на сърфиста надуши трафика, прихване заглавката на Content Security Policy, модифицира я и след това зареди своя Ajax в страницата, отворена от браузъра. Което, разбира се, се изпълнява, защото Политиката за сигурност не възразява срещу това.

Изненадващо създателите на браузъри не смятат това за измама и не правят нищо, за да я обезсърчат.

Забелязано в това поведение, например, Kaspersky - той vpendyuriruyut своя домейн gc.kis.scr.kaspersky-labs.com към директивата script-src. И съответно качва свои метрики на страниците, в които Бог знае какво седи и какво гледа. Има много начини за вграждане на собствени скриптове на Kaspersky в страници, гледани от браузъра, понякога дори пишат за това: Kaspersky ви наблюдава, за вашите пари.

Така че неспециалистът може да се плаши колкото си иска от Big Brother в лицето на Microsoft, който въведе "телеметрия" (под този термин се крие баналното шпиониране на потребителя) в цялата линия на Windows от седем до десет, но неспециалистът не знае най-важното.

Нямате нужда от шпиониране от операционната система, когато имате Kaspersky. Във всяка система с всеки браузър, той ще вмъкне своя Ajax във всяка страница и ще запише всички ходове. Дори политиката за сигурност на съдържанието не е указ за него - той я кове, както трябва.

Оценете потенциала, особено предвид популярността на Kaspersky. И това, че в офисите е забранено свързването на компютър към мрежата, ако няма инсталирана антивирусна. Освен това в държавните служби 146%, че ще бъде точно Kaspersky.

Е, фактът, че KaGiB е много по-лесен за преговори с Kaspersim, отколкото с всеки друг Big Brother, това е разбираемо за глупак.

Използвате ли политика за сигурност на съдържанието?

Трябва. Защото всички браузъри днес са написани на същата платформа като Chrome. И защото ще има милион разширения, най-различни. Включително фалшиви, които нанасят реална и осезаема вреда на вашия сайт.

Глупав уебмастър ще отхвърли всичко и ще продължи да забавлява посетителите с всичките глупости, показани на страниците на неговия сайт, чудейки се откъде идват. По някаква причина по-нататъшната му съдба изобщо не ни притеснява.

И друг график няма.

Актуализация 22.09.15 г.: Ами заразените браузъриYandex мисли?

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

Това е особено вярно за нишовите сайтове за развлечения. Интелектуалците изобщо не ходят там с всичките последствия.

Ако питате правилно, винаги ще получите отговор от Платон. И конкретно тук ще бъде обнадеждаващо - платоните разбират ситуацията перфектно, дори имат огромен списък със сайтове като teaser.bz и друг списък с плъгини. И да, Платонови знаят за какво е всичко това и как работи. Следователно самият сайт не подлежи на санкции.

Е, тъй като кралят и кралицата имаме тяхното величество поведенчески фактори и всичко се върти само около тях, напълно неразбираемо е как същите поведенчески фактори директно определят класирането на сайтовете.

Тоест взеха чист сайт, на който потребителите се държат така. Запомнете и запишете. След това изляха две кофи помия върху същия сайт, залепиха дузина изскачащи прозорци, разпръснаха обилно тийзъри с голи лели - и ето, поведенческите ни фактори изобщо не се промениха и сайтът по никакъв начин не пострада от това. Потребителите категорично не виждат голи лели, със силата на неизвестна магия се спасяват от изскачащи прозорци и твърдо не се поддават на никакви провокации.