Плохая форма. Разбираем техники тестирования и защиты форм восстановления пароля

Я занима­юсь ана­лизом защищен­ности в Singleton Security. При про­веде­нии пен­теста час­то стал­кива­юсь с фор­мами сбро­са пароля. Кажет­ся, что это прос­той и стан­дар­тный механизм. На деле же — уяз­вимос­ти в вос­ста­нов­лении пароля при­водят к пол­ному зах­вату акка­унта, утеч­ке кон­фиден­циаль­ных дан­ных или перех­вату управле­ния сер­вером.

Атаки с использованием заголовка Host

Нач­нем с атак на под­мену HTTP-заголов­ков. Такая ата­ка воз­ника­ет, ког­да заголов­ки генери­руют­ся на осно­ве поль­зователь­ско­го вво­да и сер­вер не про­веря­ет эти дан­ные дол­жным обра­зом. Хакер может внед­рить свой кон­тро­лиру­емый домен в ссыл­ку для вос­ста­нов­ления пароля.

Уяз­вимость час­то встре­чает­ся, ког­да час­ти веб‑при­ложе­ния находят­ся на раз­ных доменах и поль­зовате­ли при­вязы­вают­ся к точ­ному хос­ту:

• от­дель­ные под­домены для раз­ных язы­ков;
• раз­бивка поль­зовате­лей из раз­ных стран по домен­ным зонам (.ru, .fr, .de и так далее);
• мно­жес­твен­ные домены — нап­ример, язы­ковая шко­ла может исполь­зовать что‑то вро­де eng-lang.com, de-lang.com, rus-lang.com.

Что­бы подоб­ный сер­вис стал уяз­вимым, раз­работ­чик дол­жен забыть про белые спис­ки и исполь­зовать пря­мую встав­ку домена в генера­торе ссы­лок на вос­ста­нов­ление пароля:

До­пус­тим, у нас есть сайт, уяз­вимый к под­мене HTTP-заголов­ков, который отправ­ляет ссыл­ку для вос­ста­нов­ления пароля вида https://vulncorp.com/{token}. Мы можем соз­дать такой зап­рос, что­бы получить токен пароля:

Жер­тве при­дет ссыл­ка на вос­ста­нов­ление пароля с вре­донос­ным доменом. Ког­да поль­зователь перей­дет по ней, токен попадет в руки зло­умыш­ленни­ка.

Ес­ли ата­ка не сра­бота­ла, про­буй раз­личные дуб­лиру­ющие хедеры наподо­бие X-Forwarded-Host, X-HTTP-Host-Override и так далее.

Один из воз­можных под­ходов — дуб­лирова­ние заголов­ка Host. Прок­си‑сер­веры обра­баты­вают дуб­лирован­ные заголов­ки по‑раз­ному. В зависи­мос­ти от прок­си на выходе может быть отбро­шен пер­вый или дуб­лиру­ющий заголо­вок либо выпол­нится join с раз­делени­ем через запятую. Иног­да может ока­зать­ся, что раз­работ­чики не пре­дус­мотре­ли такой сце­нарий и мы можем внед­рить наш домен в ссыл­ку, добавив еще один заголо­вок Host.

Бы­вают слу­чаи, что сер­вер про­веря­ет хедеры, но недос­таточ­но безопас­но. Воз­ника­ет воз­можность внед­рения висячей раз­метки (Dangling markup) — это вид ата­ки с инъ­екци­ей HTML-кода, пред­полага­ющий исполь­зование незак­рытого тега или атри­бута. Пред­положим, что заголо­вок Host валиди­рует­ся, но есть воз­можность написать порт при­ложе­ния. Этим мы и вос­поль­зуем­ся, отпра­вив зап­рос такого вида:

С помощью такой наг­рузки мы можем соз­дать фишин­говую стра­ницу с фор­мой отправ­ки дан­ных на наш сер­вер. Поль­зователь, уве­рен­ный, что получил пись­мо от нас­тоящей ком­пании, перей­дет по ссыл­ке и вве­дет дан­ные от учет­ной записи. Тут оста­ется сде­лать хорошую фишин­говую стра­ницу.

Но сов­ремен­ные поч­товые кли­енты (такие как Gmail или Outlook) и анти­вирус­ные решения име­ют мощ­ные филь­тры, которые находят и бло­киру­ют подоб­ные пись­ма, помещая их в спам или вооб­ще не дос­тавляя, так как HTML в заголов­ках выг­лядит подоз­ритель­но.

Пе­ред тем как ана­лизи­ровать содер­жимое, один из филь­тров при­водит HTML-код пись­ма к «плос­кому» и чита­емо­му виду, ана­логич­но тому, как это дела­ет бра­узер. Все эти висящие <div>, <span>, <font> с белым цве­том шриф­та на белом фоне, эле­мен­ты с display: none или font-size: 0 прос­то вычища­ются. Оста­ется толь­ко видимое тек­сто­вое содер­жимое. Извле­кают­ся все ссыл­ки пись­ма, про­веря­ются репута­ции URL-адре­сов и мно­гое дру­гое. Эта ата­ка может сра­ботать в кор­поратив­ных сетях со сво­ими поч­товыми сер­верами, где филь­тра­ция менее стро­гая.