The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Результаты анализа системой Coverity безопасности и качества..., opennews (??), 25-Фев-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


62. "Результаты анализа системой Coverity безопасности и качества..."  +4 +/
Сообщение от Xasd (ok), 25-Фев-12, 22:40 
интересно что используя нормальные Фрэймворки -- довольно сложновато допустить: CSRF, SQL-Inj, XSS

1. CSRF

...например -- в Django сделать CSRF ошибку -- по сути можно только если НАСИЛЬНО отключить CsrfViewMiddleware

[отключают CsrfViewMiddleware (и их аналоги) в своих проектах -- только глупышки наподобие Александра Соловьёва -- https://bitbucket.org/piranha/byteflow/src/0109284f9a8d/sett... ]

2. SQL-Inj

а допустить SQL-Inj -- ТРУДНО и в случае Объектно-Реляционного-Отображения (ORM) и в случае DB-API

[зато очень ЛЕГКО допустить SQL-Inj -- в PHP при традиционном использовании там MySQL]

3. XSS

создание XSS -- опятьже -- довольно ТРУДНО в Django-подобных-шаблонизаторах, которые поумолчанию всё экранируют, кроме случаев где это не надо

############################## из этого всего делаем вывод ##############################

допускаемые ошибки -- сильно *зависят* от языка и библиотеки. а не только от опыта праграммирования

Ответить | Правка | Наверх | Cообщить модератору

79. "Результаты анализа системой Coverity безопасности и качества..."  –2 +/
Сообщение от ананим (?), 25-Фев-12, 23:42 
>[зато очень ЛЕГКО допустить SQL-Inj -- в PHP

а где сложнее?
>при традиционном использовании там MySQL]

а с MsSQL это будет сложнее сделать?

зыж
это применимо для ЛЮБОГО языка программирования. и СУБД соответсвенно тоже.

ну а для того, кто даже прочитать доку (по-русски!!! не в каждом мсдн найдёшь :D) http://php.net/manual/ru/security.database.sql-injection.php не удосужился,... конечно пыхпых виноват.
странно что они в этом ещё сиквел-сервера не обвиняют. а то выдают понимаешь ли секюрную инфу всем подряд.
а сравненние фрэйворком с языками программирования... и не знаю как это назвать.

Ответить | Правка | Наверх | Cообщить модератору

83. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от VoDA (ok), 26-Фев-12, 00:32 
>>[зато очень ЛЕГКО допустить SQL-Inj -- в PHP
> а где сложнее?

В java через JPA или любые языки работающие с SQL через связанные переменные.

Ответить | Правка | Наверх | Cообщить модератору

91. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от ананим (?), 26-Фев-12, 01:29 
Ха! Через.
А jdbc там ужО отменили?
Через <подставь_нужное> можно и в <подставь_любой_язык>.
А можно даже свои фильтры написать.

Зыж
Когда в языках запретят прямой доступ к данным, тогда и придёт апокалепсис.

Ответить | Правка | Наверх | Cообщить модератору

94. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от VoDA (ok), 26-Фев-12, 02:32 
> Ха! Через.
> А jdbc там ужО отменили?
> Когда в языках запретят прямой доступ к данным, тогда и придёт апокалепсис.

В каком то смысле jdbc уже отменили. в приложении ты можешь запросить работающий EntityManager, а можешь запросить JDBC коннект.

Потому несколько следствий:
1. с точки зрения приложения JPA не обертка поверх JDBC, поскольку приложение не имеет доступа к созданию JPA-инфраструктуры.
2. JPA может быть построен поверх иных нежели JDBC коннектов с системами хранения, в том числе и NoSQL.
3. поскольку все конфигуриврование инфраструктуры идет через архитектора проекта, а на боевых серверах через админа, то даже криворукие программеры не могут применить JDBC коннекты без разрешения архитектора. Коннекторов просто не создано в инфраструктуре.

Ответить | Правка | Наверх | Cообщить модератору

110. "Результаты анализа системой Coverity безопасности и качества..."  –2 +/
Сообщение от ананим (?), 26-Фев-12, 04:40 
>В каком то смысле jdbc уже отменили. в приложении ты можешь запросить работающий EntityManager, а можешь запросить JDBC коннект.

не в каком-то, а в прямом смысле вы передёргиваете.
мягко говоря.
или возможно действительно не знаете о чём говорите (что гораздо хуже) - вот когда в жабе нельзя будет написать приложение, подверженное sql-injection, тогда и будете сравнивать технологии с языками программирования.
но надеюсь я до до такого идиотизма не доживу.

Ответить | Правка | Наверх | Cообщить модератору

111. "Результаты анализа системой Coverity безопасности и качества..."  +1 +/
Сообщение от Xasd (ok), 26-Фев-12, 04:57 
> вот когда в жабе нельзя будет написать приложение, подверженное ...

причём тут "можно" или "нельзя"?

чащще всего ошибки допускаются -- в случаях когда их допустить ПРОЩЩЕ, чем НЕ допускать...

...а в случае когда-же ПРОЩЩЕ НЕ допускать ошибку, чем её допустить -- ошибки допускаются на порядок реже [если не сказать что не допускаются вообще].

выше указаны примеры библиотек/языков -- в которые постронны таким образом что ошибку (SQL-Injection, XSS, CSRF) там прощще НЕ допустить

почему я оперирую термином "библиотека/язык" (а не просто "библиотека") ??? потомучто библиотеки строятся вокруг языка, а не в сферическом вакууме

Ответить | Правка | Наверх | Cообщить модератору

138. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от ананим (?), 26-Фев-12, 12:48 
> причём тут "можно" или "нельзя"?

Что ж. Объясню ещё раз.
Php — это язык. Как и java.
И там и там можно использовать различные технологии и техники.
Включая и те что приводят/не_приводят к sql-injection.
Упомянутый jpa — не язык, а технология.
Сравнивать язык и технологию более некомпетентно, чем тёплое и мягкое.

Ответить | Правка | Наверх | Cообщить модератору

153. "Результаты анализа системой Coverity безопасности и качества..."  –1 +/
Сообщение от Xasd (ok), 26-Фев-12, 14:35 
>> причём тут "можно" или "нельзя"?
> Что ж. Объясню ещё раз.
> Php — это язык. Как и java.
> И там и там можно использовать различные технологии и техники.
> Включая и те что приводят/не_приводят к sql-injection.
> Упомянутый jpa — не язык, а технология.
> Сравнивать язык и технологию более некомпетентно, чем тёплое и мягкое.

хорошо.. чтобы Вы поняли мою мысль -- я спрошу вот так:

    почему в PHP -- те техники которые приводят (провоцируют) к SQL-Inhection -- не удалят из языка? (в других же языках их удалили, или не допустили изначально)

Ответить | Правка | Наверх | Cообщить модератору

155. "Результаты анализа системой Coverity безопасности и..."  –2 +/
Сообщение от arisu (ok), 26-Фев-12, 14:39 
you made my day. no, really!
Ответить | Правка | Наверх | Cообщить модератору

159. "Результаты анализа системой Coverity безопасности и..."  –1 +/
Сообщение от ананим (?), 26-Фев-12, 14:57 
присоединяюсь. :D
Ответить | Правка | Наверх | Cообщить модератору

162. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от ананим (?), 26-Фев-12, 15:08 
> почему в PHP -- те техники которые приводят (провоцируют) к SQL-Inhection -- не удалят из языка? (в других же языках их удалили, или не допустили изначально)

не знаю, почему продолжаю отвечать...
нет таких языков. нет.
в той же жабе без jdbc не будет и jpa.
их отношения примерно такие же как https и tcp/ip.
и они также смешны, как если бы вы утверждали, что https лучше, чем tcp/ip.
зыж
к примеру оракл поддерживает аж 3-и (!!!) драйвера jdbc в актуальном состоянии.
а это единственный поддерживаемый путь получать данные на языке java из субд оракл.
мс также выпускает jdbc драйвера для своей mssql, включая и для linux.
запретить формировать запрос так, как удобно разработчику (не пользователю, повторяю!) НЕЛЬЗЯ.
а то получится "пчёлы против мёда".

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

135. "Результаты анализа системой Coverity безопасности и качества..."  –1 +/
Сообщение от VoDA (ok), 26-Фев-12, 11:42 
>>В каком то смысле jdbc уже отменили. в приложении ты можешь запросить работающий EntityManager, а можешь запросить JDBC коннект.
> или возможно действительно не знаете о чём говорите (что гораздо хуже) -
> вот когда в жабе нельзя будет написать приложение, подверженное sql-injection, тогда
> и будете сравнивать технологии с языками программирования.

Пожалуйста напиши мне пример JavaEE приложения на JPA с возможностью SQL-injection. )))


