Маскарад на знаци: аспекти на сигурността, ориентирани към Unicode. Вместо файлове "йероглифи" (неразбираеми знаци) на USB флаш устройство Windows в различни приложения на Windows

КракозябриКоя е интересна дума? Тази дума обикновено се използва от руски потребители за обозначаване на неправилно / неправилно показване (кодиране) на знаци в програмите или самата операционна система.
Защо това се случва? Няма да намерите нито един отговор. Това може да се дължи на триковете на нашите "любими" вируси, може да се дължи на повреда на операционната система Windows (например, прекъсна електричество и компютърът се изключи), може би програмата създаде конфликт с друга или операционна система и всичко "излетя". Като цяло причините могат да бъдат много, а най-интересната е „Просто взе и се счупи така“.
Четем статията и откриваме как да коригираме проблема с кодирането в програмите и операционната система Windows, тъй като се случи.

За тези, които все още не разбират какво имам предвид, ето няколко:

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

Няколко "неща" отговарят за показването на кодирането (шрифта) в Windows - това са езикът, регистърът и файловете на самата ОС. Сега ще ги проверим поотделно и точка по точка.

Как да премахнете и коригирате krakozyabry вместо руски (руски букви) в програма или Windows.

1. Проверка инсталиран езикза програми, които не поддържат Unicode. Може би се е изгубил от теб.

И така, нека да вървим по пътя: Контролен панел - Регионални и езикови опции - раздел Разширени
Там гледаме езикът да е руски.

6. Последната точка, в която ви давам файл, който ми помогна да оправя всичко веднъж и затова го оставих за спомен. Ето и архива:

Вътре има два файла: krakozbroff.cmd и krakozbroff.reg

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

И накрая, няколко съвета:
1) Ако работите с системния регистър, не забравяйте да направите резервно копие ( архивиране), в случай че нещо се обърка.
2) Препоръчително е да поставите отметка на първия елемент след всеки елемент.

Това е всичко. Сега знаете как да коригирате премахване / коригиране на Krakozyabry (квадрати, йероглифи, удивителни и въпросителни знаци) в програма или Windows.

Внимание!!! Пригответе се, статията ще е дълга. Може да се уморите и да заспите, така че седнете удобно, вземете чаша кафе и нека започваме.


Изучаването на китайски йероглифи е важна част от изучаването на самия език. Има много начини, средства и идеи как да ги изучаваме. Тази статия ще обсъди някои от тях. Различните хора, в зависимост от целите си, ги учат по различен начин.
Например, някой просто иска да знае определен брой знаци. Други искат да прочетат текста с йероглифи. Други искат не само да четат, но и да могат да пишат йероглифи. И тогава има такива, които ще записват на китайски или ще пишат текстове. Отново пишете на ръка, защото писането им на компютър е много по-лесно.
Струва си да се отбележи, че съвременната заетост на човек не позволява да се потопите напълно в учебния процес без разсейване. Особено трудно е за тези, които изучават езика сами и "когато е възможно". Струва си да изберете начин за индивидуално изучаване на йероглифи. Тези, които са ограничени във времето, вероятно искат да намерят удобно приложение за своето устройство, за да „похапват гранита на науката“ в свободното си време. Е, за тези, които учат езика, как трябва всичко да е специалност, но кой не иска да съкрати времето за придобиване на умения?
Ще добавя, че изучаването на йероглиф може да означава различни неща за различните хора. В пълния смисъл да научите йероглиф означава да знаете неговото произношение, правопис и значение. И така, по какви начини можете да развиете всички тези умения и да овладеете китайски йероглифи? Да започнем с хартиен носител, после с електронен.

1. Предписване на йероглифи.

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

1. Шаблон. Може да изглежда различно, но същността е същата. Върху текста е насложена паус, върху която са изписани йероглифи. Проблемът е, че в такъв шаблон няма произношение на йероглифи, т.е. обучават се само разпознаване на познати и калиграфия.

