Скорее всего этому экстремалу не нужно доставать все картинки сразу, а надо по одной.
то есть идея про open() и close() один раз - не одинраз не проканает.
Megas, как-то не вяжется вместе
- лично работал [c] Mongo
- потратить кучу времени на переезд, к примеру, на ту же MongoDB
- На in-memory БД памяти не напасешься
Какое-то из этих утверждений явно не стыкуется с остальными
Etherata, если используется и mysqli_real_escape_string и кавычки, то и не будет ошибок. В этом-то смысл этой функции и заключается. Она корректно форматирует строки, как раз чтобы не было ошибок. А не будет ошибок - не будет и инъекции.
Etherata, чтобы найти инъекцию, надо чтобы запросы сообщали об ошибках.
Если запрос SELECT * FROM users where id = 1; drop table testtable; не сможет выполниться, то он вызовет синтаксическую ошибку. Что будет означать возможность инъекции.
А запрос вида SELECT * FROM users where id = '1; drop table testtable;' ошибку не вызовет. Следовательно, он безопасен.
Но нам надо чтобы ошибка была в любом случае, а не только когда запрос не сработал.
поэтому надо сделать заведомо ошибочный запрос.
Например, SELECT * FROM users where id = 1'
То есть передавать в запрос 1'
Если код сообщает программисту об ошибках, то этим "волшебным словом" можно вполне тестировать на уязвимости.
Примечание: об ошибках код должен сообщать только программисту. А не вываливать, как это принято у вайтишников, все кишки прямо наружу. Потому что сообщение об ошибке - это самое ценное, что только может помочь атакующему.
Etherata, ещё раз.
Я не объясняю что этот вариант "должен" работать.
Я объясняю, что то, что он у вас не работает, не имеет никакого отношения к наличию или отсутствию функции mysqli_real_escape_string
А вы именно из-за неё сюда пришли.
Имя таблицы в данном случае не имеет значения. Оно может быть любым. Дело не в имени, а в том, что если убрать из примера mysqli_real_escape_string, то результат будет тот же самый -
если таблица не удаляется с mysqli_real_escape_string, то и без этой функции она останется на месте
Etherata, по поводу P.S.
Это редкостная чушь.
"Пример инъекции" вообще никак не поможет, по каким местам им ни "проходись". Потому что инъекция, как я уже говорил, это не какое-то заветное слово, которое где ни напиши - везде сразу даст доступ к БД и ключи от квартиры где деньги лежат. Инъекция, как я уже говорил - это SQL. Все время разный. Где не сработает один, сработает другой. Где не сработает другой, надо сидеть трое суток и кропотливо подбирать третий.
А вот так "ну я щас одной левой найду все инъекции, только волшебное слово узнать!" - это совсем уж детсадовского уровня фантазии.
И это при том, что чтобы найти инъекцию, успешная атака ВООБЩЕ не обязательна. Чтобы найти инъекцию, достаточно только показать её возможность. Что и продемонстрировано мной в примере выше. Приведенный запрос уязвим, поскольку позволяет себя модифицировать. А уж какая модификация сработает, а какая - нет, с точки зрения ЗАЩИТЫ мне не интересно.
Etherata, фигня здесь только у кого-то в голове.
Если же голову применить по назначению, то вдруг выяснится, что та же беда будет и без всякой "mysqli_real_escaoe_string". Внезапно, если её совсем убрать, и повторить свои глубокомысленные эксперименты, то таблица testtable тоже останется на месте.
Какой мы сделаем из этого вывод? Что от инъекций защищает не только mysqli_real_escape_string, но даже её отсутствие!
Megas, ну почему же 2-3? тут будет от 2000-3000 до бесконечности.
Только не выигрыш, а наоборот.
Но вообще задавая такой вопрос надо бы конечно хотя бы немного представлять себе варианты решений.
Чтобы правильно задать вопрос, нужно знать большую часть ответа.
Если вы не знаете поляну даже схематически, и для вас все базы на одно лицо, а in-memory БД - это потенциально рассматриваемый вариант, то ответы вам не помогут.
я понимаю.
когда не понял вопроса, вообще никогда не касался предметной области, и не понимаешь ни одного слова в своем же ответе, то действительно, всякая ересь только и вспоминается.
