Инжекция заголовка SMTP в ASP.NET?
С учетом того, что циклы не имеют return, break и т. Д. (Например, исключение броска), полнота равна
O(n * (m + j)) == O(n * m) + O(n * j)
, если оба m и j являются константами у нас есть
O(n*m + n*j) == m * O(n) + j * O(n) == O(n)
если хотя бы один m или j такой, что m ~ n или j ~ n, то имеем
// here m ~ n and j is some const
O(n * m) + O(n * j) == O(n * n) + j * O(n) == O(n**2) + O(n) == O(n**2)
3 ответа
Я видел этот являющийся целью ОЧЕНЬ творческого нападения.... Вы наполняете управляемые данные пользователя в свое тело сообщения... В которой точке, лукавое использование двоичных данных МОГЛО привести к ТЕЛУ, которое отправляет надлежащие данные во время сессии SMTP для получения его ПРОСТО ПРАВО... Если бы я могу, я предложить или преобразование тела всему тексту ASCII, или во время Вашего строкового здания, записать строковое дезинфицирующее средство, которое только позволяет символам RFC войти. (Фильтрует URL, ССЫЛАЮЩИЙСЯ ДОМЕН, Удаленный Адрес и UserAgent). Это - Ваши более вероятные точки нападения.
Долгое размышление могло бы быть должно создать основное электронное письмо в коде и ПРИСОЕДИНИТЬ тело, которое Вы создали как текст, или HTML или файл PDF.
Следует иметь в виду, данные КОНВЕРТА SMTP НЕ являются тем же как данными сообщения.... Если бы кто-то был достаточно лукавым для отправки корректного тела, которое заставило CRLFCRLF.CRLFCRLF быть отправленным во время части тела, которая завершит отправку, и затем если бы они продолжали отправлять данные, то они могли бы отправить целую ПОЧТУ ОТ: ПРИЕМ К: ДАННЫЕ, и т.д. (Предоставленный, это - маловероятный сценарий...)...
Я хотел бы видеть НЕОБРАБОТАННЫЙ источник электронной почты, которую Вы получили... (Как в шестнадцатеричном дампе фактической транзакции SMTP, не, что Outlook хочет, чтобы Вы видели, или безотносительно).
Можно также попытаться кодировать тело с помощью QP или B64 прежде, чем отправить сообщение.... Это могло бы решить Вашу проблему...
Это - интересное, и я с нетерпением жду результата его.
Ваш код выглядит очень безопасным, таким образом, я не думаю, что проблема находится на Вашей стороне.
IMO, любой, кто-то прервал сообщение SMTP, в то время как это отправлялось в mailserver и ввело дополнительный CC: строка; или mailserver был поставлен под угрозу.
Если Вы не можете найти ответ, я предлагаю связаться с Microsoft непосредственно - Вы, возможно, раскрыли использование в Платформе.NET.
As a workaround, why don't you encript the email message using asymeterical encription (for example public key encription)? That way only the intended recepient will be able to read it.
In this way even if the bad guys get a copy of your message (by whatever means) it will be of now use to them.
Lets face it, if you have a high profile website like the FBI or Google, lots of very creative people will spend lots of time and go to great lengths to comprimise it. It is extremely important to protect detailed error messages.