SMTPUTF8, Unicode имейл адреси, рискове за сигурността и съвместимост на практика.
Валидирането на имейл адреси изглежда лесно. Потребителят въвежда имейл адрес, приложението проверява формата му и регистрацията продължава.
Но какво се случва, когато някой се регистрира с müller@example.com?
Наскоро обсъдихме дали нашият процес на регистрация трябва да допуска Unicode символи в локалната част на имейл адресите - частта преди символа @.
На пръв поглед отговорът изглежда прост. Ако даден имейл адрес е разрешен от установените стандарти, защо да го отхвърляме?
Но поддръжката на имейл адрес включва повече от приемането му при регистрация.
Съвместимостта при доставяне на имейли, процесите за удостоверяване, интеграциите с външни услуги и съображенията за сигурност влияят върху това решение.
Какво е SMTPUTF8?
Традиционно в имейл адресите се използват предимно ASCII символи. Разширението SMTPUTF8, определено в RFC 6531, позволява интернационализирани имейл адреси, съдържащи символи извън ASCII.
Това позволява имейл адреси като:
müller@example.comδοκιμή@example.com用户@example.com
Има важна разлика между интернационализираните имена на домейни и Unicode символите в локалната част.
| Имейл адрес | Характеристики | Съвместимост |
|---|---|---|
john@example.com |
Локална част и домейн с ASCII символи | Широка поддръжка |
user@bücher.example |
Домейн с Unicode символи | Може да се използва Punycode кодиране |
müller@example.com |
Локална част с Unicode символи | Изисква SMTPUTF8 |
δοκιμή@example.com |
Локална част на гръцки | Изисква SMTPUTF8 |
Интернационализираните домейни могат да бъдат представени чрез Punycode - кодиране, съвместимо с ASCII.
Този подход обаче не може да се използва за преобразуване на локални части с Unicode символи в еквивалентни имейл адреси с ASCII символи.
За пренасянето на такива адреси е необходима поддръжка на SMTPUTF8.
И точно тук съвместимостта се превръща в предизвикателство.
Проблемът със съвместимостта на AWS SES
Amazon Simple Email Service (AWS SES) се използва широко за транзакционни имейли, включително потвърждения на регистрация, възстановяване на пароли и известия за потребителски профили.
AWS SES обаче не поддържа разширението SMTPUTF8.
Според документацията на услугата имейл адресите трябва да съдържат само 7-битови ASCII символи. Интернационализираните домейни могат да използват Punycode, но локални части с Unicode символи не се поддържат.
Да разгледаме приложение, което приема:
müller@example.com
Приложението може успешно да валидира адреса и да го съхрани в база данни, съвместима с UTF-8.
Но когато се опита да изпрати имейл за потвърждение чрез AWS SES, заявката не може да използва този адрес на получател.
Резултатът е неработещ процес на регистрация.
Приложението приема адрес, който неговата имейл инфраструктура не може да поддържа.
Това показва защо правилата за валидиране трябва да отчитат възможностите на външните зависимости.
Рискове за сигурността: когато различни символи изглеждат еднакво
Съвместимостта не е единственото съображение.
Unicode въвежда допълнителни съображения за сигурност, особено когато визуално сходни символи принадлежат към различни писмености.
Например латинската буква o и кирилската буква о изглеждат почти еднакво в много шрифтове.
Те обаче са различни символи с различни Unicode кодови позиции.
Да разгледаме тези два адреса:
| Имейл адрес | Използван символ | Unicode |
|---|---|---|
support@example.com |
Латинско o |
U+006F |
suppоrt@example.com |
Кирилско о |
U+043E |
Във втория адрес буквата, която изглежда като "o", всъщност е на кирилица.
За човек тези адреси може да изглеждат еднакви.
За компютъра те съдържат различни последователности от символи.
Това създава възможности за хомографски атаки, при които визуално сходни символи се използват за представяне под доверена самоличност.
Потенциалните рискове за сигурността включват:
- Представяне за друг потребител: Нападател, който контролира визуално сходен адрес, може да се опита да се представи за легитимен потребител.
- Объркване между профили: Приложенията, които показват имейл адресите като потребителски идентификатори, може да затруднят разграничаването на визуално сходни профили.
- Грешки при контрола на достъпа: Системи, които разчитат на неправилно проектирани сравнения на низове или на ръчно поддържани списъци с разрешени адреси, може да обработват неправилно визуално сходни адреси.
- Социално инженерство: Визуално сходни адреси могат да заблудят потребители, администратори или екипи за поддръжка.
Тези проблеми не означават, че Unicode адресите по своята същност са злонамерени.
Визуално сходният адрес също не получава автоматично съобщения, предназначени за друга пощенска кутия. Нападателят трябва да контролира адреса, който използва.
Рисковете обаче стават особено важни, когато имейл адресите служат като видими идентификатори или се използват при решения, свързани със сигурността.
RFC 6530 изрично разглежда визуално объркващи символи и хомографски атаки при интернационализирани имейл адреси.
Защо това е важно за регистрацията и удостоверяването
Имейл адресите рядко се използват само при първоначалната регистрация.
Те често стават част от критични процеси в приложението:
- Регистрация и потвърждаване на профили.
- Удостоверяване на потребители и идентифициране на профили.
- Възстановяване на пароли.
- Известия за сигурност.
- Администриране на потребителски профили.
Проблем в който и да е от тези процеси може да създаде затруднения при използването или рискове за сигурността.
Потвърждаването на имейл адрес доказва, че някой може да получава съобщения на него. То не установява дали адресът се отличава визуално от адреса на друг потребител или дали притежателят му е надежден.
Затова приложенията трябва да избягват да вземат решения за предоставяне на права въз основа на това как имейл адресът изглежда на човек, който го проверява.
Само ASCII или SMTPUTF8: сравнение на подходите
Решението дали да се поддържат Unicode символи в локалната част включва няколко компромиса.
| Съображение | Локална част само с ASCII символи | Поддръжка на SMTPUTF8 |
|---|---|---|
| Имейл съвместимост | Широка поддръжка | Зависи от инфраструктурата |
| Интернационализация | По-ограничителна | По-приобщаваща |
| Сложност на реализацията | Обикновено по-ниска | Допълнителни изисквания |
| Риск от хомографски атаки | Намален в локалната част | Изисква допълнително внимание |
| Интеграции с външни услуги | По-добра съвместимост | Изисква проверка |
| Изисквания за тестване | По-прости | Повече гранични случаи |
Нито един от двата подхода не е универсално правилен.
За приложения, които разчитат на доставчици без поддръжка на SMTPUTF8, ограничаването на Unicode символите в локалната част може да бъде разумно инженерно решение.
За приложения, насочени към международна аудитория, поддръжката на SMTPUTF8 може да бъде важно изискване.
Решението трябва да отразява нуждите на продукта, възможностите на инфраструктурата и изискванията за сигурност.
Практични препоръки за разработчици
Преди да активират SMTPUTF8, екипите за разработка трябва да обмислят няколко области.
1. Проверете съвместимостта на инфраструктурата
Уверете се, че доставчиците на имейл услуги, услугите за удостоверяване и интеграциите с външни системи поддържат интернационализирани имейл адреси.
2. Проверете целия процес на регистрация
Не приемайте, че успешното синтактично валидиране гарантира успешно доставяне на имейли.
Тествайте имейлите за потвърждение, възстановяването на пароли и другите критични комуникационни процеси.
3. Обмислете откриването на визуално объркващи Unicode символи
Unicode Technical Standard #39 предоставя механизми за откриване на визуално объркващи символи и идентификатори със смесени писмености.
Тези механизми могат да помогнат на приложенията да маркират подозрителни адреси за допълнителна проверка.
Автоматичното отхвърляне на всеки адрес със смесени писмености обаче може ненужно да изключи легитимни потребители.
4. Подхождайте внимателно към Unicode нормализацията
Unicode нормализацията може да разреши някои разлики в представянето на символите, но не премахва автоматично визуално объркващите символи.
Латинското o и кирилското о например остават различни.
Приложенията трябва да избягват сляпото заместване, преобразуване в малки букви или други преобразувания на локалната част на имейл адресите, защото тълкуването на пощенската кутия зависи от приемащия доставчик.
5. Използвайте отделни идентификатори за удостоверяване
Използвайте стабилни вътрешни потребителски идентификатори за предоставяне на права и за връзките между профили, вместо да третирате показвания имейл адрес като доверена самоличност.
6. Тествайте гранични случаи, свързани със сигурността
Включете визуално сходни адреси, различни Unicode представяния и интернационализирани адреси в интеграционните тестове и тестовете за сигурност.
Често задавани въпроси
Валидни ли са имейл адресите с Unicode символи?
Да. Стандартите за интернационализирана електронна поща допускат Unicode символи в имейл адресите при определени условия. Синтактичната валидност обаче не гарантира, че всеки доставчик на имейл услуги може да ги обработва.
Поддържа ли AWS SES SMTPUTF8?
Не. Документацията на AWS SES посочва, че SMTPUTF8 не се поддържа. Имейл адресите трябва да използват ASCII символи, въпреки че интернационализираните домейни могат да бъдат представени чрез Punycode.
Представляват ли Unicode имейл адресите риск за сигурността?
Не по своята същност. Визуално объркващите символи обаче могат да създадат рискове от представяне за друг потребител и проблеми при управлението на самоличности, ако приложенията не ги обработват подходящо.
Трябва ли приложенията да отхвърлят Unicode имейл адреси?
Не автоматично. Решението трябва да отчита изискванията за интернационализация, съвместимостта на инфраструктурата и подходящите мерки за сигурност.
Заключителни мисли
Валидирането на имейл адреси често се разглежда като прост детайл от реализацията.
В действителност то свързва логиката на приложението, външните услуги, потребителското изживяване и сигурността.
SMTPUTF8 показва как един установен стандарт може да създаде практически предизвикателства, когато инфраструктурата не го поддържа еднакво навсякъде.
Визуално сходните Unicode символи добавят още едно съображение: два адреса, които изглеждат еднакви за потребителите, може да представляват различни самоличности.
Целта не е просто да приемаме технически валиден вход, а да гарантираме, че приложението може да го обработва сигурно и надеждно през целия потребителски път.
Източници
- RFC 6531 - SMTP разширение за интернационализирана електронна поща (отваря се в нов раздел или прозорец)
- RFC 6530 - Рамка за интернационализирана електронна поща, съображения за сигурност (отваря се в нов раздел или прозорец)
- Unicode Technical Standard #39 - Механизми за сигурност на Unicode (отваря се в нов раздел или прозорец)
- Amazon SES - Документация на API SendEmail (отваря се в нов раздел или прозорец)
