Как да търсите зловреден код без антивируси и скенери. Как да търсите зловреден код без антивируси и скенери Как да търсите зловреден код в WordPress

1. Разопаковайте го в папката на сайта.
2. следвайте връзката your_site/fscure/
3. всичко

Какво може да направи той?

1. Автоматично търсене на вируси по сигнатури.
2. Търсене на низ във файлове
3. Изтриване на файлове
4. Коригирайте зловреден код с помощта на регулярни изрази

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

Как работи?

При първото стартиране той създава индекс от файлове. Файлът fscure.lst е в папката. Показва списък с файлове, съдържащи потенциално злонамерени подписи. „Потенциално злонамерен“ означава, че ще трябва да решите дали е вирус или не. Списъкът с подписи е конфигуриран във файла config.php, константа SCAN_SIGN. С настройките по подразбиране скриптът не проверява js файлове и не съдържа подписи за тях.

Най-често срещаните проблеми

1. не създава индекса fscure.lst. Може да се случи, ако няма достатъчно права. Поставете 777 в папката fscure

2. 5xx грешка. Най-често "504 Gateway Time-out". Скриптът няма време за обработка и се срива поради изчакване. В този случай има няколко начина за ускоряване на работата му. Скоростта зависи главно от размера на индекса. Това е във файла fscure.lst. Обикновено файл до 5 MB може да бъде обработен в 90% от случаите. Ако няма време, можете да намалите "алчността" на скрипта, като забраните сканирането *.jpg;*.png;*.css в конфигурацията.
Във файла config.php.

// разделител; define("FILES_EXCLUDE","*.js;*.jpg;*.png;*.css");

3. Хостингът издава предупреждение като
(HEX)base64.inject.unclassed.6: u56565656: /var/www/u65656565/data/www/34535335353.ru/fscure/index.php

В сценария няма вирус и никога не е имало. И (HEX)base64.inject.unclassed.6 е конструкция като "echo base64_decode(", която често се среща и сама по себе си е доста безобидна. Въпреки това, в последната версия, замених този код.

Какво да направите, ако не сте успели да откриете вируса сами?

Можете да се свържете с мен за помощ. Цените ми са скромни. Давам гаранция за работата си 6 месеца. Цената на работата е 800 рубли. за 1 сайт. Ако има няколко сайта в акаунта ви, цената се определя индивидуално.

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

Моите реквизити:
yandex
41001151597934

webmoney
Z959263622242
R356304765617
E172301357329

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

