Вообще, это логично. Если программист проверяет (a == b) and (b == c), то логично предположить, что все три значения равны. А приравнивание чисел к true нарушает эту логику. При этом значение 55 остаётся истинным. if 55: будет выполняться всегда, как и if True:, т.к. bool(55) == True
Такой логике следуют и Python, и JS. А вот PHP с его приравниванием всего подряд является скорее исключением.
Эти вопросы подходят для оценки рассуждений, но ожидать правильных ответов на все - точно не стоит. Ответы будут знать только те, кто специально заучивал разные вопросы с собесов, в то время как реальные сениоры могут и за 100 лет с некоторыми из особенностей питона не столкнуться. Потому, что большинство этих вопросов - это именно особенности, а не "база".
Вот ещё пример такого вопроса, который может сбить с толку сениоров:
Чем различаются два примера кода и что будет выводить функция:
a = 1
def f(b):
if b:
a = 2
else:
global a
print(a)
a = 1
def f(b):
if b:
global a
else:
a = 2
print(a)
Очевидный ответ про обратное условие - неправильный.
Скрытый текст
В первом случае, будет SyntaxError и функция не создастся.
Во втором примере функция будет выводить 1, пока b истинно, но после первого же вызова с ложным значением b функция начнёт выводить 2, независимо от значения b.
Скрытый текст
global выглядит как часть кода функции, но на самом деле обрабатывается парсером, а не исполняется при вызове функции. Но кому это вообще нужно постоянно помнить?
Несколько дополнений к этому комменту и замечаний по статье:
RCE - вообще не уязвимость, а последствия эксплуатации. В статье смешали внедрение SQL кода и внедрение команд ОС.
В статье не упоминаются использования php://, которые позволяют выполнить RFI без внешнего URL и прочие интересные штуки.
SSTI - внедрение в код шаблона, аналогично другим внедрениям, таким как SQLi. Шаблонизатор сам по себе предполагает использование подготовленных запросов, поэтому уязвимость встречается не так часто. В OWASP такие уязвимости и должны быть, т.к. RCE - слишком обширная категория уязвимостей, собранная по последствиям атаки. SSTI и внедрение команд OS являются одними из наиболее частых уязвимостей, приводящих к RCE.
В статье вообще не представлена SSRF. Настоящая SSRF заключается в возможности отправлять запросы со стороны сервера для извлечения данных и взаимодействия с локалкой сервера. Например, когда сайт позволяет загрузить аватар по URL. В статье вместо этого представлен пример IDOR для не числового ID и действия удаления аккаунта.
По десериализации авторы статьи скорее всего перепутали PHP с питоном. В pickle действительно можно сериализовать деструктор для выполнения кода, но в PHP нужно быть более изобретательным, чтобы найти цепочку гаджетов для RCE (если она вообще есть на целевом сайте)
Вообще, это логично. Если программист проверяет (a == b) and (b == c), то логично предположить, что все три значения равны. А приравнивание чисел к true нарушает эту логику. При этом значение 55 остаётся истинным. if 55: будет выполняться всегда, как и if True:, т.к. bool(55) == True
Такой логике следуют и Python, и JS. А вот PHP с его приравниванием всего подряд является скорее исключением.
Кто-нибудь потом. Это уже не так важно. Суть задачи в том, что оба примера выдают неожиданные результаты, при этом ещё и разные.
Эти вопросы подходят для оценки рассуждений, но ожидать правильных ответов на все - точно не стоит. Ответы будут знать только те, кто специально заучивал разные вопросы с собесов, в то время как реальные сениоры могут и за 100 лет с некоторыми из особенностей питона не столкнуться. Потому, что большинство этих вопросов - это именно особенности, а не "база".
Вот ещё пример такого вопроса, который может сбить с толку сениоров:
Чем различаются два примера кода и что будет выводить функция:
Очевидный ответ про обратное условие - неправильный.
Скрытый текст
В первом случае, будет SyntaxError и функция не создастся.
Во втором примере функция будет выводить 1, пока b истинно, но после первого же вызова с ложным значением b функция начнёт выводить 2, независимо от значения b.
Скрытый текст
global выглядит как часть кода функции, но на самом деле обрабатывается парсером, а не исполняется при вызове функции. Но кому это вообще нужно постоянно помнить?
Несколько дополнений к этому комменту и замечаний по статье:
RCE - вообще не уязвимость, а последствия эксплуатации. В статье смешали внедрение SQL кода и внедрение команд ОС.
В статье не упоминаются использования php://, которые позволяют выполнить RFI без внешнего URL и прочие интересные штуки.
SSTI - внедрение в код шаблона, аналогично другим внедрениям, таким как SQLi. Шаблонизатор сам по себе предполагает использование подготовленных запросов, поэтому уязвимость встречается не так часто. В OWASP такие уязвимости и должны быть, т.к. RCE - слишком обширная категория уязвимостей, собранная по последствиям атаки. SSTI и внедрение команд OS являются одними из наиболее частых уязвимостей, приводящих к RCE.
В статье вообще не представлена SSRF. Настоящая SSRF заключается в возможности отправлять запросы со стороны сервера для извлечения данных и взаимодействия с локалкой сервера. Например, когда сайт позволяет загрузить аватар по URL. В статье вместо этого представлен пример IDOR для не числового ID и действия удаления аккаунта.
По десериализации авторы статьи скорее всего перепутали PHP с питоном. В pickle действительно можно сериализовать деструктор для выполнения кода, но в PHP нужно быть более изобретательным, чтобы найти цепочку гаджетов для RCE (если она вообще есть на целевом сайте)