История двух ATO. Ищем уязвимости в логике обработки email

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

Первый Account Takeover

При изу­чении сер­виса я нашел нес­коль­ко инте­рес­ных ано­малий:

• При сме­не email в нас­трой­ках про­филя дос­туп к новому адре­су не про­веря­ется.
• При регис­тра­ции поль­зовате­ля и логине в его акка­унт API при­водит передан­ный email к ниж­нему регис­тру. Но при сме­не email в нас­трой­ках про­филя он не под­верга­ется никаким изме­нени­ям и успешно про­ходит про­вер­ку уни­каль­нос­ти, даже если сущес­тву­ет близ­нец с сим­волами в ином регис­тре.
• При иссле­дова­нии JWT, который исполь­зует­ся для авто­риза­ции поль­зовате­ля, я выяс­нил, что роль иден­тифика­тора поль­зовате­ля игра­ет email (так как это единс­твен­ный иден­тифика­тор поль­зовате­ля в пей­лоаде JWT).

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

Пример пейлоада JWT

Пер­вым делом нуж­но было понять, что про­изой­дет, если будет сущес­тво­вать нес­коль­ко email-близ­нецов с сим­волами в раз­ных регис­трах и мы поп­робу­ем исполь­зовать их для логина.

Что­бы разоб­рать­ся, что про­исхо­дит на бэкен­де сер­виса, я соз­дал два акка­унта и email вто­рого поменял на email пер­вого через баг в нас­трой­ке про­филя, пред­варитель­но изме­нив регистр некото­рых букв. При этом пароли у акка­унтов были раз­ными.

При попыт­ке вой­ти с дан­ными пер­вого поль­зовате­ля (того, который был зарегис­три­рован рань­ше) мы успешно попада­ем в его акка­унт. Если же исполь­зовать дан­ные вто­рого поль­зовате­ля, получа­ем ошиб­ку Invalid Credentials.