PS вообще проблема SQL-inject легко могла бы решиться если в СУБД запретить несвязанные переменные. ХЗ есть ли подобная возможность в современных СУБД.


Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

139. "Результаты анализа системой Coverity безопасности и качества..."  +1 +/
Сообщение от ананим (?), 26-Фев-12, 12:52 
Выше уже ответил.

Зыж
И ещё потом удивляются отношения к жабистам, как к курице, которая не птица.
Ззыж
И да, напишиТЕ.
Соблюдайте хоть видимость вашего образования.

Ответить | Правка | Наверх | Cообщить модератору

238. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от Аноним (-), 02-Мрт-12, 23:06 
> PS вообще проблема SQL-inject легко могла бы решиться если в СУБД запретить
> несвязанные переменные.

Это константы запретить?
В java уже запретили что-ли?

Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

190. "Результаты анализа системой Coverity безопасности и качества..."  –1 +/
Сообщение от Tav (ok), 27-Фев-12, 01:19 
Справедливости ради, в jdbc никто не подставляет параметры в sql выражения путем конкатенации строк, для этого есть http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedSt..., исключающий возможность инъекции и улучшающий производительность, за счет того, что разбор выражения выполняется один раз.

API, в котором для подстановки параметров в sql выражения предполагается использовать конкатенацию или другие средства работы со строками, — неимоверный дебилизм.

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

194. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от ананим (?), 27-Фев-12, 04:58 
>Справедливости ради, в jdbc никто не подставляет параметры в sql выражения путем конкатенации строк,

серьёзно? никто-никто? :D
пример (и не откуда-нибудь, а с IBM!!! :D)
http://publib.boulder.ibm.com/html/as400/v4r5/ic2979/info/ja...
...
ResultSet rs = select.executeQuery ("SELECT * FROM "
                + collectionName + dmd.getCatalogSeparator() + tableName);
зыж
согласно вашему пониманию справедливости утверждаю, что в пыхпыхе никто не пользуется конкатенацией при формировании запросов.
все исключительно пользуются переменными привязки, согласно документации
http://www.php.net/manual/en/pdo.prepared-statements.php
$stmt = $dbh->prepare("SELECT * FROM REGISTRY where name = ?");
if ($stmt->execute(array($_GET['name']))) {мwhile ($row = $stmt->fetch()) {print_r($row);}

Ответить | Правка | Наверх | Cообщить модератору

211. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от Tav (ok), 27-Фев-12, 11:15 
В PHP prepared statements добавили позже, следуя примеру JDBC. И да, те, кто изначально испорчен общением с PHP, и в JDBC будут использовать конкатенацию.

В примере IBM в запрос подставляетсе не значение колонки, а имя таблицы — его привязать нельзя. На практике имя таблицы редко получается непосредственно от пользователя (разве что в средствах администрирования), поэтому тут проблемы нет.

Ответить | Правка | Наверх | Cообщить модератору

225. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от ананим (?), 27-Фев-12, 14:40 
> В PHP prepared statements добавили позже, следуя примеру JDBC. И да, те, кто изначально испорчен общением с PHP, и в JDBC будут использовать конкатенацию.

На практике наблюдаю ровно противоположенное — те кто и использовал php  столкнулись и с инжекциями, и с методами их обойти.
А вот  спорченные жабой даже не задумываются и верят что очередная жпа их спасёт.
И за примерами ходить далеко не надо — тут, на опеннете пишут, что в жабе нет меморилик, нет sql-injection и тд.
И пишут код соответсвенно.

Ответить | Правка | Наверх | Cообщить модератору

213. "Результаты анализа системой Coverity безопасности и качества..."  +/
Сообщение от Yankee (??), 27-Фев-12, 12:40 
Вы бы уж говорили за себя. Потрудитесь почитать следующее:
http://codeigniter.com/user_guide/libraries/input.html
Очень познавательно будет для Вас расширить кругозор и не тявкать впредь не удосужившись погуглить, как с этим XSS (ипрочими) эффективно борятьсяв толковых фреймворках.
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру