Комментарии 75
Статья хорошая, хотя лично я ничего нового не узнал.
Насчет загрузки файлов — можно было бы рассказать про возможность вставки PHP кода в тело картинки и подобные техники
Насчет загрузки файлов — можно было бы рассказать про возможность вставки PHP кода в тело картинки и подобные техники
НЛО прилетело и опубликовало эту надпись здесь
Проверки расширения файла путем сравнения строк недостаточно, нужно так же проверять MIME тип файла.
Некоторые даже расширения не проверяют на серверной стороне, а в настройках по умолчанию(?) апача .php работает из любого каталога.
почему недостаточно? Аппач смотрит по расширению, если зааплоадить консольный скрипт у него не будет прав на выполнение да и к онсоли доступ нужен будет для его запуска. Что я упустил?
При определении mime типа считывается часть файла и сравнивается с магическими константами разных типов файлов. Т.е. более точное определение и гарантия, что не смотря на расширение там именно то, что надо.
всё равно не понял. Взлом через аплоад файла, если нет проверки на расширение: загрузили скрипт doorway.php, ввели в браузере путь к нему, скрипт выполнился, сделал какую то гадость. Если есть проверка на расширение: загрузили скрипт doorway.jpg, ввели в браузере путь к нему, получили контент, увидели ошибку в браузере… В чём опасность?
Стоит только отметить, что надо анализировать не mime тип приедший от браузера пользователя, а определенный на стороне сервера соответствующими функциями/библиотеками.
Это весьма частая ошибка. На шаредах периодически вылазят подобные косяки.
Часть бывает так, что файл image.php.jpg выполняется пхп интерпретатором, и тогда туда можно вставлять пхп код
Если вы можете самостоятельно настроить php, то можно отключить ненужные функции которые в умелых руках могут быть небезопасны. в php_ini
disable_functions = phpinfo,popen,exec,system,passthru,proc_open,shell_exec,eval и тд
Хорошая статья про безопасную обработку загружаемых изображений есть на хабре — часть 1, часть 2
disable_functions = phpinfo,popen,exec,system,passthru,proc_open,shell_exec,eval и тд
Хорошая статья про безопасную обработку загружаемых изображений есть на хабре — часть 1, часть 2
«то лучше sha1 » — sha256, так как sha1 broken в 2005 году.
По поводу SQL инъекций обязательно нужно сказать, что с помощью запроса можно считать и записать инфу на диск (при соответствующих настройках). Был знаком с разработчиком, который знал, что у него не фильтруются входные параметры в sql и думал, что с помощью этого максимум можно считать данные из базы. В реальности же можно записать веб-шелл и затем творить все что угодно со взломанной машиной/сайтом.
И уже в третьей статье упоминается Positive Technologies. Какой-то нездоровый интерес…
А сама статья довольна неплоха для тех, кто хочет понять самые основы защиты от взлома, поддерживаю Ваше начинание!
И уже в третьей статье упоминается Positive Technologies. Какой-то нездоровый интерес…
А сама статья довольна неплоха для тех, кто хочет понять самые основы защиты от взлома, поддерживаю Ваше начинание!
если бы читали статью полностью — заметили, что я об этом упомянул (два раза) ;]
А про Positive — я очень многое почерпнул из их документов и блогов сотрудников. По этому ссылаюсь на них.
Благодарю за фидбэк :-)
А про Positive — я очень многое почерпнул из их документов и блогов сотрудников. По этому ссылаюсь на них.
Благодарю за фидбэк :-)
А сама статья довольна неплоха
Ещё бы на эту самую статью кто ссылку поставил… А то сходу не сориентироваться о какой именно речь.
Разве для CSRF нужен JS? Достаточно простой ссылки
Смысл в таких статьях? Это тоже самое, что в 2011 году про взлом WEP статьи писать.
Вы неправы. Новички в веб-программировании легко могут наткнуться на подобные грабли. Лично я часто встречаю сайты, где есть SQL-инъекции, XSS-инъекции. А иногда и пхп-инклуды встречаются (у меня есть привычка в любое поле для ввода информации пытаться ввести кавычку :))) )
Нового ровным счетом ничего. Эта статья не претендует на список 0day уязвимостей. Просто перечень граблей, на которые можно наступить новичкам. Разумеется, всем не новички должны все это знать как свои пять пальцев.
Кстати, я лично знаком с верстальшиком, который подключал шаблоны по методу include($_GET['template']) и очень удивился когда я ввел туда не то что он ожидал
Кстати, я лично знаком с верстальшиком, который подключал шаблоны по методу include($_GET['template']) и очень удивился когда я ввел туда не то что он ожидал
Для DoS атаки не обязательно иметь limit, можно сделать вот так, например:
testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,version(),3,4,5,6,database(),8,9,10,benchmark(10000000, md5(user()))
DoS — Denial Of Service. «Умный» вывод ресурса из строя (в отличии от DDoS). Данная атака производится при возможности выполнения «долгих» запросов или длительном выполнении кода.
Не совсем верно, тупой
ab -n 1000000 -c 1000 example.com вполне может положить сервер (если локально отработает и канал позволит :) )Разница между DoS и dDoS в том, что в первом случае атака идёт из одной точки, а во втором распределённая, причём в обоих она может быть тупой, а может быть умной (недавний dDoS на хабре с запросом на поиск -, имхо, полуумный :) )
А вот лично для меня так упорядоченная инфа — это то, чего мне не хватало. Спасибо, очень рад серии, жду продолжения.
Плюс как-то думал, что CSRF и XSS это совершенно разные атаки и соответственно совершенно разные методы защиты. При первой атаке JS не нужен вовсе, да и вообще на атакуемый сервер ничего не внедряется, а со стороннего сайта (злоумышленника или зараженного через XSS или ещё как) браузер пользователя отправляет на атакуемый запрос, изменяющий его состояние. Задача атакуемого понять, что запрос, изменяющий его состояние, пришёл с левого для него сайта. Простейший способ — проверка HTTP_REFERER, но по разным причинам он может фальшиво срабатывать, посложнее — вставка в запрос «секретного» (индивидуального для пользователя, а то и для запроса) поля
>> но по разным причинам он может фальшиво срабатывать
например?
например?
при условии что нет xss, то просто проверка реферера намного безопаснее в ряде случаев чем генерация ключа, так как если у вас на сайте используется crossdomain.xml можно совершить несколько запросов на интересующие страницы страницы клиентом пользователя при помощи флеш
например идет скрытый запрос на страницу с формой, ключ клиенту записывается например в сессию, потом идет второй с ложными данными на страницу обработки формы и ключ подходит
а с проверкой реферера это не получиться, с проверкой реферера без xss провести csrf не получиться, так что не вводите в заблуждение что просто проверка реферара это самый легкий способ, как показывает практика это самый надежный способ
например идет скрытый запрос на страницу с формой, ключ клиенту записывается например в сессию, потом идет второй с ложными данными на страницу обработки формы и ключ подходит
а с проверкой реферера это не получиться, с проверкой реферера без xss провести csrf не получиться, так что не вводите в заблуждение что просто проверка реферара это самый легкий способ, как показывает практика это самый надежный способ
<img src='http://site.com/delete_my_account.php' />
В итоге имеем абсолютно корректный referrer.
Так что уже лучше использовать код. А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
В итоге имеем абсолютно корректный referrer.
Так что уже лучше использовать код. А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
каким образом вы вставите мне на сайт site.com/delete_my_account.php? я ведь написал при условии что нет xss(и подобного рода внедрений)
>> А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
вы не поняли, пользователь и есть агент он не меняется никак, флеш служит только как средство кроссдоменных запросов при помощи js, единственное что не так будет при таком запросе только реферер, остальное все как обычно
>> А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
вы не поняли, пользователь и есть агент он не меняется никак, флеш служит только как средство кроссдоменных запросов при помощи js, единственное что не так будет при таком запросе только реферер, остальное все как обычно
ну пусть это будет не delete_my_account.php, а delete_post_in_forum.php. Короче любая ссылка выполняющая какие-то действия.
я понял, пусть хоть delete_site_and_world.php :)
вы объясните откуда этот тег может взяться например у меня на сайте, при условии что теги фильтруются и нет xss, что в прочем то одно и тоже, как вы внедрите этот код?
понимаете я проверяю реферер чтобы все запросы шли только с моего сайта и все, например так if (parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) die;
вы объясните откуда этот тег может взяться например у меня на сайте, при условии что теги фильтруются и нет xss, что в прочем то одно и тоже, как вы внедрите этот код?
понимаете я проверяю реферер чтобы все запросы шли только с моего сайта и все, например так if (parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) die;
Надеюсь только на небезопасных скриптах? :)
ок, я смоделировал ситуацию при которой генерация токена бесполезна(читайте выше), смоделируйте ситуацию когда вы сможете защиту(по коду выше) обойти, при условии что нет xss, как и раньше и обозначил
Честно говоря я не понял её смысла. То есть не вижу где там атака. У меня два сайта site1. com и site2.com. На site1.com авторизуются пользователи, а на site2.com лежит, скажем, флэш-игрушка, в которой авторизованным на site1.com пользователям дают бонусы. Для этого я положил в корень site1.com crossdomain.xml и указал в нём site2.com как доверенный. Да, игрушка делает запрос к site1.com, получает ключ формы, заполняет форму и отправляет её. Где здесь атака? Это нормальная функциональность, которую я заложил и в site1.com, и в site2.com, и во флэш-объект. Надо будет — заложу и в JS. Вопрос — где здесь атака, если нет XSS? А если есть, то с таким же успехом XSS может быть на моём сайте и тут реферер не спасёт.
Первое я написал что crossdomain должен быть разрешен для всех. А не только site1 site2. Как пример вы отдаете игру как embed код для вставки в другой сайт ваш придется этот сайт разрешить если флеш должен с ваших сайтов подгружать какие то данные. Иначе он не сможет сделать запрос. Тут подробнее habrahabr.ru/blogs/web_security/125727/#comment_4139003
Второе. Если на сайте есть XSS генерация ключа тоже не спасет. Например я внедряю код 2 запросов ajax на сайт. Таким образом один запрос идет на форму где юзер получает тоукен, второй на страницу отправки с полученным токеном. И все.
Но если есть XSS защита по рефереру тоже бесполезна.
Второе. Если на сайте есть XSS генерация ключа тоже не спасет. Например я внедряю код 2 запросов ajax на сайт. Таким образом один запрос идет на форму где юзер получает тоукен, второй на страницу отправки с полученным токеном. И все.
Но если есть XSS защита по рефереру тоже бесполезна.
Ну если вы сами разрешили кроссдомен для всех, то опять-таки почему это атака? Если XSS то ничего не спасёт :)
Не все так просто. Если бы запретил crossdomain и все. Но нет. Мировые лидеры по видео контенту имеют эту уязвимость, а вы говорите просто закрыть. Закроете одно закроется и другое, я просто тему плотно изучал. Все расписывать тут по крайней мере не охата.
Способ с реферером работает. И не нужны никакие ключи и прочее. Например у меня так в фреймворке.
if ($_SERVER['REQUEST_METHOD'] == 'POST' && (!isset($_SERVER['HTTP_REFERER']) || parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) {
$this->_403()->send();
exit(0);
}
И фиг взломаешь. А то что как вы написали файрвол и т.д. Это конечно понятно, но ориентируюсь на массового пользователя. А если клиент сознательно юзает например tor или чего то еще это его проблемы. У меня например ни разу нареканий по моим сайтам на счет этого не было. Если например хочешь вывести деньги или еще чего важное будь добр, юзай то что и все. Вот и вся философия :)
Способ с реферером работает. И не нужны никакие ключи и прочее. Например у меня так в фреймворке.
if ($_SERVER['REQUEST_METHOD'] == 'POST' && (!isset($_SERVER['HTTP_REFERER']) || parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) {
$this->_403()->send();
exit(0);
}
И фиг взломаешь. А то что как вы написали файрвол и т.д. Это конечно понятно, но ориентируюсь на массового пользователя. А если клиент сознательно юзает например tor или чего то еще это его проблемы. У меня например ни разу нареканий по моим сайтам на счет этого не было. Если например хочешь вывести деньги или еще чего важное будь добр, юзай то что и все. Вот и вся философия :)
P.S. Это атака потому что я могу распарсить страницу получить ваш ключ и отправить его на нужную форму. А если бы проверялся реферер я бы этого сделать не смог. Понимаете? Я могу var html = API.GET(«site.com», «q=1&q=2»); var token = html.match(/input type=«token» value="(.+?)"/)[1]; API.POST(«site.com», «q=1&q=2&token=»+token);
И это все от имени клиента. Вы считаете это не атакой?
И это все от имени клиента. Вы считаете это не атакой?
И где вы это будете парсить? Во флешевом объекте? Он, вроде, к сессии в соседней вкладке доступа не имеет. JS на своем сайте? Аналогично.
Какая соседняя вкладка? Причем тут она, не понял.
JS имеет доступ к флешу(элементу спрятанному на странице). Вы в курсе что на флеше можно реализовать доступ к его объектам из JS?
Ладно рассказываю на пальцах. Flash умеет делать кросдоменные запросы, если домен предоставил ему доступ через crossdomain. Реализовывается программка на флеше которая ничего кроме запросов не умеет но имеет доступ из JS к ее функциям POST и GET уже реализованым в программе и это будет весить 10кб+-. Вы прячете на странице эту флешку. Пользователю достаточно зайти туда и все. Таким образом вы манипулируете непосредственно браузером(клиентом) пользователя. Флеш и есть часть клиента, все заголовки, куки, и прочее от клиента идут по указаному домену автоматом от браузера, кроме реферера это поле флеш сам ставит, все остальное идентично как будто вы зашли с браузера, понимаете?
Как пример обычный плеер. Он и совершает такие действия, например плеер ютуба. Он автоматом когда шлет запрос, то подхватывает все заголовки в том числе куки если они есть для домена/пути куда он шлет этот запрос.
Т.е. если по сути рассматривать это, то это обычный кродоменный ajax, но если вы для обычного кроссдоменного ajax-a должны на своем серевере какой то прокси иметь скрипт как пример, чтоб совершить запрос на другой домен. То в случае с флешем этим прокси он сам и является. Он и есть клиент, который взаимодействует посредством браузера, поэтому и ip и прощее остаются те ми же. В отличие от скрипта где IP уже будет сервера, ну соответсвенно куки никакие не отправляться на скрипт браузером.
JS имеет доступ к флешу(элементу спрятанному на странице). Вы в курсе что на флеше можно реализовать доступ к его объектам из JS?
Ладно рассказываю на пальцах. Flash умеет делать кросдоменные запросы, если домен предоставил ему доступ через crossdomain. Реализовывается программка на флеше которая ничего кроме запросов не умеет но имеет доступ из JS к ее функциям POST и GET уже реализованым в программе и это будет весить 10кб+-. Вы прячете на странице эту флешку. Пользователю достаточно зайти туда и все. Таким образом вы манипулируете непосредственно браузером(клиентом) пользователя. Флеш и есть часть клиента, все заголовки, куки, и прочее от клиента идут по указаному домену автоматом от браузера, кроме реферера это поле флеш сам ставит, все остальное идентично как будто вы зашли с браузера, понимаете?
Как пример обычный плеер. Он и совершает такие действия, например плеер ютуба. Он автоматом когда шлет запрос, то подхватывает все заголовки в том числе куки если они есть для домена/пути куда он шлет этот запрос.
Т.е. если по сути рассматривать это, то это обычный кродоменный ajax, но если вы для обычного кроссдоменного ajax-a должны на своем серевере какой то прокси иметь скрипт как пример, чтоб совершить запрос на другой домен. То в случае с флешем этим прокси он сам и является. Он и есть клиент, который взаимодействует посредством браузера, поэтому и ip и прощее остаются те ми же. В отличие от скрипта где IP уже будет сервера, ну соответсвенно куки никакие не отправляться на скрипт браузером.
С флэшем действительно не работал никогда, но спасибо за объяснение — главное правило усвоил — не ставь на свой домен файл crossdomain.xml, т. к. кроме реферера нет способа понять, что это флэш.
UserAgent насколько помню подменить нельзя.
Все утилиты закрываем от флеша.
Все утилиты закрываем от флеша.
Полностью согласен. На прошлой неделе обратился ко мне знакомый с проблемой, что его компьютер блокировал windows и просит на WMU скинуть 120 грн — человек просто смотрел фильм онлайн, ему на XP подгрузили скрипт через flash, который блокировал все, кроме консоли в безопасном режиме. Подробно о проблеме можно погуглить. Картинка была что-то типа вот этой: book-lab.ru/foto/virus/Windows_zablokirovan.jpg
P.S. По факту Flash и Java у клиента это очень большая уязвимость, а главное не только для клиента. От части рад, что в Linux есть хорошее распределении прав доступа.
P.S. По факту Flash и Java у клиента это очень большая уязвимость, а главное не только для клиента. От части рад, что в Linux есть хорошее распределении прав доступа.
с другого домена без проблем тянутся js файы, этого достаточно чтобы организовать кросдоменный аякс. Чтобы просто слить какие то данные, например куки, достаточно обратиться к скрипту с гет/пост параметром на своём домене.
это будет работать если Access-Control-Allow-Origin: * например стоит, иначе нет
каким образом вы получите html или куки клиента зашедшего на вашу страницу которая обращается на другую страницу? объясните пожалуйста, если не трудно
каким образом вы получите html или куки клиента зашедшего на вашу страницу которая обращается на другую страницу? объясните пожалуйста, если не трудно
не на свою… если есть возможность разместить js код на чужой странице, который будет обращаться к скрипту на вашем домене, то вы можете получить чужие куки.
аа)) ну так это понятно, если есть xss, тогда вообще нет никаких проблем что-то получить, и никакая защита не поможет от csrf
но мы говорили о странице взломщика на которую заходит пользователь и флеш посылает кроссдоменный запрос на другой сайт, вот в чем разница
но мы говорили о странице взломщика на которую заходит пользователь и флеш посылает кроссдоменный запрос на другой сайт, вот в чем разница
т.е. Захожу на сайт злоумышленника, он посылает запрос на вконтакте, если я там был раньше залогинен то сессия активна и скрипт может удалить/друзей, сменить пароль и т.д. — так? Если да, то это обычный CSRF и для него флеш не нужен, всё делается с помощю js или просто нтмл
Речь шла не об одном запросе, а о нескольких с одной страницы, без ведома пользователя. Т.е. заходит пользователь на сайт злоумышленника скрипт делает запрос чтоб получить генерируемый ключ(token) предотвращения csrf и потом делает запрос уже с ключом. А если вы делаете просто запрос то ключа не будет, запрос не пройдет.
Этот тег я могу оставить форуме, гостевой или комментарии у Вас на сайте.
Меня вот тоже заинтересовало: откуда у меня на сайте возьмется флеш, который выполняет все эти JS запросы? Опять же при условии отсутствия более страшных дыр чем CSRF.
Меня вот тоже заинтересовало: откуда у меня на сайте возьмется флеш, который выполняет все эти JS запросы? Опять же при условии отсутствия более страшных дыр чем CSRF.
Вы не оставите, потому что теги фильтруются, защита от 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, все те же так как клиент и делает сам запрос, но только! реферер другой, так как флеш ставит сам реферер, вы никак не поставите.
>> откуда у меня на сайте возьмется флеш
А он не на вашем сайте а на моей странице. Это просто скрытый флеш элемент, которого назначение только делать кросс доменные запросы при помощи 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 и в любом нормальном скрипте есть
Я с самого начала подозревал что Вы не понимаете разницы между CSRF и XSS, теперь вижу что Вы окончательно запутались.
> это только у тех сайтов у которых crossdomain.xml разрешен для всех.
Фу ты блин, я-то думал что действительно о какой-то серьезной уязвимости речь, а тут «раз в год при попутном ветре».
Если не возражаете, я от дальнейшей дискуссии устранюсь.
Я с самого начала подозревал что Вы не понимаете разницы между CSRF и XSS, теперь вижу что Вы окончательно запутались.
> это только у тех сайтов у которых crossdomain.xml разрешен для всех.
Фу ты блин, я-то думал что действительно о какой-то серьезной уязвимости речь, а тут «раз в год при попутном ветре».
Если не возражаете, я от дальнейшей дискуссии устранюсь.
Если надумали слиться то так и скажите, что сморозил херню и все. Вы сначала сами разберитесь как CSRF и XSS связаны а тогда пишите глупости типа. На досуге разберитесь с функцией php.net/htmlentities
и быть может и на ваших сайтах перестанут появляться такие глупости как
и быть может и на ваших сайтах перестанут появляться такие глупости как
Просто не вижу смысла обсуждать с Вами то, о чем Вы не имеете представления.
www.cgisecurity.com/csrf-faq.html#attackperform
www.cgisecurity.com/csrf-faq.html#attackperform
сначала почитай о чем я говорил с VolCh, если ума хватит понять о чем идет речь, то сможешь сделать выводы если не хватит то не лезь в разговор с берелебердой типа img src='http://site.com/delete_my_account.php' которая не имеет к этому никакого отношения
мы не говорили о xss(внедрение произвольного кода) который ты приплел почему то к разговору, а о csrf (поделка запросов пользователя), и если на сайте нет xss, то csrf через проверку по рефереру не получиться, я об этом уже написал пару раз написал и об этом мы говорили. ты влепил какую то хрень типа «Этот тег я могу оставить форуме, гостевой или комментарии у Вас на сайте.» Как ты бля дятел оставишь если символы кодируются например через htmlentities или теги вообще удаляются, любой движок нормальный это делает.
короче, разберись в своей голове, и перечитай разговор тогда что-то отвечай. я лучше тебя понимаю отличия и взаимосвязи между CSRF и XSS. так что гуляй…
мы не говорили о xss(внедрение произвольного кода) который ты приплел почему то к разговору, а о csrf (поделка запросов пользователя), и если на сайте нет xss, то csrf через проверку по рефереру не получиться, я об этом уже написал пару раз написал и об этом мы говорили. ты влепил какую то хрень типа «Этот тег я могу оставить форуме, гостевой или комментарии у Вас на сайте.» Как ты бля дятел оставишь если символы кодируются например через htmlentities или теги вообще удаляются, любой движок нормальный это делает.
короче, разберись в своей голове, и перечитай разговор тогда что-то отвечай. я лучше тебя понимаю отличия и взаимосвязи между CSRF и XSS. так что гуляй…
… глупости как img src='http://site.com/delete_my_account.php'
Не используется и сомневаюсь, что когда либо будет использоваться. Но, как я понял, его назначение как раз разрешить Сross Site Request и он действует по принципу «белого списка». Не вижу причин, если я разрешаю условно-стороннему флэш-объекту делать POST запросы из флэша, запрещать их делать из html/js.
почини картинки пожалуйста. ссылки «не совсем рабочие»
НЛО прилетело и опубликовало эту надпись здесь
Спасибо. Не ново, но вполне познавательно и структурировано.
Написано очень поверхностно и сумбурно. Будто бы читаю: «смотрите, я знаю что такое XSS, SQLi, CSRF и DDoS, да!». Логика хромает, структура уныла, содержательностью не пахнет. Да и такое ощущение, что автор сам со всем изложенным познакомился где-то вчера, прочитав десяток-другой разрозненных публикаций и копипаст (ну хоть о существовании Positive Technologies узнал), затем помучав себе на радость несколько унылых говнокодерских сайтов.
Очень жаль тех, кто сие прочтёт, и на эти знания потом будет пытаться накладывать что-то ещё, или, не дай бог, удовлетворится только этим.
Объяснение терминов меня вообще убило.
Брр…
Про остальное даже промолчу. Я бы такое отправлял прямиком в трэш.
IMHO, куда полезнее было читать это:
классификация уязвимостей от Open Web Application Security Project
рекомендуемые статьи и книги на сайте Web Application Security Consortium
Даже статья Википедии при SQL-инъекции после этого топика кажется сказкой!
Очень жаль тех, кто сие прочтёт, и на эти знания потом будет пытаться накладывать что-то ещё, или, не дай бог, удовлетворится только этим.
Объяснение терминов меня вообще убило.
SQL inj — SQL инъекция, выполнение несанкционированных запросов
XSS/CSRF — внедрение произвольного JS кода/скрипта в страниц
Брр…
Про остальное даже промолчу. Я бы такое отправлял прямиком в трэш.
IMHO, куда полезнее было читать это:
классификация уязвимостей от Open Web Application Security Project
рекомендуемые статьи и книги на сайте Web Application Security Consortium
Даже статья Википедии при SQL-инъекции после этого топика кажется сказкой!
+1
Топик вообще не о чем.
Минусанул бы топик да нельзя.
Такие посты — позор хабра.
Начнем с того, что, вроде было правило копипасту на хабр не постить — все что я вижу в этом топике заезженно уже на каждом километре, и даже при этом я глубоко сомневаюсь что автор топика знает хотя бы как прочитать файл /etc/passwd через sql-инъекцию.
$hash = sha1($username.':'.$password);
Да ради бога — я солью дамп базы и посмотрю как зашифрован мой пароль, а затем запущу свой рекриптор, суть которого перебрать все возможные варианты хеширования пароля, до тех пор пока полученный рекриптором хеш не будет совпадать с тем что был в базе. И так как $username мне будет известен, то перебор паролей не займет уйму времени.
Еще вариант — тупо прочитаю скрипт и вытащу это «формулу»…
Докапываться можно к каждому предложению в статье.
Топик вообще не о чем.
Минусанул бы топик да нельзя.
Такие посты — позор хабра.
Начнем с того, что, вроде было правило копипасту на хабр не постить — все что я вижу в этом топике заезженно уже на каждом километре, и даже при этом я глубоко сомневаюсь что автор топика знает хотя бы как прочитать файл /etc/passwd через sql-инъекцию.
$hash = sha1($username.':'.$password);
Да ради бога — я солью дамп базы и посмотрю как зашифрован мой пароль, а затем запущу свой рекриптор, суть которого перебрать все возможные варианты хеширования пароля, до тех пор пока полученный рекриптором хеш не будет совпадать с тем что был в базе. И так как $username мне будет известен, то перебор паролей не займет уйму времени.
Еще вариант — тупо прочитаю скрипт и вытащу это «формулу»…
Докапываться можно к каждому предложению в статье.
Ну это замечательно, что Вы культхакер, а Ваш единственный топик про игру, не что иное как топ 100 статей за год.
Нет, правда!
Я думаю не стоит переходить на личности, кто-что умеет. На частоту — да, тема топика изъезжена.
Не стоит кричать «позор тебе, и всему вашему семейству», но как видете, «пипл» поддержал, значит кому-то это интересно.
Нет, правда!
Я думаю не стоит переходить на личности, кто-что умеет. На частоту — да, тема топика изъезжена.
Не стоит кричать «позор тебе, и всему вашему семейству», но как видете, «пипл» поддержал, значит кому-то это интересно.
а я бы минусовал за слова: «Меня (скорее всего) будут минусить» — это явное попрошайничество и социальная инженерия
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ликбез по уязвимостям в веб-приложениях, а также самые частые ошибки разработчиков