Специалист с необходимите знания и опит трябва да извърши работа за премахване на злонамерени скриптове и да анализира причините за хакване:

  • За да премахнете злонамерени скриптове, са ви необходими познания по езика за програмиране PHP, както и познания за „вътрешността“ на популярните CMS (Joomla, WordPress и др.) и разширенията за тях. Тези познания са необходими за разграничаване на скриптове директно от CMS и нейните разширения от външни файлове, както и за да можете недвусмислено да определите какви действия извършват, когато се натъкнат на съмнителни скриптове.
  • За да се анализират причините за хак, е необходим опит в администрирането на сървъра. Това е необходимо, за да се анализира състоянието на файловете в акаунта, времето, когато са били променени, както и да се сравнят тези данни със сървърните регистрационни файлове, за да се определи кои действия на нападателя са довели до хакване на сайтове.

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

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

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

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

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

  • Веднага след откриване, че даден сайт е бил хакнат, е необходимо напълно да блокирате достъпа на посетителите до него. Това, първо, ще попречи на нападателя да извършва злонамерени дейности на сайта, и второ, няма да му позволи да се намесва в работата по възстановяването. Тази стъпка е много важна, тъй като премахването на злонамерени скриптове и елиминирането на причината за хака не се случва за една нощ - като правило отнема няколко часа. Ако сайтът остане достъпен отвън, атакуващият ще може да качи отново скриптове в раздела на сайта, който вече е изчистен. В този случай нападателят може да използва различни IP адреси за свързване, така че отказът на достъп само до списък с IP адреси няма да работи. За да се гарантира, че сайтът е почистен от открити злонамерени скриптове, е необходимо напълно да се блокира достъпът на атакуващия до сайта, което може да стане само чрез пълно блокиране на сайта за всички посетители. Свържете се със службата за техническа поддръжка на хостинга, който хоства вашия сайт, за да го блокирате.
  • След като блокирате сайта, трябва да проверите компютрите, от които сте работили със сайта, с модерна антивирусна програма с актуализирани вирусни бази данни. Ако сайтът е бил хакнат чрез кражба на пароли за акаунти с помощта на вирус, трябва да се уверите, че по-нататъшната работа с хакнатия сайт се извършва от компютър, който няма вируси, в противен случай след промяна на паролите за достъп те могат да бъдат откраднати отново.
  • След като блокирате сайта и проверите за вируси, трябва да смените всички пароли за достъп до вашия акаунт: достъп през FTP, през SSH, както и достъп до контролния панел на хостинга. Ако нападател получи достъп до файловете на акаунта, използвайки един от тези методи, след като паролите бъдат променени, той вече няма да може да го направи.
  • След като промените паролите, трябва да унищожите всички сървърни процеси, работещи под акаунта, на който се поддържа сайтът. Процесите, стартирани от атакуващ във фонов режим, без да бъдат унищожени, ще могат да поставят отново злонамерени скриптове на сайта след извършване на възстановителна работа. За да не се случи това, всички процеси, изпълнявани преди блокирането на сайта, трябва да бъдат унищожени. Сайтът вече трябва да е блокиран в този момент, така че атакуващият да не може да стартира нови процеси чрез достъп до някой от неговите скриптове на сайта. За да унищожите процесите, изпълнявани във вашия акаунт, свържете се със службата за техническа поддръжка на хостинга, който хоства вашия сайт.
  • Сега е невъзможно да проникнете в сайта отвън и можете да започнете да го възстановявате.
  • Преди по-нататъшни действия изтрийте всички съществуващи файлове на сайта, за да се уверите, че няма злонамерени скриптове или CMS скриптове, в които атакуващият е вмъкнал злонамерен код. Тази стъпка също е важна, защото при възстановяване на сайт от резервно копие, файловете, които са съществували преди възстановяването, не винаги се изтриват. Ако след възстановяване от резервно копие на сайта останат стари злонамерени скриптове, нападателят ще може да влезе отново в сайта. Можете да избегнете това, като изтриете всички файлове на сайта, преди да извършите възстановяване.
  • След като изтриете всички файлове на сайта, възстановете сайта от архив, създаден преди да бъде хакнат. Често е достатъчно да възстановите само файловете на сайта, но ако след възстановяването им се наблюдават грешки в работата на сайта, е необходимо да възстановите сайта напълно: както файловете, така и базата данни.
  • След като възстановите от резервно копие, актуализирайте системата за управление на съдържанието (CMS) и разширенията до най-новите версии. Това е необходимо, за да се изключи наличието на известни уязвимости на сайта, чрез които той може да бъде хакнат. По правило актуализацията може да се извърши през секцията за администриране на CMS. За получаване пълни инструкцииЗа да актуализирате CMS, трябва да отидете на уебсайта на разработчика на системата. Важно е да актуализирате не само самата CMS, но и всички нейни разширения, тъй като хакването често се случва чрез уязвимост, присъстваща в едно от разширенията на CMS (например плъгини, теми, джаджи и т.н.). В този момент все още е невъзможно сайтът да бъде деблокиран за посетители, тъй като може все още да е уязвим. За да получите достъп до вашия сайт за актуализиране, свържете се с техническата поддръжка на хостинга, хостващ вашия сайт, и поискайте да разрешите достъп до сайта само от IP адреса на вашия компютър. Можете да разберете вашия IP адрес, например, на inet.yandex.ru.
  • След като актуализирате системата за управление на сайта и нейните разширения, отидете в раздела за администриране на сайта и променете паролата за администраторски достъп до него. Уверете се, че сред потребителите на сайта няма други потребители с администраторски привилегии (те могат да бъдат добавени от нападател) и ако бъдат намерени, ги изтрийте.
  • Сега, след като сайтът е възстановен от резервно копие и не съдържа злонамерени скриптове, CMS и неговите разширения са актуализирани до най-новите версии, в който няма уязвимости и са променени паролите за достъп до сайта и хостинг акаунта, можете да отворите отново сайта за посетители.
  • Всички горепосочени действия трябва да се извършват в съответствие с посочения ред, без пропуски или промени. Ако действията се извършват неточно, на сайта могат да останат злонамерени скриптове или уязвимости, в резултат на което след кратко време той може да бъде отново хакнат от нападател. Ако по някаква причина не е възможно да изпълните горните стъпки във формата, в която са посочени, свържете се със специалист, който да извърши работа по възстановяване на сайта след хакване.

    За да защитите сайта си от повторни хакове в бъдеще, трябва да се придържате към следните препоръки:
  • Следете актуализациите на CMS и разширенията за него на уебсайтовете на разработчиците и своевременно ги актуализирайте до най-новите версии. Ако коментар за актуализация гласи, че коригира уязвимост, инсталирайте актуализацията възможно най-скоро.
  • Работете със сайта и хостинг акаунта само от компютри, които са защитени от вируси от съвременни антивируси с постоянно актуализирани бази данни с вируси.
  • Използвайте сложни пароли, така че да не могат да бъдат отгатнати чрез търсене в речника.
  • Не запазвайте пароли за FTP и SSH в програми за свързване към сайта и не запазвайте паролата за достъп до административната област на сайта и контролния панел на хостинга във вашия браузър.
  • От време на време (например веднъж на три месеца) сменете паролите за достъп до сайта и хостинг акаунта.
  • Ако са открити вируси на компютъра, от който сте работили със сайта, сменете паролите за достъп до сайта и хостинг акаунта възможно най-бързо. Трябва да смените всички пароли: паролите за достъп през FTP, SSH, паролата от административния панел на сайта, както и паролата от контролния панел на хостинга.
  • Не предоставяйте достъп до сайта на трети страни, освен ако не сте сигурни, че те също ще следват тези указания.
  • Зловреден код попада на сайта поради небрежност или злонамерено намерение. Целите на злонамерения код са различни, но по същество той вреди или пречи на нормалното функциониране на уебсайт. За да премахнете зловреден код в WordPress, първо трябва да го намерите.

    Какво е злонамерен код на WordPress сайт?

    от външен вид, най-често злонамереният код е набор от букви и символи на латинската азбука. Всъщност това е криптиран код, чрез който се извършва това или онова действие. Действията могат да бъдат много различни, например новите ви публикации веднага се публикуват на ресурс на трета страна. Това по същество е кражба на вашето съдържание. Кодовете имат и други „задачи“, например поставяне на изходящи връзки на страниците на сайта. Задачите могат да бъдат най-сложни, но едно е ясно: злонамерените кодове трябва да бъдат преследвани и премахвани.

    Как злонамерените кодове попадат в уебсайт?

    Има и много вратички за кодове за влизане в сайта.

  • Най-често това са теми и плъгини, изтеглени от „леви“ ресурси. Въпреки това, такова проникване е типично за така наречените криптирани връзки. Явният код не се озовава на сайта.
  • Най-опасно е проникването на вирус при хакване на сайт. По правило хакването на сайт ви позволява да поставите не само „еднократен код“, но и да инсталирате код с елементи на злонамерен софтуер (злонамерена програма). Например, намирате код и го изтривате, но той се възстановява след известно време. Опциите отново са много.
  • Нека веднага да отбележа, че борбата с такива вируси е трудна и ръчното премахване изисква знания. Има три решения на проблема: първото решение е да използвате антивирусни добавки, например плъгин, наречен BulletProof Security.

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

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

    Как да търсите злонамерен код в WordPress

    Важно е да разберете, че злонамереният код на WordPress може да бъде във всеки файл на сайта, а не непременно в работната тема. Той може да измисли плъгин, тема или „домашен“ код, взет от Интернет. Има няколко начина да се опитате да намерите зловреден код.

    Метод 1: Ръчно. Превъртате през всички файлове на сайта и ги сравнявате с файловете на незаразен архив. Ако намерите чужд код, изтрийте го.

    Метод 2: Използване на добавки за сигурност на WordPress. Например, . Този плъгин има страхотна функция, сканира файловете на сайта за наличие на код на други хора и плъгинът се справя перфектно с тази задача.

    Метод 3. Ако имате разумна поддръжка на хостинг и ви се струва, че има някой друг на сайта, помолете ги да сканират сайта ви с тяхната антивирусна програма. Техният доклад ще изброява всички заразени файлове. След това отворете тези файлове в текстов редактори премахване на зловреден код.

    Метод 4. Ако можете да работите с SSH достъп до директорията на сайта, давайте, той има собствена кухня.

    важно! Без значение как търсите злонамерен код, преди да търсите и след това да изтриете кода, затворете достъпа до файловете на сайта (включете режима на поддръжка). Не забравяйте за кодовете, които сами се възстановяват, когато бъдат изтрити.

    Търсете злонамерени кодове с помощта на функцията eval

    В PHP има такава функция, наречена eval. Позволява ви да изпълните всеки код на неговия ред. Освен това кодът може да бъде криптиран. Именно поради кодирането злонамереният код изглежда като набор от букви и символи. Две популярни кодировки са:

  • Base64;
  • Гниене13.
  • Съответно в тези кодировки функцията eval изглежда така:

    • eval(base64_decode(...))
    • eval (str_rot13 (...)) //във вътрешни кавички, дълги, неясни набори от букви и символи..

    Алгоритъмът за търсене на зловреден код с помощта на функцията eval е следният (работим от административния панел):

    • отидете в редактора на сайта (Външен вид→Редактор).
    • копирайте файла functions.php.
    • отворете го в текстов редактор (например Notepad++) и потърсете думата: eval.
    • Ако го намерите, не бързайте да изтриете нищо. Трябва да разберете какво „иска“ да бъде изпълнена тази функция. За да се разбере това, кодът трябва да бъде декодиран. За декодиране има онлайн инструменти, наречени декодери.
    Декодери/Кодери

    Декодерите работят просто. Копирате кода, който искате да дешифрирате, поставяте го в полето за декодер и декодирате.

    По време на писането не намерих нито един криптиран код в WordPress. Намерих кода от уебсайта на Joomla. По принцип няма разлика в разбирането на декодирането. Да погледнем снимката.

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

    В заключение бих искал да отбележа, за да не получа вирус на сайта:

    • Зловреден код в WordPress често идва с теми и добавки. Затова не инсталирайте шаблони и добавки от „леви“, непроверени ресурси, а ако го направите, проверете ги внимателно за наличие на връзки и изпълнителни функции на PHP. След като инсталирате плъгини и теми от „незаконни“ ресурси, проверете сайта с антивирусен софтуер.
    • Не забравяйте да правите периодични архиви и да извършвате други.
    Злонамерен JavaScript

    Моето мнение, което е, че е по-лесно и по-ефективно да се защитите срещу инжектирани злонамерени скриптове на браузъра (съхранени XSS атаки) с помощта на инструменти на браузъра, беше изразено по-рано: . Защитата на браузъра срещу JavaScript, която се състои в добавяне на филтриращ код към html страниците на уебсайта, се предполага, че е надеждна; наличието на такава защита обаче не премахва необходимостта от използване на сървърен филтър. За същите XSS атаки можете да организирате допълнителна линия на защита на сървъра. Трябва също да помним за възможността нападател да въведе не базирани на браузър, а сървърни скриптове (php) в HTML съобщение, изпратено от сайт, което браузърът няма да може да разпознае.

    Атакуващият скрипт, независимо дали е базиран на браузър или сървър, е програма; човек трябва да мисли, че програмата винаги ще има някои символични разлики от „чистия“ html. Нека се опитаме да намерим такива разлики и да ги използваме за изграждане на HTML филтър на сървъра. По-долу са дадени примери за злонамерен JavaScript.

    XSS:

    Малко текст


    Малко текст

    Криптиран XSS:

    Малко текст


    Малко текст

    Браузърите възстановяват текст от символни примитиви, намиращи се не само в html контейнери (между отварящите и затварящите тагове), но и в самите тагове (между< и >). URL кодирането е разрешено в http адреси. Това затруднява разпознаването на зловреден код от страна на сървъра, тъй като една и съща последователност от знаци може да бъде представена по различни начини.

    XSS червеи:

    "+innerHTML.slice(action= (method="post")+".php",155)))">





    alert("xss");with(new XMLHttpRequest)open("POST","post.php"),send("content="+_.outerHTML)

    Горните XSS червеи са само малка част от многото изпратени на състезанието на Робърт Хансен (известен още като RSnake) през януари 2008 г. за най-кратък злонамерен JavaScript червей (резултати от конкурса).

    Признаци на XSS атаки

    XSS скриптът е програма, която има достъп до DOM (Document Object Model) обекти и техните методи. В противен случай е малко вероятно да бъде вредно по някакъв начин. Например JavaScript низ
    onckick="var a = "xss""
    не засяга обектния модел на документа, така че дори ако е вграден в html таг, такъв низ е безвреден. Само чрез манипулиране на обекти на HTML документ и техните методи хакерът може да причини значителна вреда на даден сайт. Например линията
    onmousemove="document.getElementsByTagName("body").innerHTML="XSS""
    вече замества съдържанието на страницата.

    Знак за достъп до DOM методи са скоби, както и точки вляво от знака за равенство. Скобите също могат да се използват в html за задаване на цвят във формата rgb(), но цветовете на шрифта и фона в html се задават поне по още три начина. Следователно, скобите могат да бъдат пожертвани, без да се компрометира изразителността на html текста. Необходимо е да се приеме като правило, че скобите са вътре в тага (т.е. между< и >) - това е много опасно, ако получим съобщение от потребител на сървъра, това съобщение съдържа скоби в етикетите, тогава най-подходящото нещо, което трябва да направим, е да блокираме такова съобщение.

    Точката може да се съдържа в html тагове: при посочване на адреса на връзката (таг ); когато задавате размера на html елементите (style="height:1.5in; width:2.5in;" ). Но символни последователности на формата
    буквена точка е равна на
    не може да бъде в html тагове. Ако посочената последователност присъства в html таг, съобщението от потребителя най-вероятно съдържа скрипт и трябва да бъде блокирано.

    Друг очевиден знак за опасност е символът "+" вътре в етикета. Няма такова нещо в html без скриптове. Ако намерим плюсове в етикетите, безмилостно блокираме съобщението.

    За криптиране със символни примитиви вътре в html таговете, добронамерен потребител на сайта добавя коментар, използвайки визуален редактор, никога няма да тича. Използването на символни примитиви в таговете не предоставя никакви предимства под формата на допълнителни изразни средства, а само изисква допълнително време за писане. В повечето случаи човек би си помислил, че един добронамерен потребител дори не знае, че в HTML има определени символни примитиви. Оттук и правилото: амперсанд в таг е доказателство за атака срещу сайта. Съответно, ако видим това, блокираме съобщението.

    Подобно правило трябва да се приеме по отношение на символа "%", който може да се използва при кодиране на url. Процентите обаче се използват и в „чистия“ html за задаване на относителните размери на елементите. Опасни комбинации са тези, при които знакът "%" е непосредствено последван от буква или цифра.

    Неутрализиране на сървърни скриптове

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

    PHP филтър за HTML съобщения

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

    // запомняне на дължината на съобщението $lenmessage = strlen($message); // изрязване на етикета за коментар $message = preg_replace("//", "", $message); // изрязва всеки таг, в който атрибутът "src" се отнася до външен ресурс $message = preg_replace("/]+?src[\w\W]+\/\/[^>]+?>/i" , " ", $message); // изрязва всеки таг, който съдържа произволен знак с изключение на: - a-z 0-9 / . : ; " = % # интервал $message = preg_replace("/]+[^->a-z0-9\/\.\:\;\"\=\%\#\s]+[^>]+?> /i", "", $message); // изрязва всеки таг, който съдържа последователността ". a-z =" $message = preg_replace("/]+?\.+?\=[^>]+?>/i", "", $message); // изрязва всеки таг, който съдържа последователността "% a-z" или "% 0-9" $message = preg_replace("/]+?\%+?[^>]+?>/i", "", $ съобщение); // изрязва всеки таг, който съдържа последователността "script" или "js:" $message = preg_replace("/]*?script[^>]*?>/i", "", $message); $message = preg_replace("/]*?js:[^>]*?>/i", "", $message); // изрязва всеки таг, който започва със знак, различен от "a-z" или "/" $message = preg_replace("/]*?>/i", "", $message); // проверка: ако съобщението е съкратено, тогава прекратете програмата $lenmessage2 = strlen($message); if ($lenmessage != $lenmessage2) ( print "Съобщението не може да бъде добавено"; exit; ) // извършва замяна от край до край на опасни знаци със съответните им примитиви $message = str_replace("$", "$" , $съобщение); $message = str_replace("_", "_", $message); $message = str_replace(".", ".", $message); $message = str_replace(chr(92), "\", $message); // \ $message = str_replace("(", "(", $message); $message = str_replace()", ")", $message); $message = str_replace("[", "[", $message); $message = str_replace("]", "]", $message); $message = str_replace("(", "(", $message); $message = str_replace()", ")", $message); $message = str_replace("?", "?", $message); // сега съобщението е проверено, скриптовете в него са неутрализирани

    Трябва да се отбележи, че филтърът не премахва сдвоени тагове. Да кажем, че имаме
    Натисни тук!
    Филтърът ще изреже само , но сдвоеният (затварящ) етикет ще остане. Ако изпращате съобщения, които съдържат етикети без съответстващи двойки към браузъра, може да изпитате проблеми под формата на „изкривяване“ на сайта. Не е известно към кой отварящ таг браузърът ще съпостави оставащия несдвоен затварящ таг. Следователно, както и от съображения за сигурност, съобщенията, в които нещо е изрязано от филтъра, изобщо не трябва да се изпращат до браузъра. По-добре е да отпечатате нещо като "Съобщението не може да бъде добавено" и да излезете от програмата.

    Очаква се съобщението да бъде записано във файл (а не в база данни).

    Дискусия

    Ще бъда благодарен за критики. Пишете на форума за поддръжка, в раздела

    
    Връх