Интересно. А этот самый Team A meeting не превращается случайно в действо с целью потопить этого самого архитектора?

avp скучно - у нас 200-й?

и кстати раз мы это затронули. если использовать пдо и сделать запрос вида $sql = '.... where id = :id'; $sth = $pdo->prepare($sql) $sth->bindParam(':id', $_GET['id'], PDO::PARAM_INT); считается ли это безопасным?)

Такие плейсхолдеры защищают только от одного типа инъекций - который возможен при парсинге запроса во внутреннюю сруткуру сервера БД. А если дальше этот запрос инициирует процедуры/триггеры которые что-то делают с пришедшими данными, то там возможна инъекция второго рода и надо экранировать вручную все равно

не понял. я думал что сперва идет экранивароние, потом шняга вставляется в строку и отдается субд. сама субд принимает уже нормальный запрос с экранированными данными, разве не так?

У меня был тоже такой класс, который принимал массив параметров, экранировал их и через str_replace вставлял в запрос)

Но на триггеры придет неэкранированный?

@miksir следует разделять понятия "виноват" и "соответствие требованиям". Если проблема несоответствия архитектуры текущим требованиям вызывает чувство вины - могу предложить лишь обратиться к психоаналитику.

или я не догоняю

Отсутствие проверки приходящих данных от клиента. Фильтровать данные

Кстати, наверное, к XSS еще относится и следующая ошибка (а может и нет): когда мы редактируем профиль и в нем есть скрытое поле - user_id. И при сохранении мы обновляем данные этого пользователя просто по указанному в форме user_id. Здесь как вариант - либо вообще не указывать и брать данные из сессии/куки (но так как куки можно подделать), использовать csrf / подпись. то есть генерировать еще один элемент token, например. И хешировать его с нужным нам значением

не могу я не парится если в триггеры попадут не экранированные данные

Классически неверный ответ. Данные не проверяются и фильтруются. Данные эскейпется в точки применения. Хорошо знание этого показыватся на моментах защиты от xss. Где мы будем эскейпить данные? На входе? На сохранении в базу?

Классически неверный ответ. Данные не проверяются и фильтруются. Данные эскейпется в точки применения. Хорошо знание этого показыватся на моментах защиты от xss. Где мы будем эскейпить данные? На входе? На сохранении в базу?

кстати, а вот тут интересный вопрос. я прав что даныне экранируются при выводе. в бд мы храним оригинал?

кстати, а вот тут интересный вопрос. я прав что даныне экранируются при выводе. в бд мы храним оригинал?

эскейп - это подготовка данных к применению

кстати, а вот тут интересный вопрос. я прав что даныне экранируются при выводе. в бд мы храним оригинал?

проверка - это действие дающиее ответ - да/нет ;)

Может нам сервис организовать, митап платных собеседований? ;)

К XSS не относится. Куки ты как собрался подделывать. Токен - это защита от CSRF, ни к чему больше отношения не имеет.

Беру плагин - редактор куки и правлю нужные мне вещи. Нет? Все же зависит от того - как выставлены куки, если не http-онли, то значит я могу их поправить?

И? Как ты поставишь нужную куку, что бы тебе разрешили чужой id редактировать? Как ты ее узнаешь.

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

Это кто так делает? ;) В куках ID сессии или шифрованная кука.

я не знал этой особенности когда проходил последнее собеседование. было забавно. плохо то - что это был один из основных вопросов в компании N.

Три года назад точно так делал один из сайтов новостных в Казани )

Ну печально, чо ;) Токен тебя в таком случае никак не спасет. Атакующий подменит куку, получит новый токен и привет.

М.... почему все используют btree и редкто используют hash индекс, и когда его стоит использовать ;)

вообще интересно было бы услышать сложные вопросы которые поставили вас в тупик на собеседовании

Я обычно напарываюсь на впоросы из серии "случается раз в 10 проектов"