2. Шаблон. Предписването става според определената последователност от признаци. Значението на йероглифите също е дадено. Произношението остава зад кадър.

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

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

3. Карти.

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

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

1.Флаш карти.

Хората разбраха, че няколко хиляди йероглифа са голям обем карти. Цяла кутия! Възможно е и в в електронен форматнаправи ги. Създадени са всякакви програми, които различни платформивъзпроизведете тези карти.

Всеки, който се интересува от този метод, трябва да се запознае с програмата. Също и за любител. Разпределеното повторение на картини също е свързано с визуалната памет. Не всеки е еднакво добър в това. Но не само японски и китайски могат да бъдат преподавани. Освен това приложението е достъпно за различни платформи.

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

2. Символни процесори.

Веднъж се опитах да се запозная с йероглифите с помощта на програмата NJStar. Не помогна много, но някой може да го намери за полезен на компютъра си. Тук . В тази програма можете да въвеждате йероглифи с мишката.

3. Онлайн преводачи.

Google Translate има функция за въвеждане на сензорен екран. Там можете да пишете йероглифи с пръст направо на мобилното си устройство. Изисква се интернет. Няма ясна програма за запаметяване, а само способността да пишете не на хартия. Същото важи и за въвеждането с мишката на йероглифи в интернет речници като www.bkrs.info. До лентата за търсене има бутон за ръчно въвеждане, понякога не се вижда поради темата около линията, но определено е отдясно. Можете да въведете йероглиф с мишката и да гледате значението му, понякога да слушате произношението. Елиминира писането върху хартия.

4. Други програми.

Друг софтуер може да се намери в интернет. Не съм тествал всичко, така че не мога да опиша много. Но искам да кажа няколко думи за МАО системата. Не ми хареса подходът за запаметяване на йероглифи, но все пак реших да го доведа в тази статия, тъй като има приложение "MAOcard". Да, и някой може да оцени тази система над мен. Линк...

Продължаваме...

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

Бих искал специално да спомена приложението за Android платформата "Chineskill". Развива се и според мен съчетава много предимства. Изучаването на йероглифи върви ръка за ръка с изучаването на речника и граматиката. Пишете и произнасяйте думи трябва. Понякога на ръка, с пръст. Може би това е, което ви трябва...

Друго приложение, което препоръчвам на учащите китайски и, вконкретно, йероглифи, е приложението "Китайски писател". Вече го направих Кратко описаниетова приложение. Но ще кажа, че дори и с няколко неудобства, като тикер в долната част на екрана с информация за йероглифа, приложението е отлично. Можете да разглеждате йероглифи, да се научите как да ги пишете, да се тествате в играта и много други. Според мен трябва да имате това в устройството си ... Има платени и безплатни версии.

Заключение.

В заключение ще кажа, че не бих могъл да изброя всичко, което беше на моя смартфон и таблет. опитах различни програмино уви, никой не е съвършен. Или може би още не съм го намерил. Но това, което изброих по-горе, си струва да опитате. По един или друг начин всичко това е само средство за въвеждане на йероглифи в паметта ви. Но как ще ги възприеме, дали ще иска да ги върне после – това е друг въпрос. Ето защо, в допълнение към изучаването на самите йероглифи, препоръчвам да спите достатъчно и да тренирате паметта си. Благодаря ви, че прочетохте до края, сега вашето разбиране за проблема вероятно е по-широко.

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

Както се казва, "инициативата е наказуема" и както винаги за всичко са виновни американците.

