Прямые ссылки на объекты

Такая уязвимость, как использование прямых ссылок, может пагубно повлиять на безопасность веб-приложения. Возьмем в пример прямую ссылку на фотографию в приватном альбоме (папке). Если открыть данную фотографию в браузере, то в адресной строке будет прописан полный путь к этому файлу. Если в тех папках не лежит файл index.html или index.php, либо другой файл, используемый сервером по умолчанию (или файл, запрещающий доступ к папке, например, .htaccess), то, убрав из адресной строки название фотографии, мы можем просмотреть все файлы, находящиеся в данной папке. Здесь браузер выступает своеобразным "Проводником" по файлам и папкам, и мы можем передвигаться как угодно (не только по текущей папке, но и на уровень выше и ниже).

Рассмотрим, как защищаются от этой напасти различные популярные сайты. Возьмем для примера сайт Вконтакте. Все фотографии (ну или почти все, я для примера взял одну свою) имеют подобный адрес

https://pp.userapi.com/c000000/v000000000/XXXXX/XXXXXXXXXXX.jpg

Нули обозначают цифру (от 0 до 9), а X - любые символы (прописные и срочные буквы латинского алфавита), в т.ч. и цифры Давайте подсчитаем при таком расскладе (а никто не говорит, что со временем он не поменяется - допустим, цифровые коды расширятся на любые символы, либо заместо 7-символьного будет 8-символьный и т.д.) какова вероятность найти одну определенную фотографию?

Яндекс калькулятор выдал такое значение:

6^10 * 9^10 * 5^62 * 11^62 = 2,91 × 10^87

По запросу "Сколько частиц во вселенной" поисковик выдал эту цифру: 3.28 × 10^80. Т.е. во вселенной в несколько миллионов раз меньше частиц, чем возможных вариантов комбинаций адреса (надеюсь я нигде не ошибся с расчетами).

Но не везде так хорошо подходят к безопасности данных. Например, при проектировании сайта программист решил все загружаемые файлы кидать в одну папку. И рядом с картинкой, выводимой на сайте лежит какой-нибудь конфиденциальный документ. А так как в названиях обычно не рандомная строка, а что-нибудь попроще (например, дата-время, timestamp или, что еще хуже, какой-нибудь ID), то подобрать адрес документа не составляет труда.

А бывает и такое, что поисковик индексирует различные файлы, которые не должны быть в открытом доступе. Например, буквально недавно Яндекс проиндексировал документа Гугла, которые, помимо прочего, содержали пароли.

Прямые ссылки не обязательно должны указывать на файл. Это может быть ссылка на запись в БД. Например, одна из распространенных ранее уязвимостей была следующей: В адресной строке происходила передача параметра, например, такого: ?page=index, а в коде страницы просто происходило подключение данного файла, например, так: include($_GET['page'] . '.php'); Стоит ли говорить, что хакер мог подключить и выполнить на сервере произвольный код, подключив файл со своего сервера?