RegEx для анализа или проверки данных Base64 - PullRequest
85 голосов
/ 24 января 2009

Можно ли использовать RegEx для проверки или санации данных Base64? Это простой вопрос, но факторы, которые движут этим вопросом, делают его трудным.

У меня есть декодер Base64, который не может полностью полагаться на входные данные в соответствии со спецификациями RFC. Итак, проблемы, с которыми я сталкиваюсь, это проблемы, такие как, возможно, данные Base64, которые не могут быть разбиты на 78 (я думаю, что это 78, мне придется перепроверить RFC, так что не звоните мне, если точное число неверно) или что строки могут не заканчиваться на CRLF; в том, что он может иметь только CR, или LF, или, возможно, ни того, ни другого.

Итак, я чертовски разобрался с данными Base64, отформатированными как таковые. Из-за этого примеры, подобные следующим, становятся невозможными для надежного декодирования. Для краткости я буду отображать только частичные заголовки MIME.

Content-Transfer-Encoding: base64

VGhpcyBpcyBzaW1wbGUgQVNDSUkgQmFzZTY0IGZvciBTdGFja092ZXJmbG93IGV4YW1wbGUu

Хорошо, такой разбор - это не проблема, и это именно тот результат, который мы ожидаем. И в 99% случаев использование любого кода, по крайней мере, для проверки того, что каждый символ в буфере является действительным символом base64, работает отлично. Но следующий пример бросает гаечный ключ в смесь.

Content-Transfer-Encoding: base64

http://www.stackoverflow.com
VGhpcyBpcyBzaW1wbGUgQVNDSUkgQmFzZTY0IGZvciBTdGFja092ZXJmbG93IGV4YW1wbGUu

Это версия кодировки Base64, которую я видел в некоторых вирусах и других вещах, которые пытаются использовать преимущества некоторых почтовых ридеров, желающих разобрать mime любой ценой, по сравнению с теми, которые строго соблюдаются в книге, или, скорее, RFC; если вы будете.

Мой Base64 декодер декодирует второй пример в следующий поток данных. И имейте в виду, что исходный поток - это все данные ASCII!

[0x]86DB69FFFC30C2CB5A724A2F7AB7E5A307289951A1A5CC81A5CC81CDA5B5C1B19481054D0D
2524810985CD94D8D08199BDC8814DD1858DAD3DD995C999B1BDDC8195E1B585C1B194B8

У кого-нибудь есть хороший способ решить обе проблемы одновременно? Я не уверен, что это даже возможно, за исключением двух преобразований данных с применением разных правил и сравнения результатов. Однако, если вы выбрали такой подход, какому выходу вы доверяете? Кажется, что эвристика ASCII - это самое лучшее решение 1017 *, но насколько больше кода, времени выполнения и сложности это добавит к чему-то столь же сложному, как сканер вирусов, в который этот код на самом деле вовлечен? Как бы вы обучили эвристический движок, чтобы узнать, что является приемлемым Base64, а что нет?


UPDATE:

Учитывая количество просмотров, которое продолжает получать этот вопрос, я решил опубликовать простой RegEx, который я использую в приложении C # уже 3 года, с сотнями тысяч транзакций. Честно говоря, мне больше всего нравится ответ, данный Гамбо , поэтому я выбрал его в качестве выбранного. Но для любого, кто использует C # и ищет очень быстрый способ, по крайней мере, определить, содержит ли строка или byte [] допустимые данные Base64 или нет, я обнаружил, что следующее очень хорошо работает для меня.

[^-A-Za-z0-9+/=]|=[^=]|={3,}$

И да, это только для STRING данных Base64, а НЕ для правильно отформатированного сообщения RFC1341 . Итак, если вы имеете дело с данными такого типа, пожалуйста, примите это во внимание, прежде чем пытаться использовать вышеупомянутый RegEx. Если вы имеете дело с Base16, Base32, Radix или даже Base64 для других целей (URL-адреса, имена файлов, кодировка XML и т. Д.), Тогда крайне рекомендуем прочитать RFC4648 что Gumbo упоминается в его ответе, поскольку вам необходимо хорошо знать кодировку и терминаторы, используемые реализацией, прежде чем пытаться использовать предложения из этого набора вопросов / ответов.

Ответы [ 4 ]

121 голосов
/ 24 января 2009

Из RFC 4648 :

Базовое кодирование данных используется во многих ситуациях для хранения или передачи данных в средах, которые, возможно, по старым причинам, ограничены данными US-ASCII.

Таким образом, от цели использования закодированных данных зависит, будут ли данные считаться опасными.

Но если вы просто ищете регулярное выражение для соответствия словам в кодировке Base64, вы можете использовать следующее:

^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$
26 голосов
/ 04 мая 2011
^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$

Это хорошо, но будет соответствовать пустой строке

Это не соответствует пустой строке:

^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$
4 голосов
/ 24 января 2009

Ни ": ", ни ". " не будут отображаться в действительном Base64, поэтому я думаю, что вы можете однозначно выбросить строку http://www.stackoverflow.com. В Perl, скажем, что-то вроде

my $sanitized_str = join q{}, grep {!/[^A-Za-z0-9+\/=]/} split /\n/, $str;

say decode_base64($sanitized_str);

может быть, что вы хотите. Производит

Это простой ASCII Base64 для StackOverflow, например.

2 голосов
/ 26 марта 2015

Лучшее регулярное выражение, которое я мог найти до сих пор, здесь https://www.npmjs.com/package/base64-regex

который в текущей версии выглядит так:

module.exports = function (opts) {
  opts = opts || {};
  var regex = '(?:[A-Za-z0-9+\/]{4}\\n?)*(?:[A-Za-z0-9+\/]{2}==|[A-Za-z0-9+\/]{3}=)';

  return opts.exact ? new RegExp('(?:^' + regex + '$)') :
                    new RegExp('(?:^|\\s)' + regex, 'g');
};
...