| 1.3, klalafuda (?), 18:11, 30/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
SQL инжект - да неужели?! Я думал, что уж в 21м то веке народ уже не позволяет себе столь откровенных глупостей в дизайне.. :-/
| | |
| |
| 2.5, VoDA (ok), 18:31, 30/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Если язык это позволяет, то рано или поздно проверка на инжект будет забыта. Человеческий фактор однака )))
| | |
| |
| 3.21, Аноним123321 (ok), 08:54, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Если язык это позволяет, то рано или поздно проверка на инжект будет забыта
>>>проверка на инжект<<<
>>>>проверка<<<<
o_0!!!
какая нафиг проверка? вы что с луны свалились?! :-D
...никакие проверки на инжект никогда не делаются, а просто навсего происходит разделение SQL-кода-выражения на две части -- на само константное-выражение и на аргументы к нему
(в результате чего SQL-константное-выражение остаётся как есть, а аргументы _автоматически_ ЭКРАНИРУЮТСЯ)
и забыть (человеческий фактор) такое сделать -- попросту НЕВОЗМОЖНО :-) :-)
вот объясни -- как можно ПОСЛУЧАЙНОСТИ ЗАБЫТЬ сделать экранизацию в выражении cursor.execute(...) ???, где:
import MySQLdb
conn = MySQLdb.connect(host = "localhost",
user = "testuser",
passwd = "testpass",
db = "test")
cursor = conn.cursor()
animal = 'snake'
name = 'turtle'
cursor.execute("""
UPDATE animal SET name = %s
WHERE name = %s
""", (animal, name))
| | |
| |
| 4.23, Sw00p aka Jerom (?), 09:34, 01/12/2010 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>>вот объясни -- как можно ПОСЛУЧАЙНОСТИ ЗАБЫТЬ сделать экранизацию в выражении cursor.execute(...) ???, где:
пхп открой уважаемый
если ты знаешь что такое SQl injection это не означает что все знают
пс: все уязвимости появились после появления этого долбанного пхп )))
| | |
| |
| 5.25, SubGun (ok), 10:30, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Само собой, виноват именно php))) В убожестве ВАЗ тоже виноваты станки, а не кривые руки производителей.
| | |
| 5.27, klalafuda (?), 11:13, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
> пхп открой уважаемый
> если ты знаешь что такое SQl injection это не означает что все
> знают
> пс: все уязвимости появились после появления этого долбанного пхп )))
В PHP сто лет в обед как есть PDO с вменяемой поддержкой prepared statements. Точно так же как в Perl есть DBI или в Ruby или Python свои аналогичные обвязки. Если кто-то их не использует - это уже сугубо его личные сексуальные трудности и язык здесь бессилен. Любой.
| | |
| |
| 6.33, Sw00p aka Jerom (?), 17:31, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> пхп открой уважаемый
>> если ты знаешь что такое SQl injection это не означает что все
>> знают
>> пс: все уязвимости появились после появления этого долбанного пхп )))
> В PHP сто лет в обед как есть PDO с вменяемой поддержкой
> prepared statements. Точно так же как в Perl есть DBI или
> в Ruby или Python свои аналогичные обвязки. Если кто-то их не
> использует - это уже сугубо его личные сексуальные трудности и язык
> здесь бессилен. Любой.
пр препейред слышали проценты - ибо пхпешники такой тип прогеров (в основном начинающих) которым - лиш бы работало
и плюс виноваты разработчики субд - нахрена допустим в sql разрешать не закрытый многострочный комент ? или ваще нахрена они там сдались коментарии ?
виноваты разработчики API к субд - нахрена создавать небезопасные функции ?
пс: о да о безопасности должен думать проггер бля - а шо человек пишуший API к субд не проггер ? и кто виноват ?
| | |
| |
| 7.34, klalafuda (?), 19:13, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> пс: о да о безопасности должен думать проггер бля - а шо человек пишуший API к субд не проггер ? и кто виноват ?
В реальности же виноват лишь один дурак, которому указали Путь, следуя которым он избавится от указанных проблем как класса. Тогда как он вместо того, чтобы заняться делом, все продолжает с маниакальной настойчивостью искать виноватых. 'Ищите ищите - должон быть' (c) фильм.
| | |
|
|
|
| 4.26, klalafuda (?), 11:10, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> вот объясни -- как можно ПОСЛУЧАЙНОСТИ ЗАБЫТЬ сделать экранизацию в выражении cursor.execute(...) ???, где:
Все зависит от того, что в конечном итоге вызывает этот cursor.execute(sql). Если он транслируется скажем в prepared statement то тут при всем желании инжекта не будет, чтобы не задавалось в animal и name. Просто по-определению. Если же он сам конструирует конечное SQL выражение из шаблона и аргументов, которое потом передает на исполнение - то тут уже it depends. При кривых ручках можно получить все, что угодно, и никакие враперы не помогут.
| | |
|
|
| 2.6, User294 (ok), 18:43, 30/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > SQL инжект - да неужели?! Я думал, что уж в 21м то
> веке народ уже не позволяет себе столь откровенных глупостей в дизайне.. :-/
Ну, кому там не нравились переполнения буфера? Хавайте теперь скуль-иньекции, вполне себе вариант :)
| | |
| |
| 3.10, Ва (?), 20:21, 30/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
SQL - вообще для блонидинок, но "переполнение буфера" - это не к ним, а к архитектуре процессора
| | |
| |
| 4.11, Marbleless (?), 20:52, 30/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>"переполнение буфера" - это не к ним, а к архитектуре процессора
Нет, это чаще всего к Деннису Ричи.
| | |
| |
| 5.24, Sw00p aka Jerom (?), 09:36, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>"переполнение буфера" - это не к ним, а к архитектуре процессора
> Нет, это чаще всего к Деннису Ричи.
а причём тут Ричи ? то что у вас башка не варит за это надо Ричи винить ?
а то что вы даже понятия не имеете как устроена память - что за это Ричи надо винить ?
| | |
| |
| 6.30, Marbleless (?), 14:02, 01/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>а то что вы даже понятия не имеете как устроена память - что за это Ричи надо винить ?
Да ну? Просветите меня, профессор, почему же это переполнение буфера вообще невозможно отследить без специальной аппаратной поддержки, если программа написана на высокоуровневом языке программирования? А то мы, печники, по-своему мыслим.
Большинство прикладных программ на низком уровне с памятью не работают. Переполнение буфера чаще всего возникает из-за отсутствия проверки границ массивов, которая могла бы быть реализована на уровне компилятора, но ее не реализовали в C для выигрыша в производительности. Арифметика указателей осложняет проверку, но можно было бы, например, усложнить указатели, сделав их не обычными числами, а специальными конструкциями, чтобы указывать компилятору, в каких пределах они могут изменяться. Всего этого в языке C нет, даже опционально (как в Фортране, например), и, скорее всего, никогда не будет.
А поскольку большинство программ написано на C, мы с этим будем еще долго жить.
| | |
|
|
|
|
|
| 1.20, gkv311 (ok), 08:14, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А я то думаю, чего я не могу бинарники linphone для win скачать с понедельника с этого сервера ;))...
| | |
| 1.22, ДяДя (?), 09:31, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно. Тоже думал, что в 21-м веке такого не бывает.
Пытался проделать такое с Web-сервисом Java EE приложения на GlassFish-е.
К моему великому сожалению - это оказалось невозможным. Хотя допускаю, что в некоторых jdbc драйверах могут быть дыры, но это маловероятно. Я пробовал jTDS и MS SQl. Всё преобразуется (если не изменяет память) в хранимые процедуры с параметрами, которые создаются непосредственно перед извлечением данных, а потом сразу же выполняются с подстановкой параметра, но все опасные символы автоматически экранированы.
| | |
| |
| 2.28, Аноним (-), 11:38, 01/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
При желании даже JDBC позволяет выполнять SQL запрос, который можно перед этим выстроить без параметров в строке :)
Так что тут тоже всё возможно.
| | |
| |
| 3.29, ДяДя (?), 13:47, 01/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
Конечно :-) Кривыми руками везде можно накосячить.
Это позволяет любое средство обращения к БД через SQL.
Я просто хотел сказать, что строить запрос в коде руками плохо :-) И есть куча средств, чтобы этого не делать. И это вроде всем понятно и известно. Всегда будут находится недокументированные возможности.
| | |
|
|
|