И беше така. В зората на разцвета на компютърната индустрия и разпространението на Интернет имаше нужда от универсална система за представяне на символи. А през 60-те години на миналия век се появява ASCII - "Американски стандартен код за обмен на информация" (амер. Стандартен кодза обмен на информация), познатото 7-битово кодиране на знаци. Последният осми неизползван бит беше оставен като контролен бит за персонализиране на ASCII таблицата, за да отговаря на нуждите на всеки компютърен клиент в определен регион. Такъв бит позволява ASCII таблицата да бъде разширена, за да използва свои собствени знаци за всеки език. Компютрите бяха доставени в много страни, където вече използваха собствена, модифицирана маса. Но по-късно тази функция се превърна в главоболие, тъй като обменът на данни между компютрите стана доста проблематичен. Нов 8-битов кодови странициса несъвместими един с друг - един и същи код може да означава няколко различни знака. За да се реши този проблем, ISO ("Международна организация по стандартизация", Международна организация по стандартизация) предложи нова маса, а именно "ISO 8859".

По-късно този стандарт е преименуван на UCS ("Universal Character Set", универсален набор от знаци). Въпреки това, по времето, когато UCS беше пуснат за първи път, Unicode беше пристигнал. Но тъй като целите и задачите на двата стандарта съвпадат, беше решено да се обединят усилията. Е, Unicode се е заел с трудната задача да даде на всеки знак уникално обозначение. В момента последната версия на Unicode е 5.2.

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

Интензивен курс по unicode

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

И така, какво е Unicode? Казано по-просто, това е начин да представите всеки знак под формата на специфичен код за всички езици по света. последна версияСтандартът съдържа около 1 100 000 кода, които заемат пространството от U+0000 до U+10FFFF. Но внимавайте тук! Unicode стриктно дефинира какво е код на символ и как този код ще бъде представен в паметта. Кодовете на символи (да речем 0041 за знака "A") нямат никакво значение, но има логика за представяне на тези кодове като байтове, кодировките правят това. Unicode Consortium предлага следните типове кодировки, наречени UTF (Unicode Transformation Formats). И ето ги:

• UTF-7: Това кодиране не се препоръчва от съображения за сигурност и съвместимост. Описано в RFC 2152. Не е част от Unicode, но е въведено от този консорциум.
• UTF-8: Най-често срещаното кодиране в мрежата. Това е променлива с ширина от 1 до 4 байта. Обратно съвместим с протоколи и програми, използващи ASCII. Заема диапазона U+0000 до U+007F.
• UTF-16: Използва променлива ширина от 2 до 4 байта. Най-честата употреба е 2 байта. UCS-2 е същото кодиране, само с фиксирана ширина от 2 байта и ограничено до BMP ограничения.
• UTF-32: Използва фиксирана ширина от 4 байта, т.е. 32 бита. Използват се обаче само 21 бита, останалите 11 са запълнени с нули. Въпреки че това кодиране е тромаво по отношение на пространството, то се счита за най-ефективно по отношение на скоростта поради 32-битовото адресиране в съвременните компютри.

Най-близкият еквивалент на UTF-32 е кодирането UCS-4, но днес се използва по-рядко.

Въпреки факта, че UTF-8 и UTF-32 могат да представляват малко повече от два милиарда знака, беше решено да се ограничи до милион и опашка - в името на съвместимостта с UTF-16. Цялото кодово пространство е групирано в 17 равнини, всяка с 65536 символа. Най-често използваните символи са разположени в нулевата базова равнина. Наричан BMP - Basic MultiPlane.
Поток от данни в кодировките UTF-16 и UTF-32 може да бъде представен по два начина - малък ред и малък ред, наречени съответно UTF-16LE/UTF-32LE, UTF16BE/UTF-32BE. Както се досещате, LE е с малък ред, а BE е с голям. Но човек трябва по някакъв начин да може да прави разлика между тези поръчки. За да направите това, използвайте знака за ред на байтове U + FEFF, в английската версия - BOM, "Byte Order Mask". Тази BOM може да се появи и в UTF-8, но не означава нищо там.

В името на обратната съвместимост Unicode трябваше да побере знаци от съществуващи кодировки. Но тук възниква друг проблем - има много варианти на еднакви знаци, които трябва да бъдат обработени по някакъв начин. Следователно е необходима така наречената "нормализация", след която вече е възможно да се сравнят два низа. Общо има 4 форми на нормализация:

