Post #340

В статье про то, как Вася проектировал API, есть блок про безопасность. Но не такую безопасность, как https и схемы авторизации, а не совсем очевидную: раскрытие чувствительных данных и компрометация системы. Компрометацию я видел вблизи и в очень неприятном виде: в сервисе электронных домашних заданий (которые прямо на компьютере можно выполнять, то есть это по сути тесты) имелся API, через который можно было получить верные ответы. Разумеется, школьники его сразу же обнаружили и начали использовать: появились боты, выдающие правильные номера ответов. Да, через некоторое время проверку полностью перенесли на сервер, но обратно убедить учителей, что теперь-то школьники не смогут найти правильные ответы, так полностью и не удалось. Про ситуации, когда по известной структуре адреса можно скачать документ безо всякой авторизации, думаю, вы не раз слышали. То есть, у вас есть бинарный документ (doc, pdf, xls) или образ (jpg, png), и он лежит в файловом хранилище, а в ответ API подставляется по ссылке. Если ссылки устроены однотипно, а файлы имеют упорядоченные наименования — например, по порядку, или по дате — то можно выкачать их все. Например, как это было на Госуслугах. Ну и другие открытые метаданные бывают интересными, вот тут статья про анализ поведения такси по открытым данным. На что стоит обратить внимание: ✅ полномочия доступа к статическим ресурсам тоже должны проверяться. Ну, это не всегда хочется или есть возможность сделать. поэтому есть следующее правило: ✅ выдача идентификаторов не должна идти подряд! Иначе можно простым инкрементом вытащить сразу много объектов. А также, например, узнать прирост числа объектов за день, что тоже может быть интересным. ✅ не показывайте ссылки на технические домены — для мониторинга и отслеживания ошибок. Если уж ссылаетесь, то не размещайте там же, например, репозиториев с кодом или открытых технических страниц / админок по стандартным адресам. А то мы тут с сыном, пока ждали очереди в поликлинике, запустили на их справочном киоске youtube — именно по цепочке незакрытых технических ссылок. ✅ избегайте бесконтрольное перекладывание данных из БД в API, включая мета-информацию (кто создал, кто последний раз обновлял, и т.п.) ✅ не выдавайте лишней информации в ошибках. Например, API Github не выдает ошибку 403 при попытке доступа к приватному ресурсу, а выдает 404 — чтобы нельзя было в принципе обнаружить существование такого ресурса! ✅ контролируйте частоту запросов от одного клиента — у того же Github есть сложная система с первичными и вторичными лимитами, можно взять, как источник вдохновения. ✅ контроль подозрительной широты запросов клиента, не соответствующих естественным бизнес-потребностям (от имени учителя истории в средней школе множество запросов результатов тестов по математике и физике 10-11 классов) ✅ не передавайте алгоритм расчета или проверки на клиента (хотели тонкого клиента и избежать обновлений клиентов). Тут понятно — передать-то мы передали, а вот что клиент этот наш, и что именно по этому алгоритму он будет считать и проверять...