Microsoft: SNDS + live.com + кривая защита формы чем-то типа WAF
Нарвался на совершенно нелепый баг у Microsoft (это я сейчас уже понимаю, что это баг: вначале я думал, что это какой-то кривой вариант работы санкций где-то на промежуточных/сопутствующих серверах/сервисах).
У Microsoft есть программа SNDS (против спама) для всех подконтрольных ресурсов Microsoft.
https://sendersupport.olc.protection.outlook.com/snds/
Там все идет через Microsoft Support.
Есть такая ссылочка:
http://mail.live.com/mail/troubleshooting.aspx#errors
Далее: http://go.microsoft.com/fwlink/?LinkID=614866
Что преобразуется в: https://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75
Так вот, после заполнения указанной формы, чтобы создать тикет на очистку IP-адреса/подсети, какой-то из промежуточных сервисов/серверов Microsoft (а там куча всяких редиректов, перекидываний и еще подкапотных участий) отрапортует буквально следующее:
Access Denied
You don't have permission to access "http://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75" on this server.
Reference #xx.xxxxxxxx.xxxxxxxxxx.xxxxxxx
Так как до 24.02 все это точно работало (я использовал), первым же делом я сразу же подумал про "добро пожаловать в мир санкций". Мол, вероятно, с российским IP-адресом какой-то из сервисов (технических - промежуточных для указанного) банит запрос. И в итоге не работает вообще ничего: создать тикет для чистки IP/подсети невозможно.
Потратил кучу времени: стал пробовать разные браузеры - не помогло; разные IP-адреса (Швецию и другие) - не помогло; стал думать про кривой fingerprinting и какие-то технические особенности браузера - сделал уже абсолютно левую чистую тачку с чистым "обычным" браузером с разрешением всего и вся по умолчанию и .kz IP - тот же результат.
Это явно навело на мысли, что дело тут не в санкциях/IP/браузерах, а в чем-то другом.
Решил сделать то, что, наверно, следовало сразу же ("слишком умный") - погуглить.
Google:
support.microsoft.com You don't have permission to access
Нашел такой вопрос в поддержку:
https://answers.microsoft.com/en-us/outlook_com/forum/all/how-to-solve-you-dont-have-permission-to-access/6c92f42f-1d40-41d8-8c21-225342114a08
Стал читать и почти с первых же строк расстроился - классический support Microsoft, да и вообще большинство support'ов: "ясно-понятно, шансов просто ноль - тупой бот советует перезагрузить компьютер".
Но благо сам автор вопроса оказался умнее поддержки и через n итераций уже самостоятельно нашел решение, а именно:
Hi,
after I changed the content of the Error message field from the email header (I was entering before) to just plain text, I was able to submit the support request form.
I thought that I have to insert a header of a bounced email, but it turned out this causes an issue to submit the form.
Thanks for your time.
Похоже у Microsoft где-то в анализаторе данных засабмиченной формы стоит WAF или детектор каких-то спец-символов, или html, или <, > и т.п. - и он вместо того, чтобы преобразовать их в безопасный вариант (заэскейпить), детектирует их как попытку взлома или что-то такое и... банит пользователя (банит этот request). Отличная защита! При этом ничего конкретного не сообщает (мог бы хотя бы как-то сообщить, что проблемы в данных формы, что она "небезопасна"; правда, возможно, на том уровне, где ведется проверка данных - это давно уже не форма, а какой-нибудь 30 раз преобразованный request во что-нибудь другое, и понимания "исходника" в анализаторе может даже и не быть - или не быть возможности протолкнуть назад ответ-пометку). Как итог, люди, читая такую ошибку, думают совершенно о другом (я думал, что проблема в российском IP браузера, российской TZ в запросе, российском IP MX/подсети, российском e-mail, с которого обращение; потом - что технические особенности fingerprinting и т.д. - испробовал кучу разных браузеров, разных стран).
И как обычно, такие баги не долетают даже из support никуда выше. Можно дочитать до конца и увидеть это.
Еще пример аналогичного запроса (и вообще их много):
https://answers.microsoft.com/en-us/outlook_com/forum/all/how-to-solve-you-dont-have-permission-to-access/b567583b-d78a-4368-ad20-46f78960869a
И решения:
Had the exact same issue, turns out I couldn't send the form because the error log text field contained the string "/var/log/mail.log". As soon as I edited this to "mail.log" I was able to send the form. This must be a bug with the form request and should be escalated by someone here to the relevant team.
Я пробовал порядка 7-8 крупных модификаций заголовков (для экономии времени часть из них были совмещены, поэтому падает точность и однозначность выводов). Какие замены были сделаны:
1) Заменены "/" на пробелы (считаю, что это важно, это отмечено и в одном из ответов выше)
2) Заменены "[" и "]" на "(" и ")" (сейчас полагаю, что неважно)
3) Заменена "." перед apsx в тексте на пробел (сейчас полагаю, что неважно)
4) Заменены "@" на " at " (сейчас полагаю, что неважно)
5) Удалены ";" (это одно из последних изменений, совмещенных с еще одним неважным).
В общем, полагаю, что к "запрещенным символам", на которые реагирует парсер/защита являются "/" (предположительно) и ";" (гарантированно). В разделе "Copy error message" их быть не должно.
У Microsoft есть программа SNDS (против спама) для всех подконтрольных ресурсов Microsoft.
https://sendersupport.olc.protection.outlook.com/snds/
Там все идет через Microsoft Support.
Есть такая ссылочка:
http://mail.live.com/mail/troubleshooting.aspx#errors
Далее: http://go.microsoft.com/fwlink/?LinkID=614866
Что преобразуется в: https://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75
Так вот, после заполнения указанной формы, чтобы создать тикет на очистку IP-адреса/подсети, какой-то из промежуточных сервисов/серверов Microsoft (а там куча всяких редиректов, перекидываний и еще подкапотных участий) отрапортует буквально следующее:
Access Denied
You don't have permission to access "http://support.microsoft.com/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75" on this server.
Reference #xx.xxxxxxxx.xxxxxxxxxx.xxxxxxx
Так как до 24.02 все это точно работало (я использовал), первым же делом я сразу же подумал про "добро пожаловать в мир санкций". Мол, вероятно, с российским IP-адресом какой-то из сервисов (технических - промежуточных для указанного) банит запрос. И в итоге не работает вообще ничего: создать тикет для чистки IP/подсети невозможно.
Потратил кучу времени: стал пробовать разные браузеры - не помогло; разные IP-адреса (Швецию и другие) - не помогло; стал думать про кривой fingerprinting и какие-то технические особенности браузера - сделал уже абсолютно левую чистую тачку с чистым "обычным" браузером с разрешением всего и вся по умолчанию и .kz IP - тот же результат.
Это явно навело на мысли, что дело тут не в санкциях/IP/браузерах, а в чем-то другом.
Решил сделать то, что, наверно, следовало сразу же ("слишком умный") - погуглить.
Google:
support.microsoft.com You don't have permission to access
Нашел такой вопрос в поддержку:
https://answers.microsoft.com/en-us/outlook_com/forum/all/how-to-solve-you-dont-have-permission-to-access/6c92f42f-1d40-41d8-8c21-225342114a08
Стал читать и почти с первых же строк расстроился - классический support Microsoft, да и вообще большинство support'ов: "ясно-понятно, шансов просто ноль - тупой бот советует перезагрузить компьютер".
Но благо сам автор вопроса оказался умнее поддержки и через n итераций уже самостоятельно нашел решение, а именно:
Hi,
after I changed the content of the Error message field from the email header (I was entering before) to just plain text, I was able to submit the support request form.
I thought that I have to insert a header of a bounced email, but it turned out this causes an issue to submit the form.
Thanks for your time.
Похоже у Microsoft где-то в анализаторе данных засабмиченной формы стоит WAF или детектор каких-то спец-символов, или html, или <, > и т.п. - и он вместо того, чтобы преобразовать их в безопасный вариант (заэскейпить), детектирует их как попытку взлома или что-то такое и... банит пользователя (банит этот request). Отличная защита! При этом ничего конкретного не сообщает (мог бы хотя бы как-то сообщить, что проблемы в данных формы, что она "небезопасна"; правда, возможно, на том уровне, где ведется проверка данных - это давно уже не форма, а какой-нибудь 30 раз преобразованный request во что-нибудь другое, и понимания "исходника" в анализаторе может даже и не быть - или не быть возможности протолкнуть назад ответ-пометку). Как итог, люди, читая такую ошибку, думают совершенно о другом (я думал, что проблема в российском IP браузера, российской TZ в запросе, российском IP MX/подсети, российском e-mail, с которого обращение; потом - что технические особенности fingerprinting и т.д. - испробовал кучу разных браузеров, разных стран).
И как обычно, такие баги не долетают даже из support никуда выше. Можно дочитать до конца и увидеть это.
Еще пример аналогичного запроса (и вообще их много):
https://answers.microsoft.com/en-us/outlook_com/forum/all/how-to-solve-you-dont-have-permission-to-access/b567583b-d78a-4368-ad20-46f78960869a
И решения:
Had the exact same issue, turns out I couldn't send the form because the error log text field contained the string "/var/log/mail.log". As soon as I edited this to "mail.log" I was able to send the form. This must be a bug with the form request and should be escalated by someone here to the relevant team.
Я пробовал порядка 7-8 крупных модификаций заголовков (для экономии времени часть из них были совмещены, поэтому падает точность и однозначность выводов). Какие замены были сделаны:
1) Заменены "/" на пробелы (считаю, что это важно, это отмечено и в одном из ответов выше)
2) Заменены "[" и "]" на "(" и ")" (сейчас полагаю, что неважно)
3) Заменена "." перед apsx в тексте на пробел (сейчас полагаю, что неважно)
4) Заменены "@" на " at " (сейчас полагаю, что неважно)
5) Удалены ";" (это одно из последних изменений, совмещенных с еще одним неважным).
В общем, полагаю, что к "запрещенным символам", на которые реагирует парсер/защита являются "/" (предположительно) и ";" (гарантированно). В разделе "Copy error message" их быть не должно.