Pull to refresh
27
0
Andrei Ilinksii @Tatikoma

CTO

Строго говоря это именно раннеры пинают гитлаб, а не наоборот.

От статьи ощущение, что автор забыл в статью добавить собственно саму статью..

Если там база по типу ACID, MVCC, то не ясно как реализовать процесс именно затирания.

Смотря кому доказывать.

Большое количество компаний работает в минус.. И их тоже надо штрафовать) Кажется кроме оборотных штрафов - понятные меры придумать сложно.

У вас устаревшая информация. PHP умеет работать демоном и обслуживать любое количество запросов не умирая.

По версии кода для человеков, взял пример с памятью и попросил ChatGPT поправить нейминг переменных, результат:

function retrieveMemoryProperties(memoryPrototype, filteredProperties) {
    (memoryPrototype = p),
    (filteredProperties = Object.getOwnPropertyNames(
        Object.getPrototypeOf(window.performance.memory)
    ).filter(function(propertyName, currentPrototype) {
        return (currentPrototype = memoryPrototype), propertyName !== 'constructor';
    })),
    filteredProperties.map(function(propertyName, currentMemoryPrototype) {
        (currentMemoryPrototype = memoryPrototype), memoryPropertiesArray.push(window.performance.memory[propertyName].toString(36));
    });
}

function callRetrieveMemoryProperties() {
    if ((retrieveMemoryProperties(), callCounter++, callCounter === 3)) return void callUnknownFunction();
    setTimeout(callRetrieveMemoryProperties, 55);
}

ИИ так же дал описание того что делает функция:

It's difficult to say exactly what this code does without knowing what the other variables, such as p, c, and h, are and what the e function does. However, I can tell you what this code appears to do in a general sense.

The retrieveMemoryProperties function takes two arguments, memoryPrototype and filteredProperties. memoryPrototype is assigned the value of p, and filteredProperties is assigned the result of filtering the property names of the prototype of the window.performance.memory object. The filtered properties are those whose names are not equal to 'constructor'.

The filtered properties are then mapped over, and for each property, the value of memoryPrototype is assigned the value of p, and the value of the property is pushed onto an array called memoryPropertiesArray as a base-36 string.

The callRetrieveMemoryProperties function calls the retrieveMemoryProperties function, increments a counter callCounter, and checks if it's equal to 3. If it is, it calls an unknown function callUnknownFunction. If not, it sets a timeout to call callRetrieveMemoryProperties again in 55 milliseconds.

Кажется с подсказками ИИ разбирать такой код может быть проще.

Нет, под капотом вызов PQexecParams. Подготовленный запрос при этом не используется.

Раздельная передача запроса и данных не обязательно использует prepared statements. Плейсхолдеры могут работать и без prepared statements. Например pg_query_params так работает.

Произвольный код с привилегиями ядра - означает ли это, что можно с использованием этой CVE реализовать полупривязанный/полуотвязанный jailbreak?

Удалось ли по результатам добавить инспекцию, которая выявляет данный конкретный баг в исходном коде?

Вы что, коллектив хотите бросить? А на кого по-вашему лягут обязанности? /sarcasm

Будет, т.к. это как минимум самоуправство, а как максимум - всё перечисленное в статье.

  1. Блокировки у вас будут в любом случае. 100 запросов в секунду - ничто. По защите - советую ограничить количество регистраций. Вы знаете что у вас за ночь не может зарегистрироваться скажем больше 10 000 пользователей - ровно столько и разрешайте, сверх лимита регистрация только инвайтам.

  2. Потому что перебрать 5% записей быстрее таким способом, а не по индексу. Он несущественен в сумме исполнения запроса.


    3 и 4 пункты - то есть у вас как раз достаточно свободных ресурсов, чтобы не отключать проверку FK.

И еще отдельный комментарий. Каким образом при использовании ORM вы гарантируете отсутствие race condition ?

Как я понимаю в вашем случае возможна следующая ситуация - идет два параллельных процесса:

  1. Пользователь отправляет пост в топик.

  2. Пользователь удаляет топик тот же самый.

Соответственно предполагаю что без внешних ключей базы опираясь только на триггеры ORM мы можем получить следующую ситуацию:

  1. Пришел запрос на добавление нового поста.

  2. Проверяем что указанный в посте топик существует.

  3. Пришел запрос на удаление топика.

  4. Удаляем все посты для выбранного топика.

  5. Завершаем процедуру добавления поста - записываем его в базу.

  6. Завершаем процедуру удаления топика - удаляем его из базы (при наличии FK тут случилась бы ошибка, но у нас её нет).

В зависимости от порядка действий как повезет с их исполнением - FK выдал бы ошибку как при удалении топика (указано в примере), так и аналогично может не пройти процесс записи поста. В результате такого стечения обстоятельств у вас окажется пост без связанного топика.

Как у вас решена данная проблема? Можете ли вы сказать, что ваше решение носит системный характер и ни один из программистов большой команды не забудет написать все нужные проверки? Стали бы вы использовать такой подход при разработке ПО связанного с подсчетом финансов?

Information

Rating
3,840-th
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity