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

Рейтинг самых опасных ошибок, зафиксированных в 2009 году, opennews (?), 17-Фев-10, (0) [смотреть все] Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-, Zenitur (?), 23:13 , 17-Фев-10, (1) –4 // Угу А установка SElinux делает Windows намного безопаснее Там немалая часть уязв, XoRe (ok), 23:22 , 17-Фев-10, (2) // Вы забыли про сотни обновлений для IE, WMP и NET Достаточно окинуть взглядом с, Zenitur (?), 00:56 , 18-Фев-10, (5) –2 // С этим я не спорю Я просто хочу указать ваше внимание, что все эти уязвимости не, XoRe (ok), 10:08 , 18-Фев-10, (18) И какие сотни обновлений была для поддерживаемых на сегодня ОС MS В 2009 году V, Трухин_Юрий_Владимирович (ok), 12:19 , 20-Фев-10, (64) Вы тогда либо в поиске только ядро Linux выбирайте с минимальными GUI, либо все , Аноним (-), 20:18 , 20-Фев-10, (65) Только по ядру Linux 38 уязвимостей только в ядре за 2009 год Это без всяк, Трухин_Юрий_Владимирович (ok), 22:09 , 20-Фев-10, (67) Посмотрите на усердно вами цитируемом secunia степень опасности этих уязвимостей, Глеб В (?), 23:49 , 20-Фев-10, (70) +1 28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр в we, Глеб В (?), 20:22 , 20-Фев-10, (66) какие веб-приложения в настольных системах читайте внимательно, Трухин_Юрий_Владимирович (ok), 22:10 , 20-Фев-10, (68) это все я пишу в ответ на заявления человека о многих сотнях дыр в виндах в 2009, Трухин_Юрий_Владимирович (ok), 22:11 , 20-Фев-10, (69) Вы ссылались на статистику по числу дыр в Red Hat, а не только в настольных прил, Глеб В (?), 23:52 , 20-Фев-10, (71) Часть из этих ошибок 8212 причина порочной практики программирования, которая, Tav (ok), 23:39 , 17-Фев-10, (3) +6 // хорошо сказано , Cobold (??), 00:51 , 18-Фев-10, (4) // А Oracle не хочет приобрести php , vbv (ok), 02:49 , 18-Фев-10, (8) которая связанна с использованием непоследовательного и непродуманного языка , Deffic (?), 02:48 , 18-Фев-10, (7) +1 // самая больная проблема в PHP -- это mod_php , который ПООЩРЯЕТ помещщение и вып, polymorphm1 (ok), 03:40 , 18-Фев-10, (12) +1 Проблема не в SQL Все нормальные API для работы с SQL работают так запрос с па, Tav (ok), 10:42 , 18-Фев-10, (22)   // эта норма пришла скорее от mysql, потому что там изначально небыло компиляции за, Cobold (??), 11:50 , 18-Фев-10, (26)   А если логика запроса посложнее и состоит из 100 вложений инъекций и поведени, Deffic (?), 12:19 , 18-Фев-10, (29)   Это значит, что вам следует пересмотреть модель данных Если подобные запросы вс, Tav (ok), 14:22 , 18-Фев-10, (38)   Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запро, thirteensmay (?), 13:25 , 18-Фев-10, (35)   Имя таблицы 8212 это данные пришедшие из вне Если такое часто нужно, у вас к, Tav (ok), 14:27 , 18-Фев-10, (39)   Нет никаких проблем с моделью данных, есть необходимость динамического построени, thirteensmay (?), 14:50 , 18-Фев-10, (41)   Это все-таки не обычное использование БД, исключение, а не норма Речь о том, чт, Tav (ok), 15:34 , 18-Фев-10, (43) +1   Вот с этим не могу не согласится Моя же речь про то что эти исключительные случ, thirteensmay (?), 16:03 , 18-Фев-10, (45)   Позвольте не согласиться - это как раз НОРМА Если у Вас база нормализована, то п, Deffic (?), 18:25 , 18-Фев-10, (51)   Ошибаетесь Это давно уже норма Время, когда все можно было сделать запросами в, AlexAT (ok), 13:47 , 12-Май-10, (73)   А вот смотрите, не в защиту перла а просто как сравнение на перле с базой работ, Cobold (??), 14:57 , 18-Фев-10, (42)   И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполня, thirteensmay (?), 15:40 , 18-Фев-10, (44)   я не о том что на перле это невозможно, я о том что там в отличии от php при раб, Cobold (??), 17:29 , 18-Фев-10, (47)   а я вам про то что я например, при освоении DBI был весьма озадачен таким подход, thirteensmay (?), 18:35 , 18-Фев-10, (52)   а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых м, Cobold (??), 17:39 , 18-Фев-10, (49)   это всеже не мэйнстрим, в основном то ПО впаривается, посмотрите на туже винду и, thirteensmay (?), 18:04 , 18-Фев-10, (50)   смешивание html-кода и программной логики Можете это хот как-то обосновать,, Deffic (?), 02:51 , 18-Фев-10, (9) // Ну ведь действительно так и есть Смешивание неправильно по сути , Ян Злобин (?), 03:34 , 18-Фев-10, (10) +1 // Неправильно - смешивание данных и кода А смешивание кода и кода - это вопрос вку, Deffic (?), 03:50 , 18-Фев-10, (13) –2 код коду рознь txt-файл это тоже своего рода КОД программа например при печа, polymorphm1 (ok), 04:06 , 18-Фев-10, (15) +3 Текстовый файл не содержит инструкций, которые нужно выполнить в идеале t n, Deffic (?), 04:35 , 18-Фев-10, (16) –1 http ru wikipedia org wiki Управляющий_символсюрприз , Аноним (-), 09:30 , 18-Фев-10, (17) +1 Специалисты меня порвали , Deffic (?), 11:25 , 18-Фев-10, (24) Ваше imho нам понятно В качестве точки зрения могу указать на темы skins , шабл, XoRe (ok), 10:26 , 18-Фев-10, (20) Есть мнение что впендюривание новых шаблонов и тем - туфта гламурных домохозяек,, thirteensmay (?), 12:42 , 18-Фев-10, (32) –2 Это противоречит архитектурному шаблону Model 8211 View 8211 Controller, затру, Tav (ok), 11:00 , 18-Фев-10, (23) // а сколько господ даже здесь рассуждают о языке без намёка на MVC в своих текстах, Cobold (??), 12:03 , 18-Фев-10, (27) MVC никто не отменял , Deffic (?), 12:23 , 18-Фев-10, (30) НеMVC тоже , thirteensmay (?), 12:51 , 18-Фев-10, (33) Согласен Фанатизм - Зло , Deffic (?), 12:57 , 18-Фев-10, (34) я скорее о том что очень многие php программисты или о нём совсем не знают, или , Cobold (??), 14:29 , 18-Фев-10, (40) А вы даже для HelloWorld готовы юзать MVC , AlexAT (ok), 13:50 , 12-Май-10, (74) это верно причём код на PHP можно писать довольно надёжно, но выглядеть такой, polymorphm1 (ok), 03:57 , 18-Фев-10, (14) +1 // gt оверквотинг удален php name_arg stripslashes _GET name href htm, XoRe (ok), 10:34 , 18-Фев-10, (21) // gt оверквотинг удален Смешиваем код с html , Deffic (?), 11:47 , 18-Фев-10, (25) не потомучто смотрите как вы называете свои переменные href -- это например h, polymorphm1 (ok), 03:20 , 20-Фев-10, (62) больше всего нанавижу что люди разработчики функциональных web-страниц -- недо, polymorphm1 (ok), 03:35 , 18-Фев-10, (11) // А чем перехват и подмена кук и ip отличается от подмены HTTP_REFERER , thirteensmay (?), 12:15 , 18-Фев-10, (28) // От подмены IP защитит протокол TCP IP если вы не внедрились в канал связи Пере, Аноним (-), 12:35 , 18-Фев-10, (31) // В т ч может быть сформирован запрос с необходимым HTTP_REFERER И для этого да, thirteensmay (?), 13:31 , 18-Фев-10, (36) Нет Или это дыра в браузере Может быть запрос любой страницы или любого действ, Аноним (-), 16:36 , 18-Фев-10, (46) Какая дыра в браузере Запрос отправляется не из браузера а с сайта злоумышленн, thirteensmay (?), 17:36 , 18-Фев-10, (48) Нет Из браузера Referer сайт злоумышленника Куку не перехватили Всё работает, Аноним (-), 19:04 , 18-Фев-10, (53) Цитирую Referer может подменить клиент, все правильно, но не клиент обычного пол, thirteensmay (?), 19:33 , 18-Фев-10, (54) Не нужен Засветит откуда пришёл Злосайту это не важно Referer может подменить к, Аноним (-), 19:57 , 18-Фев-10, (55) За тем злоклиент на злосайте и нужен чтобы отправить запрос с подмененным рефере, thirteensmay (?), 20:44 , 18-Фев-10, (56) Отправлять запрос злосайт не будет Он показывает страницу Реферер формируется б, Аноним (-), 21:17 , 18-Фев-10, (57) Да злосайт сайтом называется только ради красоты, обычная машинка с доступом к с, thirteensmay (?), 21:39 , 18-Фев-10, (58) Нет Ради определённости Нужны термины для ведения дискуссии Да Нет И то и друг, Аноним (-), 22:13 , 18-Фев-10, (59) Ооо кажись понял, автор имел ввиду использование его кук в рамках понятия CSRF, thirteensmay (?), 22:32 , 18-Фев-10, (60) –1 Да , Аноним (-), 22:40 , 18-Фев-10, (61) да так - давно меня небыло на этом обсуждении, извеняюсь - просто когда я го, polymorphm1 (ok), 03:37 , 20-Фев-10, (63) Распечатать и большим плакатом в программерских развесить для альтернативноодаре, luzers (?), 14:14 , 18-Фев-10, (37) админам составьте пожалуйста ПОЛНЫЙ список из инета, обязательно по категорям я, gHg (?), 09:15 , 04-Июл-11, (75) 1,3,11,37,75