• Форма за нормализиране D (NFD): канонично разлагане.
• Форма за нормализиране C (NFC): канонична декомпозиция + канонична композиция.
• Форма за нормализиране KD (NFKD): съвместимо разлагане.
• Форма за нормализиране KC (NFKC): съвместимо разлагане + каноничен състав.

Сега повече за тези странни думи.

Unicode дефинира два вида равенство на низове - канонично и съвместимо.

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

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

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

зрителна измама

Със сигурност сте чували за IP/ARP/DNS spoofing и имате добра представа какво представлява. Но има и така нареченото „визуално подправяне“ – това е същият стар метод, който фишърите активно използват, за да измамят жертвите. В такива случаи се използва използването на подобни букви, като "o" и "0", "5" и "s". Това е най-често срещаният и най-простият вариант и е по-лесен за забелязване. Пример за това е фишинг атаката на PayPal от 2000 г., която дори се споменава на страниците на www.unicode.org. Това обаче няма голямо значение за нашата тема за Unicode.

За по-напредналите момчета на хоризонта се появи Unicode или по-скоро IDN, което е съкращение от „Интернационализирани имена на домейни“ (Internationalized Domain Names). IDN позволява използването на знаци от националната азбука в имената на домейни. Регистраторите на имена на домейни го позиционират като удобно нещо, казват те, набиране Име на домейнна собствения си език! Това удобство обаче е много съмнително. Е, добре, маркетингът не е нашата тема. Но представете си какво пространство е това за фишъри, SEO специалисти, киберсквотери и други зли духове. Говоря за ефект, наречен IDN spoofing. Тази атака принадлежи към категорията на визуалния спуфинг, в англоезичната литература се нарича още "хомографска атака", тоест атаки с помощта на хомографи (думи, които са еднакви по правопис).

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

IDNA2003 беше изобретен като вид панацея, но още тази година, 2010 г., IDNA2008 влезе в сила. Новият протокол трябваше да реши много от проблемите на младия IDNA2003, но въведе нови възможности за измамни атаки. Отново възникват проблеми със съвместимостта – в някои случаи един и същи адрес в различни браузъри може да води до различни сървъри. Факт е, че Punycode може да се конвертира по различни начини различни браузъри- всичко ще зависи от това какви стандартни спецификации се поддържат.
Проблемът със зрителната измама не свършва дотук. Unicode също идва в услуга на спамерите. Говорим за филтри за нежелана поща - разпространителите на нежелана поща пускат оригиналните букви през Unicode obfuscator, който търси подобни знаци от различни национални азбуки, използвайки така наречения UC-Simlist („Unicode Similarity List“, списък с подобни Unicode знаци). И това е! Антиспам филтърът се проваля и вече не може да разпознае нещо смислено в такава бъркотия от знаци, но потребителят е напълно способен да прочете текста. Не отричам, че е намерено решение за подобен проблем, но спамърите са начело. Е, и още нещо от същата поредица от атаки. Сигурни ли сте, че отваряте a текстов файл, а вие не се занимавате с двоичен файл?

На фигурата, както можете да видите, имаме файл, наречен evilexe. текст. Но е фалшив! Файлът всъщност се нарича eviltxt.exe. Питате, какъв е този боклук в скоби? И това, U + 202E или RIGHT-TO-LEFT OVERRIDE, така нареченият Bidi (от думата двупосочен) е Unicode алгоритъм за поддържане на езици като арабски, иврит и други. Последният в края на краищата пише отдясно наляво. След вмъкване на Unicode знака RLO, всичко, което идва след RLO, ще видим в обратен ред. Като пример този методот реалния живот, мога да цитирам спуфинг атака в Mozilla Firfox - cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3376 .

Байпас на филтъра - Стъпка #1

Вече е известно днес, че UTF-8 не-кратките форми не могат да бъдат обработени, тъй като това е потенциална уязвимост. Разработчиците на PHP обаче не могат да бъдат аргументирани с това. Да видим каква е тази грешка. Може би си спомняте за грешното филтриране и utf8_decode(). Тук ще разгледаме този случай по-подробно. Така че имаме този PHP код:

// ... етап 1
$id = mysql_real_escape_string($_GET["id"]);
// ... стъпка 2
$id = utf8_decode($id);
// ... стъпка 3
mysql_query("ИЗБЕРЕТЕ "име" ОТ "deadbeef"
WHERE "id"="$id"");

На пръв поглед тук всичко е точно. Някак, но не съвсем - тук има SQL инжекция. Нека си представим, че сме предали следния низ:

/index.php?id=%c0%a7 ИЛИ 1=1/*

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

Ако конвертирате %c0 и %a7 в техните двоични стойности, получавате съответно 11000000 и 10100111. Апострофът има двоична стойност 00100111. Сега погледнете UTF-8 таблицата за кодиране.

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

След това трябва да вземете такъв първи октет, така че първите три бита да са 110, което казва на декодера, че низът е по-широк от 1 байт. И с втория октет не е по-трудно - ще заменим първите две нули с 1 и 0. Воала! Имаме 11000000 10100111, което е %c0%a7.

Може би тази уязвимост не се среща на всяка стъпка, но трябва да се има предвид, че ако функциите са разположени в този ред, тогава нито addslashes(), нито mysql_real_escape_string(), нито magic_quotes_qpc ще помогнат. И така можете да скриете не само апострофите, но и много други знаци. Особено след като не само PHP обработва UTF-8 низовете неправилно. Като се имат предвид горните фактори, обхватът на атака е значително разширен.

Байпас на филтъра - Етап #2

Уязвимостта на този тип се крие в напълно законното маскиране на отровен низ под прикритието на различно кодиране. Вижте следния код:

/**
* UTF-7 XSS PoC
*/
header("Content-Type: text/html;
charset=UTF-7");
$str = "";
$str = mb_convert_encoding($str,
"UTF-7");
ехо htmlentities($str);

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

ADw-скрипт+AD4-предупреждение("UTF-7 XSS")+ADsAPA-/скрипт+AD4

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

Ако се съмнявате, дайте грешка и спрете да работите, а за да избегнете проблеми, е правилно да принудите изхода на данните към UTF-8 кодиране. От практиката е известен случай на атака срещу Google, при която хакер успява да извърши XSS атака чрез ръчна промяна на кодирането на UTF-7.

Първоначалният източник на атака срещу Google чрез този метод е sla.ckers.org/forum/read.php?3,3109.

Байпас на филтъра - Стъпка #3

Unicode предупреждава: Прекомерната употреба на символи вреди на вашата сигурност. Нека поговорим за такъв ефект като "изяждане на символи". Причината за успешна атака може да бъде декодер, който не работи правилно: като например в PHP. Стандартът пише, че ако по време на преобразуването се срещне ляв знак (неправилно оформен), тогава е препоръчително да замените съмнителните знаци с въпросителни знаци, интервал с U+FFFD, да спрете анализирането и т.н., но не изтривайте следващите знаци . Ако все още трябва да изтриете знак, тогава трябва да го направите внимателно.

Грешката е, че PHP ще дъвче грешния знак UTF-8 заедно със следващия. И това вече може да доведе до заобикаляне на филтъра с последващо изпълнение на JavaScript код или до SQL инжекция.

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

// ... много код, филтриране ...
$name = $_GET["име"];
$link = $_GET["link"];
$изображение = " src="http://$link" />";
ехо utf8_decode($image);
И сега изпращаме следната заявка:
/?name=xxx%f6&link=%20
src=javascript:onerror=alert(/
хсс/)//

След всички трансформации PHP ще ни върне това:

Какво стана? Променливата $name получи невалиден UTF-8 знак 0xF6, който, след като беше преобразуван в utf8_decode(), изяде 2 следващи знака, включително затварящата кавичка. http:// мъничето беше игнорирано от браузъра и следният JavaScript код беше изпълнен успешно. Тествах тази атака в Opera, но нищо не ни пречи да я направим универсална, това е просто добър пример как защитата може да бъде заобиколена в някои случаи.

От тази поредица от атаки, но без странното поведение на PHP функциите, можем да дадем още един пример за заобикаляне на филтри. Нека си представим, че WAF/IPS не пропуска редове от черния списък, но последваща обработка на редове от декодера премахва символи, чужди на ASCII обхвата. Тогава следният код ще влезе свободно в декодера:

предупреждение\uFEFFt("XSS")

И вече без \uFEFF ще бъде там, където нападателят би искал да го види. Можете да коригирате този проблем просто като обмислите логиката на обработка на низове - както винаги, филтърът трябва да работи с данните, които са на последния етап от обработката му. Между другото, ако си спомняте, тогава \uFEFF е спецификацията, за която вече писах. FireFox беше засегнат от тази уязвимост - mozilla.org/security/announce/2008/mfsa2008-43.html

Байпас на филтъра - Етап #4

Можем да кажем, че типът атака, която ще бъде обсъдена сега, е визуален спуфинг, атака за всички видове IDS / IPS, WAF и други филтри. Говоря за така наречения Unicode алгоритъм за "най-добро съпоставяне". Този метод за „най-добро прилягане“ е измислен за случаите, когато липсва конкретен знак при преобразуване от едно кодиране в друго, но трябва да се вмъкне нещо. Тогава се търси такава, която визуално да прилича на желаната.

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

Да кажем, че символът за безкрайност може да се преобразува в осмица. Те изглеждат подобни, но имат напълно различни цели. Или друг пример - знакът U + 2032 се преобразува в цитат. Мисля, че разбирате какво означава.

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

Разработчиците са се погрижили да не пропуснат този ред: ?moz?binding: url(http://nottrusted.com/gotcha.xml#xss)
Въпреки това, Крис успя да заобиколи тази защита, като замени първия знак с минус, чийто код е U+2212. След като най-подходящият алгоритъм проработи, минусът беше заменен със знак с код U+002D, знак, който позволи на CSS стила да работи, като по този начин отвори възможности за активна XSS атака. Струва си да избягвате всяка магия, но има много от нея. До последния момент е невъзможно да се предвиди до какво ще доведе прилагането на този алгоритъм. В най-добрия случай може да има загуба на знаци, в най-лошия случай изпълнение на JavaScript код, достъп до произволни файлове, SQL инжекция.

Препълване на буфера

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

1. Низовете могат да се разширяват при промяна на регистъра - от горен към малък или обратно.
2. Формата за нормализиране на NFC не винаги е „колективна“, някои символи могат да бъдат анализирани.
3. При преобразуване на знаци от един в друг, текстът може да се увеличи отново. Тоест колко се разширява низът зависи от самите данни и кодирането.

По принцип, ако знаете какво е препълване на буфера, тогава всичко е както винаги. Почти :). Просто, ако говорим за Unicode низове, тогава знаците най-често ще бъдат подплатени с нули. За пример ще дам три реда.

Редовна линия:

В ASCII кодиране:

В Unicode кодиране:

\x41\x00\x42\x00\x43\x00

Няма да има нулеви байтове, когато изходните низове са извън диапазона на ASCII низовете, тъй като те заемат пълния диапазон. Както знаете, нулевите байтове са пречка за успешната работа на shellcode. Ето защо дълго време се смяташе, че Unicode атаките са невъзможни. Този мит обаче беше разрушен от Крис Анли, той излезе с така наречения "венециански метод", който ви позволява да замените nullbytes с други знаци. Но тази тема заслужава отделна статия, а вече има доста добри публикации - просто потърсете в Google "venetian exploit". Можете също така да прегледате статия 45 от специалния брой на списанието Hacker - "Unicode-Buffer Overflows", там има добра информация за писането на Unicode shellcode.

Други радости

Да, това не е краят на уязвимостите, свързани с Unicode. Описах само онези, които попадат в основните, добре познати класификации. Има и други проблеми със сигурността, от досадни грешки до истински пробиви. Това могат да бъдат атаки от визуален характер, например, ако системата за регистрация неправилно обработва данните за влизане на потребителя, тогава можете да създадете акаунт от знаци, които са визуално неразличими от името на жертвата, като по този начин улеснявате фишинг или атаки чрез социално инженерство. И може би дори по-лошо - системата за авторизация (да не се бърка с удостоверяване) дава права с повишени привилегии, без да прави разлика между набора от символи в логина на нападателя и жертвата.

Ако слезете на ниво приложения или операционни системи, тогава грешките се проявяват в неправилно изградени алгоритми, свързани с преобразуването - лоша нормализация, прекалено дълъг UTF-8, изтриване и изяждане на знаци, неправилно преобразуване на знаци и др. Всичко това води до най-широк набор от атаки – от XSS до дистанционно изпълнение на код.

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

щастлив край?!

Така че, както можете да си представите, проблемите с Unicode все още са проблем номер едно и причина за всякакви атаки. И има само един корен на злото - неразбирането или игнорирането на стандарта. Разбира се, дори и най-известните доставчици грешат с това, но това не трябва да се отпуска. Напротив, струва си да се замислим за мащаба на проблема. Вече успяхте да се убедите, че Unicode е доста коварен и очаквайте уловка, ако се откажете и не погледнете стандарта навреме. Между другото, стандартът се актуализира редовно и затова не трябва да разчитате на древни книги или статии - остарялата информация е по-лоша от липсата й. Но се надявам, че тази статия не ви е оставила безразлични към проблема.

Punycode - скелетът на съвместимостта

DNS не позволява използването на други символи, различни от латински, цифри и тирета в имената на домейни; за DNS се използва "скъсена" ASCII таблица.

Следователно, в името на обратната съвместимост, такъв многоезичен Unicode домейн трябва да бъде преобразуван в стария формат. Тази задача се поема от браузъра на потребителя. След трансформации домейнът се превръща в набор от знаци с префикса "xn--" или, както се нарича още, "Punycode". Например домейнът „hacker.ru“, след като е преобразуван в Punycode, изглежда така: „xn--80akozv.ru“. Прочетете повече за Punycode в RFC 3492.

инфо

IDNA - IDN в приложенията (IDN в приложенията) е протокол, който решава много проблеми, като позволява използването на многоезични имена на домейни в приложенията. Изобретен е от IETF, в момента има само RFC на старата версия на IDNA2003 - RFC 3490. Новият стандарт е несъвместим с предишния.

Връзки

• unicode.org е официалният уебсайт на консорциума Unicode. Всички отговори по болна тема можете да намерите тук.
• macchiato.com/main - много полезни онлайн инструменти за работа с Unicode.
• fiddler2.com/fiddler2 - Fiddler, мощен, разширяем HTTP прокси.
• websecuritytool.codeplex.com - плъгин Fiddler за пасивен анализ на HTTP трафик.
• lookout.net - Сайтът на Крис Уебър за Unicode, уеб и софтуерен одит.
• sirdarckcat.blogspot.com/2009/10/couple-of-unicodeissueson-php-and.html - публикация в блог на sirdarckat за PHP и Unicode.
• googleblog.blogspot.com/2010/01/unicode-nearing-50of-web.html – Публикация в блог на Google за общата тенденция на нарастване на използването на Unicode.

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

Флаш устройството беше отворено със стандартни инструменти на Windows и, уви, това не даде положителни резултати.

Всички файлове на флашката са изчезнали, с изключение на един. Появиха се няколко файла със странни имена: &, t, n-& и т.н.

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

Въпреки че файловете са изчезнали, мястото е заето. В конкретен случай са заети 817 MB

Първата мисъл за причината за случилото се е ефектът от вируса. По-рано, когато се използва вирусът, се използва файловият мениджър FAR manager, който като правило вижда всички файлове (скрити и системни). Този път обаче мениджърът на FAR видя само това, което видя стандартният Windows Explorer ...

"Изгубените" файлове не могат да се видят дори от FAR manager

Тъй като Windows не вижда липсващите файлове, той не изпълнява трика за промяна на файловите атрибути с помощта на командния ред и attrib -S -H /S /D.

Какво ще види Linux?

В тази ситуация като експеримент реших да използвам базирана на Linux операционна система. В конкретен случай е използван диск с операционна система Ubuntu 10.04.3 (повече за Ubuntu и къде да го изтеглите).

важно!Няма нужда да инсталирате Ubuntu на компютъра - просто стартирайте от компактдиска, точно както се прави с .

След стартиране на Ubuntu ще се появи работният плот и можете да работите с папки и файлове по абсолютно същия начин, както правите в Windows.

Както се очакваше, Ubuntu видя повече файлове в сравнение с Windows.

Ubuntu също така показва онези файлове, които не са били видими от Windows (с възможност за кликване)

Освен това, за да не се занимавате с атрибутите на файла, бяха предприети елементарни действия: всички показани файлове бяха избрани и копирани на локалното устройство „D“ (разбира се, можете да копирате файловете на системното устройство „C“).

Сега можете да стартирате Windows отново и да проверите какво се е случило.

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

Уви, проблемът не е решен, тъй като на флаш устройството имаше очевидно повече файлове (съдейки по обема от 817 MB), отколкото успяхме да изтеглим. Поради тази причина нека се опитаме да проверим флаш устройството за грешки.

Отстраняване на проблеми с флаш устройство

За намиране и коригиране на грешки в диска Windows има стандартна помощна програма.

Етап 1.Щракнете с десния бутон върху иконата на флаш устройството и изберете „Свойства“.

Стъпка 2Отидете в раздела „Услуга“ и кликнете върху бутона „Извършване на проверка“.

Стъпка 3Щракваме върху бутона "Стартиране".

След проверка и коригиране на системни грешки ще се появи съответно съобщение.

Съобщение: „Някои грешки са открити и коригирани“

След коригиране на грешките, файловете с йероглифи изчезнаха и в главната директория на флашката се появи скрита папка с име FOUND.000.

В папката FOUND.000 имаше 264 файла с разширение CHK. Файловете с разширение CHK могат да съхраняват фрагменти от файлове от различни типове, извлечени от твърди дискове и флаш устройства с помощта на помощните програми ScanDisk или CHKDISK.

Ако всички файлове на флаш устройството са от един и същи тип, например документи на Word с разширение docx, тогава във файловия мениджър на Total Commander изберете всички файлове и натиснете клавишната комбинация Ctrl + M (Файлове - Преименуване на група) . Посочете кое разширение да търсите и на какво да го промените.

В конкретния случай знаех само, че на флашката има Word документи и файлове с Power Point презентации. Много е проблематично да се променят разширенията с помощта на научния метод, така че е по-добре да използвате специализирани програми - те сами ще определят какъв тип данни се съхраняват във файла. Една такава програма е безплатна помощна програма, която не изисква инсталиране на компютър.

Посочете изходната папка (изхвърлих CHK файловете на твърдия диск). След това избрах опцията, в която файловете с различни разширения ще бъдат поставени в различни папки.

Остава да натиснете "Старт"

В резултат на помощната програма се появиха три папки:

1. DOC - с Word документи;
2. JPG - със снимки;
3. ZIP - с архиви.

Съдържанието на осем файла остана неразпознато. Основната задача обаче беше изпълнена, документите и снимките на Word бяха възстановени.

Недостатъкът е, че не беше възможно да се възстановят подобни имена на файлове, така че очевидно трябва да се занимавате с преименуване на документи на Word. Що се отнася до файловете със снимки, имена като FILE0001.jpg, FILE0002.jpg и т.н. също ще работят.