Первое я написал что crossdomain должен быть разрешен для всех. А не только site1 site2. Как пример вы отдаете игру как embed код для вставки в другой сайт ваш придется этот сайт разрешить если флеш должен с ваших сайтов подгружать какие то данные. Иначе он не сможет сделать запрос. Тут подробнее habrahabr.ru/blogs/web_security/125727/#comment_4139003
Второе. Если на сайте есть XSS генерация ключа тоже не спасет. Например я внедряю код 2 запросов ajax на сайт. Таким образом один запрос идет на форму где юзер получает тоукен, второй на страницу отправки с полученным токеном. И все.
Но если есть XSS защита по рефереру тоже бесполезна.
Вы не оставите, потому что теги фильтруются, защита от xss и в любом нормальном скрипте есть, как видите в форме на хабре тоже только можно определенные теги юзать остальное фильтруется. Так что картинку вы не вставите.
>> откуда у меня на сайте возьмется флеш
А он не на вашем сайте а на моей странице. Это просто скрытый флеш элемент, которого назначение только делать кросс доменные запросы при помощи js. Понимаете? Это так же как будто вы делаете ajax запрос по своему хосту, но тут разница что на хост другой запрос можно сделать. Но как раньше заметил, что это только у тех сайтов у которых crossdomain.xml разрешен для всех. А это кстати сайты многие которые отдают embed код для видео. Так вот у этого флеша(программки скрытой на странице) есть минимальное API для JS. И таким образом я могу сделать следующее. Например API.GET(«site.com», «q=1&q=2») или API.POST(«site.com», «q=1&q=2») и все. Все заголовки HTTP, IP, все те же так как клиент и делает сам запрос, но только! реферер другой, так как флеш ставит сам реферер, вы никак не поставите.
ок, я смоделировал ситуацию при которой генерация токена бесполезна(читайте выше), смоделируйте ситуацию когда вы сможете защиту(по коду выше) обойти, при условии что нет xss, как и раньше и обозначил
я понял, пусть хоть delete_site_and_world.php :)
вы объясните откуда этот тег может взяться например у меня на сайте, при условии что теги фильтруются и нет xss, что в прочем то одно и тоже, как вы внедрите этот код?
понимаете я проверяю реферер чтобы все запросы шли только с моего сайта и все, например так if (parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) die;
каким образом вы вставите мне на сайт site.com/delete_my_account.php? я ведь написал при условии что нет xss(и подобного рода внедрений)
>> А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
вы не поняли, пользователь и есть агент он не меняется никак, флеш служит только как средство кроссдоменных запросов при помощи js, единственное что не так будет при таком запросе только реферер, остальное все как обычно
при условии что нет xss, то просто проверка реферера намного безопаснее в ряде случаев чем генерация ключа, так как если у вас на сайте используется crossdomain.xml можно совершить несколько запросов на интересующие страницы страницы клиентом пользователя при помощи флеш
например идет скрытый запрос на страницу с формой, ключ клиенту записывается например в сессию, потом идет второй с ложными данными на страницу обработки формы и ключ подходит
а с проверкой реферера это не получиться, с проверкой реферера без xss провести csrf не получиться, так что не вводите в заблуждение что просто проверка реферара это самый легкий способ, как показывает практика это самый надежный способ
Потому что схему кидка вы не можете просто по определению предугадать. Я лично знаю 5 разных вариантов треугольника описанного в статье, так как я фрилансер и приходится постоянно защищаться. Нужно просто выбрать верный способ защиты для каждой ситуации, в большинстве случаев это третье лицо — гарант. Протекцию без пароля, репутация клиента и т.д. это ровным счетом 0. Так как это никаким образом не защищает вас например от адекватности поведения человека или то что он передумает по пути. А при сделке через гаранта это не так уж трудно исключить.
Никто не должен напрямую первый переводить. Просто нужно третье лицо. Вы когда юридически что-то заверяете это заверяет третье лицо, правильно? Вы слышали когда нибудь о гарантах? Лучше потратить 1-2 часа чтобы выбрать себе гаранта и заплатить 5-10% от суммы ему. Чем зажмотится и в итоге остаться с голой жопой или наполовину голой.
Проще говоря удостоверится что человек и есть тем с кем вы ведете беседу. Контрольная сумма, понимаете?
Пишем в кипер «Здравствуйте, {Андрей}. Мы с Вами договорились провести сделку обмен {bitcoin на webmoney}. Мой {ICQ xxxxx}. Напишите свой номер ICQ, что удостоверится… бла-бла-бла»
Я против вашей статьи ничего не имею. Я имею возражения по этому поводу «Не 50, так 20. Переводить wmz без кода протекции еще более глупо.»
Так может 100 сразу чего уж там…
Ну так это же очевидно, попросить написать с кипера что-то. Иначе каким образом можно удостоверится что это его акк имеет репутацию? Разве я написал верьте людям на словах?
А разве Makcym написал что-то об переводе без протекции? По моему он сделал замечание что перевод вперед плохо и все.
Существуют разного рода гаранты. Деньги вперед за обещания, не известному человеку это уж извините «лоховской ход»
Вы понимаете что схем существует просто огромное количество и большинство построено на глупом шаге перевода денег вперед. То что вы описали эту схему ничего не изменится, ровным счетом ноль, просто интересно почитать.
А подходить нужно не со стороны знания схем а со стороны как можно большему препятствию проведению любой не стандартной операции. Вы пишите в блог «Информационная безопасность» вот по аналогии с точки зрения ИБ, сначала все гайки закручиваются, а потом если нужно и видно что нет дырки в системе, какая то одна откручивается. А не наоборот, все гайки откручены а когда появилась дырка то одна гайка закручивается.
>>> Соответсвенно менять что-то дольше, так как вы в реальной жизни не сможете обойтись красивыми чистыми классами как doctrine2 навязывает.
А если и сможете все аккуратно делать, то вы будете писать столько сколько пишутся java приложения, по несколько месяцев. Вот теперь скажите кто будет платить за эту сомнительную выгоду? А поскольку sf dev как человек знающий не мало захочет неплохой рейт в час, то как вы думаете кого будет предпочтительнее нанять заказчику разработчика python который пишет быстро! на django или sf2 дэва который не может объяснить почему его проект стоит так же как на django а может и дороже и ему еще нужно больше времени. Вот и все. Тут решит все рынок.
Во-первых в scala можно писать без ФП, или по крайней мере использовать его по минимуму, там ничего сложного нет, не сложнее ruby. Там есть намного сложнее вещи, система типов и т.д. Ну неважно.
Ну я не знаю если для вас сложно разобраться с методами дейплоймента или настройки ну тогда стоит специалиста нанять. Просто вы сравнили установить интерпретатор и установить и настроить сервер приложений. Это как бы завести мопед или перебрать двигатель в нем и завести. Ну это совсем разные задачи. Есть куча хостингов Java, но хороший найти чуть сложнее чем хороший с php найти. Именно чуть.
Я не о сайте визитке говорил(читайте выше) а вообще о фреймворке. Визитку, блог, проще написать на django, чем на symfony. Объясняю почему. К слову, я с sf1 2 года проработал. Так вот, то что вы больше думаете когда пишите это замечательно, но как насчет последующей поддержки? В 3-5!!! раза больше кода получается в вашем приложении по сравнении с django приложением. Код намного больше запутан. Соответсвенно менять что-то дольше, так как вы в реальной жизни не сможете обойтись красивыми чистыми классами как doctrine2 навязывает. Это раз. Теперь взлянем на ситуацию новый программист хочет/нужен прийти в проект но незнает sf2, вы представляете сколько нужно времени чтобы он въехал в этот фреймворк и тогда уже в проект. Вы посчитайте сколько там технологий, если их выучить то это проще 60% технолигий выучить для java веб разработки, и получать 2-3 раза больше денег. Это два. И это ответ почему коммюнити не будет расти как будто какая то революция произошла. А я прекрасно помню как sf2 заявлялся года 1.5 назад. И три. Сравните бенчмарки через apache benchmark например 200 одновременных запросов c общей суммой запросов 10к например. Обычный не очень нагруженный сайт, к которому в один момен может стукнуться 200 пользователей а потом сразу еще 200. И тоже самое с тем же django. И вы увидите что у вас выхода не будет кроме как наставить все кешировать. Varnish и писать для приложения кеши. И это только с самого начала жизни сайта, а что будет потом? Мне такой фреймворк не нужен, придеться только им и заниматься как бы что не просело.
Можете забыть про обычные хостинги для sf2. Вам придется юзать VDS. А если уже такая кухня пошла то легче юзать django например, куча модулей уже готовых, кода в 3!!! раза меньше писать, и фреймворк намного! проще sf2, и быстрее :) Я могу сказать одно, что команда symfony сама себя в такое положение поставила. Делая из скриптового языка, и подхода в программировании, жалкое подобие компилируемой java.
И не сравнивайте мягкое с теплым. Вы сначала скорость сравните scala и php. Если есть куда дейплоить то загрузка тоже сводится до выгрузки .war файла и не надо никаких apt. Сервер приложений для java проектов и скриптовых движок косящий под него, это совсем разные вещи.
Мда… что автора текст, что перевод
Бэкэнд твитера написан на Scala, а оф.сайт Scala тоже!!! на Drupal. Вот это совпадение, о да, у меня счас оргазм будет!!!
Второе. Если на сайте есть XSS генерация ключа тоже не спасет. Например я внедряю код 2 запросов ajax на сайт. Таким образом один запрос идет на форму где юзер получает тоукен, второй на страницу отправки с полученным токеном. И все.
Но если есть XSS защита по рефереру тоже бесполезна.
>> откуда у меня на сайте возьмется флеш
А он не на вашем сайте а на моей странице. Это просто скрытый флеш элемент, которого назначение только делать кросс доменные запросы при помощи js. Понимаете? Это так же как будто вы делаете ajax запрос по своему хосту, но тут разница что на хост другой запрос можно сделать. Но как раньше заметил, что это только у тех сайтов у которых crossdomain.xml разрешен для всех. А это кстати сайты многие которые отдают embed код для видео. Так вот у этого флеша(программки скрытой на странице) есть минимальное API для JS. И таким образом я могу сделать следующее. Например API.GET(«site.com», «q=1&q=2») или API.POST(«site.com», «q=1&q=2») и все. Все заголовки HTTP, IP, все те же так как клиент и делает сам запрос, но только! реферер другой, так как флеш ставит сам реферер, вы никак не поставите.
вы объясните откуда этот тег может взяться например у меня на сайте, при условии что теги фильтруются и нет xss, что в прочем то одно и тоже, как вы внедрите этот код?
понимаете я проверяю реферер чтобы все запросы шли только с моего сайта и все, например так if (parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) die;
>> А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
вы не поняли, пользователь и есть агент он не меняется никак, флеш служит только как средство кроссдоменных запросов при помощи js, единственное что не так будет при таком запросе только реферер, остальное все как обычно
например идет скрытый запрос на страницу с формой, ключ клиенту записывается например в сессию, потом идет второй с ложными данными на страницу обработки формы и ключ подходит
а с проверкой реферера это не получиться, с проверкой реферера без xss провести csrf не получиться, так что не вводите в заблуждение что просто проверка реферара это самый легкий способ, как показывает практика это самый надежный способ
например?
Пишем в кипер «Здравствуйте, {Андрей}. Мы с Вами договорились провести сделку обмен {bitcoin на webmoney}. Мой {ICQ xxxxx}. Напишите свой номер ICQ, что удостоверится… бла-бла-бла»
Так может 100 сразу чего уж там…
Существуют разного рода гаранты. Деньги вперед за обещания, не известному человеку это уж извините «лоховской ход»
А подходить нужно не со стороны знания схем а со стороны как можно большему препятствию проведению любой не стандартной операции. Вы пишите в блог «Информационная безопасность» вот по аналогии с точки зрения ИБ, сначала все гайки закручиваются, а потом если нужно и видно что нет дырки в системе, какая то одна откручивается. А не наоборот, все гайки откручены а когда появилась дырка то одна гайка закручивается.
А если и сможете все аккуратно делать, то вы будете писать столько сколько пишутся java приложения, по несколько месяцев. Вот теперь скажите кто будет платить за эту сомнительную выгоду? А поскольку sf dev как человек знающий не мало захочет неплохой рейт в час, то как вы думаете кого будет предпочтительнее нанять заказчику разработчика python который пишет быстро! на django или sf2 дэва который не может объяснить почему его проект стоит так же как на django а может и дороже и ему еще нужно больше времени. Вот и все. Тут решит все рынок.
Ну я не знаю если для вас сложно разобраться с методами дейплоймента или настройки ну тогда стоит специалиста нанять. Просто вы сравнили установить интерпретатор и установить и настроить сервер приложений. Это как бы завести мопед или перебрать двигатель в нем и завести. Ну это совсем разные задачи. Есть куча хостингов Java, но хороший найти чуть сложнее чем хороший с php найти. Именно чуть.
Я не о сайте визитке говорил(читайте выше) а вообще о фреймворке. Визитку, блог, проще написать на django, чем на symfony. Объясняю почему. К слову, я с sf1 2 года проработал. Так вот, то что вы больше думаете когда пишите это замечательно, но как насчет последующей поддержки? В 3-5!!! раза больше кода получается в вашем приложении по сравнении с django приложением. Код намного больше запутан. Соответсвенно менять что-то дольше, так как вы в реальной жизни не сможете обойтись красивыми чистыми классами как doctrine2 навязывает. Это раз. Теперь взлянем на ситуацию новый программист хочет/нужен прийти в проект но незнает sf2, вы представляете сколько нужно времени чтобы он въехал в этот фреймворк и тогда уже в проект. Вы посчитайте сколько там технологий, если их выучить то это проще 60% технолигий выучить для java веб разработки, и получать 2-3 раза больше денег. Это два. И это ответ почему коммюнити не будет расти как будто какая то революция произошла. А я прекрасно помню как sf2 заявлялся года 1.5 назад. И три. Сравните бенчмарки через apache benchmark например 200 одновременных запросов c общей суммой запросов 10к например. Обычный не очень нагруженный сайт, к которому в один момен может стукнуться 200 пользователей а потом сразу еще 200. И тоже самое с тем же django. И вы увидите что у вас выхода не будет кроме как наставить все кешировать. Varnish и писать для приложения кеши. И это только с самого начала жизни сайта, а что будет потом? Мне такой фреймворк не нужен, придеться только им и заниматься как бы что не просело.
И не сравнивайте мягкое с теплым. Вы сначала скорость сравните scala и php. Если есть куда дейплоить то загрузка тоже сводится до выгрузки .war файла и не надо никаких apt. Сервер приложений для java проектов и скриптовых движок косящий под него, это совсем разные вещи.
Бэкэнд твитера написан на Scala, а оф.сайт Scala тоже!!! на Drupal. Вот это совпадение, о да, у меня счас оргазм будет!!!