Сообщения

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

	22. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 10:42
	Проблема не в SQL. Все нормальные API для работы с SQL работают так: запрос с параметрами (например "SELECT * FROM table WHERE id = ?") сначала компилируется, а значения параметров подставляются уже при выполнении запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL и делает инъекции невозможными. Для PHP тоже есть такие API, но в PHP построение запросов путем подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные функции предполагают именно такой способ.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	26. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 11:50
	эта норма пришла скорее от mysql, потому что там изначально небыло компиляции запросов, и любая прослойка позволявшая пользоваться переменными по сути ничего кроме конкатенации не делала. А ещё php во все времена имел очень низенькую планочку для IQ разработчика, поэтому им пользуются столько людей которые даже слова "фреймворк" не знают. В принципе, как windows - своей убогостью создал себе огромный рынок.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 12:19
	>Проблема не в SQL. Все нормальные API для работы с SQL работают >так: запрос с параметрами (например "SELECT * FROM table WHERE id >= ?") сначала компилируется, а значения параметров подставляются уже при выполнении >запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL >и делает инъекции невозможными. А если логика запроса посложнее и состоит из 100 вложений ("инъекций") и поведение следующего вложения завязано на результате предыдущего (или нескольких)? Пелёнки всё вырежут? > >Для PHP тоже есть такие API, но в PHP построение запросов путем >подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные >функции предполагают именно такой способ. Разговор был о языках а не о API. При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются в бомбу.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	38. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 14:22
	>А если логика запроса посложнее и состоит из 100 вложений ("инъекций") >и поведение следующего вложения завязано на результате предыдущего (или нескольких)? Это значит, что вам следует пересмотреть модель данных. Если подобные запросы все-таки необходимы в порядке исключения, то и строить их придется аккуратно другим способом, на то оно и исключение. Нормой это быть не может. >Разговор был о языках а не о API. Вместе с языком предоставляется стандартный API. >При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются >в бомбу. Как будто не бывает плохих языков программирования. Понятно, что можно писать надежный код даже на PHP. Проблема в том, что PHP провоцирует порочную практику программирования, как я уже писал выше. Это как Бейсик: студенты изучавшие его, по словам Дейкстры, "подверглись необратимой умственной деградации".
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 13:25
	>Проблема не в SQL. Все нормальные API для работы с SQL работают >так: запрос с параметрами (например "SELECT * FROM table WHERE id >= ?") сначала компилируется, а значения параметров подставляются уже при выполнении >запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL >и делает инъекции невозможными. > >Для PHP тоже есть такие API, но в PHP построение запросов путем >подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные >функции предполагают именно такой способ. Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно. Проблема безопасности заключается в первую очередь не в языках или технологиях, а в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во, специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	39. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Tav (ok), 18-Фев-10, 14:27
	> Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно. Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных. > Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости. Говорит, как минимум, о разгильдяйстве.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 14:50
	> Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных. Нет никаких проблем с моделью данных, есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Кроме разных таблиц там еще куча динамически изменяющихся условий, т.е. and, or, between, case и т.п., ну не реализуется такое плейсхолдерами никак, и модель тут не причем. > Говорит, как минимум, о разгильдяйстве. В некотором плане говорит, не спорю, но смотрите на мир реально, у меня срок реализации фичи - неделя, да я за это время еле-еле только самую основу успею, ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+1 +/–
	Сообщение от Tav (ok), 18-Фев-10, 15:34
	> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Это все-таки не обычное использование БД, исключение, а не норма. Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев. > ни о каком всестороннем анализе безопасности речи сами понимаете быть не может. Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли все сложно?
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 16:03
	>  Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев Вот с этим не могу не согласится. Моя же речь про то что эти исключительные случае весьма бывают, тут один, там другой, вот уже и набралось, приложения нонче весьма не маленькие, особенно если умник какой попадется, ООП, MVC, ORM и пр. на ровном месте городить начнет, вообще туши свет > веб-приложение, так ли все сложно? Не только web. А вообще ведь дело не в том что сложно, а в том что сложнее
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Deffic (?), 18-Фев-10, 18:25
	>> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. > >Это все-таки не обычное использование БД, исключение, а не норма. Речь о >том, что использование запросов с параметрами — норма, а манипуляции со >строками — для исключительных случаев. > >> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может. > >Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли >все сложно? Позвольте не согласиться - это как раз НОРМА. Если у Вас база нормализована, то по другому просто не сделать (или у Вас всё в одной таблице?). Не, ну конечно можно сделать кучу запросов к разным таблицам, потом переварить это перлом или пхп и сделать ещё кучу запросов, и ещё, и ещё... А можно просто написать сложный SELECT и предоставить базе оптимизировать этот SELECT.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	73. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от AlexAT (ok), 12-Май-10, 13:47
	>> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. > >Это все-таки не обычное использование БД, исключение, а не норма. Речь о >том, что использование запросов с параметрами — норма, а манипуляции со >строками — для исключительных случаев. > >> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может. > >Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли >все сложно? Ошибаетесь. Это давно уже норма. Время, когда все можно было сделать запросами вида SELECT * FROM x WHERE y - прошло. Множество запросов строится "на лету", исходя из разношерстных пожеланий пользователя.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	42. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 14:57
	>Проблема безопасности заключается в первую очередь не в языках или технологиях, а >в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во, >специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость >тоже конечно имеет место быть, но вот я лично прекрасно знаю >кучу уязвимостей в своих поделках, но не исправляю их ибо не >до того, не интересно, есть др. задачи, лень, за это не >заплатят, и т.п. что в общем то заметьте не говорит о >моей криворукости. А вот смотрите, не в защиту перла а просто как сравнение: на перле с базой работают через DBI, весь её интерфейс и документация изначально подразумевают компиляцию запросов и исполльзование переменных, и никому не приходится тратить какие-то дополнительные усилия чтобы узнать как работать с ней безопасно (разве что этот кто-то из php пришёл). Почему? - потому что перл не имеет нативных функций для sql , там изначально работают с фреймворками и к этому привыкли, а этот фреймворк был написан не как api wrapper для mysql а как универсальный инструмент для профессиональной работы с базами. И что получается? PHP для той-же самой функциональности требует от разработчика более низкого интеллекта чем перл, в результате новичёк работая с перлом подтянется, а хороший специалист работая с php расслабится и будет писать плохой код, потому что "и так работает". При том что качественный код каких-то дополнительных трудозатрат особо и не требует, это только следствие определённой культуры. Культурному человеку ведь не приходится тратить время чтобы им оставаться?
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	44. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 15:40
	И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполнять, тыщу раз такое видел и сам делал, говорю вам не в инструменте дело, точнее не в первую очередь в инструменте. Качественный продукт к сожалению таки требует дополнительных трудозатрат. А вот про культуру вы хорошо заметили, все прекрасно, но это только в идеальном сферическом мире, а на практике все под елочку ходят когда приспичит. Если тему развивать я вам даже больше скажу, проблема безопасности через деньги вытекает вообще к нашему социально-экономическому строю, с одной стороны производителям зачастую не особо выгодно производить высококачественный продукт, с другой - нанимать на его реализацию "культурных" исполнителей, ибо качество дорого, а культура капризна. Основной принцип - руби бабло, промышленный подход, так что качество (безопасность) второстепенны, если конечно вы не рубите бабло на безопасности ;)
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 17:29
	я не о том что на перле это невозможно, я о том что там в отличии от php при работе с базой наиболее лёгкий и удобный способ одновременно является и более безопасным, и при этом приучает делать более качественный код. Может быть в этом главная слабость php - он реализует очень много функциональности на уровне языка вместо того чтобы стимулировать развитие более качественных фреймворков, а все эти стандартные расширения практически монополизируют свою функцию, какому-то конкурирующему решению очень сложно пробиться. P.S. ещё раз, я здесь имею в виду только DBI и отдельные особенности перла, не говорю про весь язык и всё что на нём написанно.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 18:35
	а я вам про то что я например, при освоении DBI был весьма озадачен таким подходом, особенно когда узнал что mysql не поддерживал хранимых запросов, и в результате чтобы не выписывать каждый раз такие кренделя написал функцию execute_query() в которую передавал динамически собираемую строку запроса. Даже если бы mysql поддерживал то всеравно бы написал, ибо в результате проще, кода меньше, на тот момент я был таков, писал кода в день в три раза больше чем сейчас и просил за это крохи, а теперь что, пока доку три раза прочтешь, пока подумаешь, спланируешь, ошибки обработаешь и т.п. пацан молодой какой нить уже 10 раз все сделает за в три раза меньшие деньги, вот и подумайте кого выберет современный массовый работодатель производитель всякого ширпотреба ? Незнаю, возможно я и не прав, можете убеждать меня дальше, но считаю что инструменты тут дело далеко десятое.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от Cobold (??), 18-Фев-10, 17:39
	а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых местах водятся очень даже культурные клиенты которые готовы доплатить небольшой бонус за качество чтобы потом не потерять бóльшие деньги
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	50. "Рейтинг самых опасных ошибок, зафиксированных в 2009 году"	+/–
	Сообщение от thirteensmay (?), 18-Фев-10, 18:04
	это всеже не мэйнстрим, в основном то ПО впаривается, посмотрите на туже винду или офис, куча красочных перделок, мало кому нужных и зачастую даже бесплатных.
	Ответить | Правка | Наверх | Cообщить модератору

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

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