я как раз выше писал о том, что современные системы строятся по другому и соответсвенно вектор атаки меняется из классического web на изощренные подходы компромизации пользователей - как вы сами выше описали. Distributed Systems - это сейчас стандарт. Вы не одно собеседование без system design не пройдете.
Само понятие инъекция существует в разных вариациях и если туда углубляться - там конца и края нет. Вон выше вы писали, что у вас в команде с теми же самыми GET и POST разобраться не могут. По вашему опусу можно судить,что в 2025 году в вашей конторе так же могут напороться на какие угодно атаки. Или скриншот с гос сайта филадельфии - это вообще треш - думаете там не пробоют классический injection? Вы так же можете просмотреть OWASP сертификацию - там до сих пор раздел есть.
Переход на распределенные системы начался году в 2015, когда уже пошел ажиотаж на разделение монолита, добавление дополнительных функций, асинхронные вызовы - kafka, rabbitmq - прям рассвет этих технологий. до 2015 года, проблема классических атак и методология их купирования были в каждом конфигурационном документе фаерволов. Они и сейчас там есть. Проблема осталась в том, что за последние 10 лет не все компании смогли адаптировать свой легаси продукт под новый дизайн. Оттуда и архаичные требования о знаниях и SQL query в фронтенде. И это реальность даже на сегодняшний день - точно не из 90х годов. Точнее пережиток прошлого дошедший до наших дней. Переделывать сложно - нет ресурсов и денег, поддерживать - будут до тех пор пока могут. Вот на COBAL до сих пор пишут.
Весь спор не о чем - одни говорят о том, что это устарело, только без объяснений почему,Москва пишет что это маст хав - только тоже без нормального объяснения для чего именно ей это нужно. Если у вас супер жесткие требования по безопасности и вы спрашиваете по sql во frontend - то Houston у вас проблемы.
In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.
Это просто позор говорить о SQL query в фронтенде.
Только @ramator-у это неведомо. Я потому и ржу везде , где он это пишет.
Именно поэтому в конторах как у нас, где безопасность очень важна, спрашивают “базу” у новичков на собеседовании , чтобы увидеть что человек вообще знает об этом, какие методы решения предлагает. Если бы начал говорить об архаике, как “товарисчи” здесь, с ним бы тут же попрощались.
Я не знаю о ком ты " бюджтные погроммисты пишут SQL на фронтенде" в контексте конкретной дискуссии.
Поэтому и предполагаю, что о себе. Тем более, что ты именно это и утверждаешь .
К сожалению. Но у нас в любом случае есть целый независимый отдел, мониторящий атаки, и на уровне инфраструктуры поверхность атак минимизируется. Все микросковисы комуницируют в VPN, и контора регулярно заказывает penetration test сторонних фирм. Но тем не менее я постоянно вижу слабые места, и рассказать мне об этом некому. Слава богам после одного из таких тестов они отошли хотя бы от стратегии security from obscurity.
Весь спор о том, что @Moscow вспомнила лишь самый знаментый книжный вид инъекции и думает, что она обладает какими-то несравнимыми ни с кем высокопрофессиональными знаниями такого уровня, что ей ни одна security угроза не страшна, даже если она будет писать на Assembly. Больше ничего вспомнить не может. И очень даже возможно, что она как раз и занимается госсайтом Филадельфии (для этого не обязательно жить в самом городе).
А так, да, я и говорю про всю сложность вопроса безопасности, и что нет для этого one size fits all знаний.
Если бы человек не читал всю дискуссию, он мог бы поверить тебе. Но я уверена, человек читал.
Поэтому, ненавистник москвичей, проходите мимо. У вас это личное, sorry.
И когда я описал ситуацию, что у меня в команде выбрали POST вместо GET из-за простоты передачи параметров, я именно и имел в виду какие дыры это может открыть. И тут пришла @Moscow , которая на голубом глазу утверждает, что GET придумали хакеры, чтобы легче взломать систему, и что везде, где есть параметры на всякий случай нужно выбрать POST. Ей тут же поставили 2 в журнал, а она - я мильён лет на страже SQL инъекций, я тим-лид и фулл-стэк. При этом не в зуб ногой об различиях этих http методов. Не только не понимает принципы семантики RESTfull коммуникаций, но и не разделяет эти методы по признакам safe и idempotent. А тем временем слепой выбор POST над GET может открыть двери для атак следующих классов:
Cross-Site Request Forgery (CSRF)
HTTP Verb Tampering
Complex Payload Injection (тот самый, где SQL injection является частным члучаем)
Mass Assignment
Logging Data Exposure (это я в своей конторе в нескольких местах поймал - и, да, это в основном случается с POST запросами)
Application-Layer DoS
И это, наверное, не весь список.
Hey @Moscow , что у вас в конторе предусмотрено на случай application -layer DoS? Давай, как на интервью. Чем защититься от этого для POST-запросов?
Ещё бы кто ей напомнил про CORS и preflight запросы, но у них там разрабатывается что-то железобетонное, не до нюансов. Лишь бы от noSQL инъекций в мозг отбиться.
Я потому и ржу везде , где он это пишет.
Но я уверена, человек читал.