1.1, Zenitur (?), 23:13, 17/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.
| |
|
2.2, XoRe (ok), 23:22, 17/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Анализ был составлен по данным статистики обновлений безопасности MS Windows XP-7.
Угу.
А установка SElinux делает Windows намного безопаснее)
Там немалая часть уязвимостей относится к безопасности в web.
На основании каких данных был сделан вывод о Windows, если не секрет?
| |
|
3.5, Zenitur (?), 00:56, 18/02/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть от ужаса
| |
|
4.18, XoRe (ok), 10:08, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Вы забыли про сотни обновлений для IE, WMP и .NET. Достаточно окинуть
>взглядом список исправленных уязвимостей в версии 3.5 SP1, чтобы невольно вздрогнуть
>от ужаса
С этим я не спорю)
Я просто хочу указать ваше внимание, что все эти уязвимости не могут быть только на Windows.
Так как там куча уязвимостей, относящихся к web (php, sql, алгоритмы обработки форм).
Так же куча уязвимостей, относящихся к приемам программирования вообще.
Ну и указание на то, что SElinux помогает, как-бы намекает на то, что это не только в Windows)
| |
|
5.65, Аноним (-), 20:18, 20/02/2010 [^] [^^] [^^^] [ответить] | +/– | Вы тогда либо в поиске только ядро Linux выбирайте с минимальными GUI, либо все ... большой текст свёрнут, показать | |
|
|
7.70, Глеб В (?), 23:49, 20/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Только по ядру Linux: 38! уязвимостей только в ядре!!! за 2009 год.
Посмотрите на усердно вами цитируемом secunia степень опасности этих уязвимостей - Less critical или Not critical. Я ни одной даже со статусом Moderately critical (умеренная опасность) не смог найти. Теперь набираем в поиске http://secunia.com/advisories/search/ Windows и видим только за февраль 9 уязвимостей из которых половина имеет статус Highly critical. Теперь я понимаю почему вас не любят на этом форуме, вы упорно подтасовывайте факты.
| |
|
|
5.66, Глеб В (?), 20:22, 20/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр в web-приложениях это вы мощно сравнили.
| |
|
6.68, Трухин_Юрий_Владимирович (ok), 22:10, 20/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>28 дыр дающих удаленно права администратора и 135 Cross Site Scriptirng дыр
>в web-приложениях это вы мощно сравнили.
какие веб-приложения в настольных системах... читайте внимательно
| |
|
|
8.71, Глеб В (?), 23:52, 20/02/2010 [^] [^^] [^^^] [ответить] | +/– | Вы ссылались на статистику по числу дыр в Red Hat, а не только в настольных прил... текст свёрнут, показать | |
|
|
|
|
|
|
|
1.3, Tav (ok), 23:39, 17/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка PHP: построение SQL-запросов путем конкатенации, смешивание html-кода и программной логики, скрипты и файлы с данными вперемешку, изначальное отсутствие пространств имен, "magic quotes hell" (убрали, но каким местом раньше думали), register_globals (понятно, что обычно выключено, но как вообще можно было в здравом уме до такого додуматься).
| |
|
2.7, Deffic (?), 02:48, 18/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
"..которая связанна с использованием непоследовательного и непродуманного языка PHP.."
Если в Вашем тексте PHP заменить на SQL, то смысл не измениться. Всякие там иньекции и т.п.
Но на SQL ни кто не гонит.
На PHP есть масса очень грамотных проектов.
Возможно, всё-таки проблема с руками.
| |
|
3.12, polymorphm1 (ok), 03:40, 18/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
самая больная проблема в PHP -- это mod_php , который ПООЩРЯЕТ помещщение (и выполнение) php-файлов в тойже самой директории что и статические media-файлы..
| |
3.22, Tav (ok), 10:42, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Проблема не в SQL. Все нормальные API для работы с SQL работают так: запрос с параметрами (например "SELECT * FROM table WHERE id = ?") сначала компилируется, а значения параметров подставляются уже при выполнении запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL и делает инъекции невозможными.
Для PHP тоже есть такие API, но в PHP построение запросов путем подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные функции предполагают именно такой способ.
| |
|
4.26, Cobold (??), 11:50, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
эта норма пришла скорее от mysql, потому что там изначально небыло компиляции запросов, и любая прослойка позволявшая пользоваться переменными по сути ничего кроме конкатенации не делала. А ещё php во все времена имел очень низенькую планочку для IQ разработчика, поэтому им пользуются столько людей которые даже слова "фреймворк" не знают. В принципе, как windows - своей убогостью создал себе огромный рынок.
| |
4.29, Deffic (?), 12:19, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Проблема не в SQL. Все нормальные API для работы с SQL работают
>так: запрос с параметрами (например "SELECT * FROM table WHERE id
>= ?") сначала компилируется, а значения параметров подставляются уже при выполнении
>запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL
>и делает инъекции невозможными.
А если логика запроса посложнее и состоит из 100 вложений ("инъекций")
и поведение следующего вложения завязано на результате предыдущего (или нескольких)?
Пелёнки всё вырежут?
>
>Для PHP тоже есть такие API, но в PHP построение запросов путем
>подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные
>функции предполагают именно такой способ.
Разговор был о языках а не о API.
При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются в бомбу.
| |
|
5.38, Tav (ok), 14:22, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А если логика запроса посложнее и состоит из 100 вложений ("инъекций")
>и поведение следующего вложения завязано на результате предыдущего (или нескольких)?
Это значит, что вам следует пересмотреть модель данных. Если подобные запросы все-таки необходимы в порядке исключения, то и строить их придется аккуратно другим способом, на то оно и исключение. Нормой это быть не может.
>Разговор был о языках а не о API.
Вместе с языком предоставляется стандартный API.
>При не умелом обращении оба эти языка (SQL и PHP) одинаково превращаются
>в бомбу.
Как будто не бывает плохих языков программирования. Понятно, что можно писать надежный код даже на PHP. Проблема в том, что PHP провоцирует порочную практику программирования, как я уже писал выше. Это как Бейсик: студенты изучавшие его, по словам Дейкстры, "подверглись необратимой умственной деградации".
| |
|
4.35, thirteensmay (?), 13:25, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Проблема не в SQL. Все нормальные API для работы с SQL работают
>так: запрос с параметрами (например "SELECT * FROM table WHERE id
>= ?") сначала компилируется, а значения параметров подставляются уже при выполнении
>запроса. Такой подход избавляет от необходимости каждый раз выполнять разбор SQL
>и делает инъекции невозможными.
>
>Для PHP тоже есть такие API, но в PHP построение запросов путем
>подстановки переменных или путем конкатенации строк почему-то является нормой, и стандартные
>функции предполагают именно такой способ.
Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно.
Проблема безопасности заключается в первую очередь не в языках или технологиях, а в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во, специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости.
| |
|
5.39, Tav (ok), 14:27, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Все бы было хорошо если бы плейсхолдеры можно было применять в любой части запроса, но это не так, ибо тогда нарушается его план, "select * from ? where..." а такое относительно часто бывает нужно.
Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных.
> Криворукость тоже конечно имеет место быть, но вот я лично прекрасно знаю кучу уязвимостей в своих поделках, но не исправляю их ибо не до того, не интересно, есть др. задачи, лень, за это не заплатят, и т.п. что в общем то заметьте не говорит о моей криворукости.
Говорит, как минимум, о разгильдяйстве.
| |
|
6.41, thirteensmay (?), 14:50, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Имя таблицы — это данные пришедшие из вне? Если такое часто нужно, у вас какие-то принципиальные проблемы с моделью данных.
Нет никаких проблем с моделью данных, есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть. Кроме разных таблиц там еще куча динамически изменяющихся условий, т.е. and, or, between, case и т.п., ну не реализуется такое плейсхолдерами никак, и модель тут не причем.
> Говорит, как минимум, о разгильдяйстве.
В некотором плане говорит, не спорю, но смотрите на мир реально, у меня срок реализации фичи - неделя, да я за это время еле-еле только самую основу успею, ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
| |
|
7.43, Tav (ok), 15:34, 18/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> есть необходимость динамического построения сложных аналитических запросов по всей базе, в зависимости от текущих желаний пользователя, построитель у него есть.
Это все-таки не обычное использование БД, исключение, а не норма. Речь о том, что использование запросов с параметрами — норма, а манипуляции со строками — для исключительных случаев.
> ни о каком всестороннем анализе безопасности речи сами понимаете быть не может.
Увы. Но вы же не криптографическую систему разрабатываете, а веб-приложение, так ли все сложно?
| |
|
8.51, Deffic (?), 18:25, 18/02/2010 [^] [^^] [^^^] [ответить] | +/– | Позвольте не согласиться - это как раз НОРМА Если у Вас база нормализована, то ... текст свёрнут, показать | |
8.73, AlexAT (ok), 13:47, 12/05/2010 [^] [^^] [^^^] [ответить] | +/– | Ошибаетесь Это давно уже норма Время, когда все можно было сделать запросами в... текст свёрнут, показать | |
|
|
|
5.42, Cobold (??), 14:57, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Проблема безопасности заключается в первую очередь не в языках или технологиях, а
>в необходимости тратить на нее дополнительные ресурсы, квалификацию разработчика, их кол-во,
>специализацию, время и т.п., а это дорого, отсюда и проблема. Криворукость
>тоже конечно имеет место быть, но вот я лично прекрасно знаю
>кучу уязвимостей в своих поделках, но не исправляю их ибо не
>до того, не интересно, есть др. задачи, лень, за это не
>заплатят, и т.п. что в общем то заметьте не говорит о
>моей криворукости.
А вот смотрите, не в защиту перла а просто как сравнение: на перле с базой работают через DBI, весь её интерфейс и документация изначально подразумевают компиляцию запросов и исполльзование переменных, и никому не приходится тратить какие-то дополнительные усилия чтобы узнать как работать с ней безопасно (разве что этот кто-то из php пришёл). Почему? - потому что перл не имеет нативных функций для sql , там изначально работают с фреймворками и к этому привыкли, а этот фреймворк был написан не как api wrapper для mysql а как универсальный инструмент для профессиональной работы с базами. И что получается? PHP для той-же самой функциональности требует от разработчика более низкого интеллекта чем перл, в результате новичёк работая с перлом подтянется, а хороший специалист работая с php расслабится и будет писать плохой код, потому что "и так работает". При том что качественный код каких-то дополнительных трудозатрат особо и не требует, это только следствие определённой культуры. Культурному человеку ведь не приходится тратить время чтобы им оставаться?
| |
|
6.44, thirteensmay (?), 15:40, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
И на перл можно каждый раз собирать строку запроса, препарить ее а потом исполнять, тыщу раз такое видел и сам делал, говорю вам не в инструменте дело, точнее не в первую очередь в инструменте. Качественный продукт к сожалению таки требует дополнительных трудозатрат. А вот про культуру вы хорошо заметили, все прекрасно, но это только в идеальном сферическом мире, а на практике все под елочку ходят когда приспичит.
Если тему развивать я вам даже больше скажу, проблема безопасности через деньги вытекает вообще к нашему социально-экономическому строю, с одной стороны производителям зачастую не особо выгодно производить высококачественный продукт, с другой - нанимать на его реализацию "культурных" исполнителей, ибо качество дорого, а культура капризна. Основной принцип - руби бабло, промышленный подход, так что качество (безопасность) второстепенны, если конечно вы не рубите бабло на безопасности ;)
| |
|
7.47, Cobold (??), 17:29, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
я не о том что на перле это невозможно, я о том что там в отличии от php при работе с базой наиболее лёгкий и удобный способ одновременно является и более безопасным, и при этом приучает делать более качественный код. Может быть в этом главная слабость php - он реализует очень много функциональности на уровне языка вместо того чтобы стимулировать развитие более качественных фреймворков, а все эти стандартные расширения практически монополизируют свою функцию, какому-то конкурирующему решению очень сложно пробиться.
P.S. ещё раз, я здесь имею в виду только DBI и отдельные особенности перла, не говорю про весь язык и всё что на нём написанно.
| |
7.49, Cobold (??), 17:39, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
а по поводу безопасности - всё зависит от вашей клиентской группы, в некоторых местах водятся очень даже культурные клиенты которые готовы доплатить небольшой бонус за качество чтобы потом не потерять бóльшие деньги
| |
|
|
|
|
|
2.9, Deffic (?), 02:51, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
"..смешивание html-кода и программной логики.."
Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
| |
|
3.10, Ян Злобин (?), 03:34, 18/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>"..смешивание html-кода и программной логики.."
>Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
Ну ведь действительно так и есть. Смешивание неправильно по сути.
| |
|
4.13, Deffic (?), 03:50, 18/02/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
>>"..смешивание html-кода и программной логики.."
>>Можете это хот как-то обосновать, кроме того, что так удобнее для CMS?
>
>Ну ведь действительно так и есть. Смешивание неправильно по сути.
Неправильно - смешивание данных и кода.
А смешивание кода и кода - это вопрос вкуса.
| |
|
5.15, polymorphm1 (ok), 04:06, 18/02/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Неправильно - смешивание данных и кода.
> А смешивание кода и кода - это вопрос вкуса.
код коду рознь...
txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером -- в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно какую), где дожен перейти на следущую строчку, где поставить пробел, или серию пробелов (\t)...
html-код -- чуть сложнее txt-кода ..
...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...
| |
|
6.16, Deffic (?), 04:35, 18/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Неправильно - смешивание данных и кода.
>> А смешивание кода и кода - это вопрос вкуса.
>
>код коду рознь...
>
>txt-файл это тоже своего рода КОД\программа.. например при печати txt-файла принтером --
>в этом "коде" выраженно где принтер дожен напечатать буковку (и указанно
>какую), где дожен перейти на следущую строчку, где поставить пробел, или
>серию пробелов (\t)...
Текстовый файл не содержит инструкций, которые нужно выполнить (в идеале).
(\t \n и др. это не код, а просто невидимые символы)
>
>html-код -- чуть сложнее txt-кода ..
Дело не в сложности.
>
>...а вообще если применять MVC-шаблон-проектирования -- то "вид" щитают что нужно отделять
>от всего остального ... и неважно что "вид" этот задаётся ТОЖЕ
>кодом (html?) , как и "поведение" и "модель" тоже задаются кодами...
>
IMHO это не нужно рассматривать как правило.
В некоторых случаях проще и эффективнее вставить html в лигику.
Очень, ОЧЕНЬ зависит от задач проекта.
| |
|
7.20, XoRe (ok), 10:26, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>IMHO это не нужно рассматривать как правило.
>В некоторых случаях проще и эффективнее вставить html в лигику.
>Очень, ОЧЕНЬ зависит от задач проекта.
Ваше imho нам понятно)
В качестве точки зрения могу указать на темы (skins), шаблоны (templates).
При разделении выполняемой и показываемой частей, впендюрить новый шаблон или новую тему куда проще.
А при смешивании - это такой гемморой...
Для примера могу указать на скрипты для web-магазина oscommerce.
Там изначально все в перемешку.
И поменять скин там - задачка ещё та.
Так же при этом разделении куда проще сделать переход на другой язык программирования (или на более новую версию текущего языка).
| |
|
|
|
|
3.23, Tav (ok), 11:00, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Это противоречит архитектурному шаблону Model–View–Controller, затрудняет модификацию кода и контроль его корректности.
| |
|
4.27, Cobold (??), 12:03, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
а сколько господ даже здесь рассуждают о языке без намёка на MVC в своих текстах?
| |
|
5.30, Deffic (?), 12:23, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>а сколько господ даже здесь рассуждают о языке без намёка на MVC
>в своих текстах?
MVC никто не отменял.
| |
|
6.40, Cobold (??), 14:29, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
> MVC никто не отменял.
я скорее о том что очень многие php программисты или о нём совсем не знают, или не понимают зачем он им нужен (или не нужен). В большинстве дискуссий это заметно.
| |
|
7.74, AlexAT (ok), 13:50, 12/05/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> MVC никто не отменял.
>
>я скорее о том что очень многие php программисты или о нём
>совсем не знают, или не понимают зачем он им нужен (или
>не нужен). В большинстве дискуссий это заметно.
А вы даже для HelloWorld готовы юзать MVC?
| |
|
|
|
|
|
2.14, polymorphm1 (ok), 03:57, 18/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Часть из этих ошибок — причина порочной практики программирования, которая связанна с использованием непоследовательного и непродуманного языка PHP ...
это верно... причём код на PHP можно писать довольно надёжно, но выглядеть такой код будет ГРАМОЗДКО и НЕВЫНОСИМО...
вот например такой пример:
<?php
$name_arg = stripslashes($_GET['name']);
echo
'<а href="'.htmlspecialchars(
$_SERVER['SCRIPT_NAME'].'?profile='.urlencode($name_arg)
).'">'.
htmlspecialchars('Перейти к профелю: '.$name_arg).
'</а>';
еслибы каждый начинающщий программист изначально зналбы что для того чтобы вывести всеголишь одну HTML-ссылку -- нужно так много PHP-кода (и такие длинные названия функций. конешно ведь небыло пространств имён) , то онбы не стал и начинать изучать PHP...
...становиться понятным что новечку в web (кто только изучает web и PHP) -- кажется что чтобы вывести ссылку нужно всеголишь написать:
<?php
echo
'<а href="'.$_SERVER['SCRIPT_NAME'].'?profile='.$_GET['name'].'">'.
'Перейти к профелю: '.$_GET['name'].
'</а>';
и они думают что это (эта гора ошибок) в одной только PHP-строчке -- это и есть гипкость языка PHP.... охохохохооо... :-(
| |
|
3.21, XoRe (ok), 10:34, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>$name_arg = stripslashes($_GET['name']);
>
>echo
> '<а href="'.htmlspecialchars(
> $_SERVER['SCRIPT_NAME'].'?profile='.urlencode($name_arg)
> ).'">'.
> htmlspecialchars('Перейти к профелю: '.$name_arg).
> '</а>';
>
<?php
$name_arg = stripslashes($_GET['name']);
$href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
$prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
echo '<а href="' . $href . '">' . $prof . '</а>';
?>
не?
| |
|
4.25, Deffic (?), 11:47, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>
>
><?php
>$name_arg = stripslashes($_GET['name']);
>$href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
>$prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
>echo '<а href="' . $href . '">' . $prof . '</а>';
>?>
>
>не?
Смешиваем код с html? ))
| |
4.62, polymorphm1 (ok), 03:20, 20/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>
> <?php
> $name_arg = stripslashes($_GET['name']);
> $href = htmlspecialchars($_SERVER['SCRIPT_NAME'] . '?profile=' . urlencode($name_arg));
> $prof = htmlspecialchars('Перейти к профилю: ' . $name_arg);
> echo '<а href="' . $href . '">' . $prof . '</а>';
> ?>
>
>не?
не! потомучто смотрите как вы называете свои переменные!
$href -- это например "http://www.example.ru/?mode=war&level=danger&page=3"
а после операции htmlspecialchars(...) это уже совсем не $href получается... а чорт-че-чо, которое ужн НЕЛЬЗЯ использовать нигде ниже в программе, кроме как один раз вставить в HTML-код...
...изза таких неправильно названных переменных (а потом РАЗУМЕЕТСЯ их неправильного оиспользования) -- как раз и возникают в PHP-сайтах -- АД-КОВЫЧГ (quote-hell) и различный "e;-и-&-мусор
| |
|
|
|
1.11, polymorphm1 (ok), 03:35, 18/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
больше всего нанавижу что люди (разработчики функциональных web-страниц) -- недооценивают возможность Cross-Site Request Forgery (CSRF) при разработке своих страничек ...
..каждые 9/10 сайтов подвержены "межсайтовой подмене запроса" , и ПОДСТАВЛЕНЫМИ таким образом оказываются ПОЛЬЗОВАТЕЛИ таких сайтов .
...например напишут от твоего имени сообщение на форуме opennet.ru оскорбительного содержания, а ты потом доказывай кому хочешь что просто-навсего opennet.ru не проверяет испочник (HTTP_REFERER) POST-запроса , а следовательно запрос мог быть присланным с ЛЮБОГО другого подставного сайта, но с использованием МОИХ Cookie и моего ip :-( ...
# p.s.: про Opennet -- сказал чисто гипотетически . на самом деле может он и проверяет HTTP_REFERER при принятии POST запроса , этого я не проверял ещё покачто :-)
# p.p.s.:
хорошо хоть "window.XMLHttpRequest" [при использовании XML или JOSN] уже ПОУМОЛЧАНИЮ ЗАЩИЩЁН от CSRF , и web-разработчику не нужно прилогать дополнительные усилия для фильтрования запросов в зависимости от источника (а можно лишь наоборот приложить дополнительные усилия -- чтобы создать дыру в безопасности :-) , но так делать врядли кто захочет ) .
...
...в отличии от статических HTML POST "<form ...></form>" , где если не написать дополнительной строчки кода [проверяющщей HTTP_REFERER] -- то ДЫРА СУЩЕСТВУЕТ какбы ПОУМОЛЧАНИЮ...
| |
|
|
3.31, Аноним (-), 12:35, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
От подмены IP защитит протокол TCP/IP. (если вы не внедрились в канал связи)
Перехват кук так же не возможен при тех же условиях. (нужно хотя бы чтение канала связи)
А для действий от вашего имени на любом сайте, пусть даже защищённом https. Достаточно, чтобы вы перешли по ссылке. А там за вас будет сформирован и отправлен любой запрос, имитирующий любое ваше действие.
| |
|
4.36, thirteensmay (?), 13:31, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ? И для этого даже не придется прослушивать канал связи ?
| |
|
5.46, Аноним (-), 16:36, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>В т.ч. может быть сформирован запрос с необходимым HTTP_REFERER ?
Нет. Или это дыра в браузере. Может быть запрос любой страницы или любого действия на странице другого сайта. Вполне штатная функция. Блокируется лишь там где это явно необходимо.
>И для этого даже не придется прослушивать канал связи ?
Да. Не придется.
| |
|
6.48, thirteensmay (?), 17:36, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Какая дыра в браузере ? Запрос отправляется не из браузера а с сайта злоумышленника. Я не понимаю почему человек считает что если у него перехватили куку то он сможет защититься реферером, он же в плане безопасности по сравнению с куками сопля полная, светиться всем.
| |
|
7.53, Аноним (-), 19:04, 18/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Запрос отправляется не из браузера а с сайта злоумышленника.
Нет. Из браузера. Referer: сайт злоумышленника.
Куку не перехватили. Всё работает и отправляется стандартно.
Referer может подменить клиент, но не другой сайт. В плане безопасности проверка Referer необходима, чтобы удостовериться, что клиент сам выполняет действие.
| |
|
|
|
|
|
|
13.59, Аноним (-), 22:13, 18/02/2010 [^] [^^] [^^^] [ответить] | +/– | Нет Ради определённости Нужны термины для ведения дискуссии Да Нет И то и д... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|
|
1.37, luzers (?), 14:14, 18/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Распечатать и большим плакатом в программерских развесить.
для альтернативноодаренных - заставлять зубрить.
потом спросить за отче наш, гимн СССР и гимн России)
| |
1.75, gHg (?), 09:15, 04/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
админам составьте пожалуйста ПОЛНЫЙ список из инета, обязательно по категорям (языки, назначение программ/алгоритмов,....).
+ >"Отсутствие шифрования конфиденциальных данных, например, хранение номера кредитной карты в БД в открытом виде"
- полуказанно, так даже шифруя их - они могут быть взломаны, или тупо проданы персоналом или владельцем.
----
+ использование скриптов - как формы backdoor под видом ошибок транслятора/JIT или библиотек, тем более если могут выполнять себя динамически(без компиляции/трансляции) вроде интернетовских
| |
|