Сервер с JSON API. Как сделать правильно и безопасно.

#json #безопасность #шифрование

                    
Я хочу сделать сервер, который будет отдавать данные в формате JSON. (Как например
у Github.com).
Но проблема в том, что мне необходимо защитить передаваемые данные от перехвата.
Кроме того доступ к некоторым возможностям будет выборочным. (Т.е. нужна аутентификация
и авторизация).
Как это сделать? Можно использовать любые технологии, но желательно не слишком маргинальные.    

Ответы

Ответ 1

Авторизация по сложным паролям-токенам (средствами вашего кода) + HTTPS средствами
apache+mod_ssl.
Естественно, если клиент - браузер рядового пользователя - потребуется валидный сертификат.
Если же использовать нешифрованный протокол - то можно пытаться защитить авторизацию
через хеш на клиенте и рендомную "соль".
Опять таки - все зависит от клиента. Если это браузер - решение должно быть максимально
стандартным. 
Если коммутация сервер-сервер - тогда что угодно, вплоть до v3 SSL auth(обмен сертификатами).

Защита Connection String

#c_sharp #net #безопасность

Вопрос сложный, но хотелось бы услышать аргументированные ответы. 
Суть проблемы: Connection String - способ хранения, как обойтись без нее(если таково
возможно) и подключаться к базе данных (платформа .NET). Такие варианты, как app.config(web.config)
с шифрованием секции, реестр и сам исходный код - не предлагать. WCF и EntityFramework
тоже хранят ее в открытом виде. Как с этой строкой справляются в корпоративном ПО? 

P.S. База данных - на удаленном хосте mySql. Может стоит как-то получать эту строку
через сайт по защищенному каналу?
    

Ответы

Ответ 1

Я не уверен, что вам это нужно. Connection String, как правило, лежит в app.config/web.config.
Конфиг не доступен по сети, локально права на его чтение можно ограничить.

Android. Проверка на регистрацию реального человека(девайса)

#android #безопасность

Есть клиент серверное приложение с регистрацией. Необходимо, чтобы регистрировался
реальный человек(девайс), а не скрипт посылал пост запросы на регистрацию. Как можно
в этом удостовериться? Вроде, есть у девайса аккаунты. И наверняка возможно проверить
как то (например с помощью гугл апи), что девайс и аккаунт соответствуют. Но как это
сделать?
P.S. конкретнее надо сделать так, что бы злодей не смог зарегистрировать много(100+)
аккаунтов.    

Ответы

Ответ 1

Используйте Oauth 2.0 для андроид.
Суть: достаем с девайса аккаунт, генерим для него AccessToken для получения информации
о email. И передаем на сервер этот AccessToken и email аккаунта. На сервера по AccessToken
запрашиваем у гугла email, и если совпадает с тем, что прислал юзер - можно выдавать
свой token, с которым и работать дальше. 

Авторизация
Сама библиотека
Блогозапись, которая может помочь

При возникновении других вопросов - просто гуглите: информации достаточно.


Ответ 2

Доброй ночи!
Можно привязаться к аккаунту Google Play. Таким образом проверять реальность аккаунта
перед запросом на регистрацию. Минусом такого подхода - установка только через гугл плей.
Второй вариант:  перед разрешением любых запросов проводить идентификацию устройства.
Самый простой способ, сгенерировать ХЭШ ключ (передав его на сервер вместе с инфой
о девайсе единственным разрешенным без него методом АПИ), и сохранить его в SharedPreferences
софта, передавать в дальнейшем при каждом запросе к серваку.
Это самые простые два варианта, которые на вскидку приходят в голову


Ответ 3

Мне кажется тут нет способа, основанного на специфики девайса. Но, на мой взгляд,
схема обезопасить себя от массового создания аккаунтов такая:

На момент авторизации ограничить время выполнения запроса (например не чаще 10 секунд
на запрос с одного айпишника)
Провести взаимо-обмен информацией клиента с сервером на основе набора каких-то случайных
правил (и сделать цепочку множественной) например: 


Клиент отправляет серверу свой уникальный номер (любой, IMEI или всё что угодно)




Сервер прибавляет к этому например 10. У сервера и клиента есть параметризованое
дерево вопросов и ответов по которому они обмениваются верными ответами и вопросами
N раз. Если всё верно - то высока вероятность что клиент - это мобильное приложение.


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

Загрузка файла на сервер - баги, уязвимости

#php #javascript #html #безопасность

На моем сайте есть форма для загрузки файла, в которой у пользователя есть возможность,
написав комментарий, прикрепить файл. Загрузку файла я не контролирую: нет ограничения
по размеру, по типу и т.п. 

Что может злоумышленник сделать с такой загрузкой файла, где нет ни каких ограничений? 
Какие есть еще защиты кроме ограничения по размеру, типу?
    

Ответы

Ответ 1

Злоумышленник при заливке произвольного файла к вам на сервер в принципе может все
что угодно. Файл может быть скриптом php или другим видом cgi и дать злоумышленнику
полный доступ на ваш хостинг. А может быть каким нибудь скриптом/выполнимым файлом,
который сработает в браузерах ваших пользователей.

Защита:


Проверять тип файла и не по расширению, а по внутреннему содержимому.
Если это картинки то в браузеры к пользователям они должны  попадать только в виде 
Скрипт загружающий файлы должен исключить наличие символов / и .. в именах файлов.
Что бы через него нельзя было залить файл в произвольную папку на сервере
Папка в которую заливаются файлы должна быть защищена от выполнения скриптов из нее.
Для этого надо в .htaccess в этой папке (для apache) написать следующее:

php_flag engine 0
RemoveHandler .php
AddType "text/html" .php .cgi .pl .fcgi .fpl .phtml .shtml .php2 .php3 .php4 .php5
.asp .jsp
Options -ExecCGI -Indexes


Ответ 2

Самое опасное, что может произойти - удаленное выполнение кода. Это означает, что
злоумышленник может загрузить свой скрипт и запустить его. Что будет в скрипте зависит
только от фантазии злоумышленника.

Я вижу два способа, как убрать данную уязвимость:


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

Как запретить использовать приложение без интернета?

#java #android #android_sdk #безопасность

У меня всё время выполняются запросы, и, если отключить интернет и зайти в приложение,
то всегда краш, а проверки ставить всюду затратно. 

Есть ли универсальное решение?
    

Ответы

Ответ 1

Можно по разному:


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


Проверить же наличие соединения с сетью (не факт, что там есть сам интернет) можно,
согласно en-SO, так:

public boolean isOnline() {
    ConnectivityManager cm =
        (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo netInfo = cm.getActiveNetworkInfo();
    return netInfo != null && netInfo.isConnectedOrConnecting();
}


Также надо добавить спец. разрешение в AndroidManifest.xml:




Ещё момент: если надо проверять именно факт подключённости с интернету (а не подключено-или-подключается)
то использовать надо netInfo.isConnected() вместо  netInfo.isConnectedOrConnecting().



Проверить же есть ли интернет как таковой можно вот так:

public boolean isInternetAvailable() {
    try {
        InetAddress ipAddr = InetAddress.getByName("google.com"); //можно заменить
на к-л другой сайт

        if (ipAddr.equals("")) {
            return false;
        } else {
            return true;
        }

    } catch (Exception e) {
        return false;
    }

}




И не забываем про все нужные разрешения в манифесте:






Ответ 2

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

Как реализовать вход по Pin-коду (отпечатку пальца)

#java #android #безопасность

Скажите, как можно реализовать функционал ввода пароля (PIN четырехзначный) при запуске
приложения? 
А также сделать возможность вместо PIN использовать биометрию. 
Гуглил, но там только реализация в виде вызова в onRestore(), да и то, не слишком понятно
    

Ответы

Ответ 1

Сканер отпечатков пальцев поддерживается Android M.
Краткий алгоритм его реализации таков:

1.Прописываете разрешение: 




2.Получаете экземпляр класса FingerprintManager и вызываете метод authenticate().

3.Реализовываете UI для аутентификации с помощью отпечатков пальцев, используя стандартное
изображение отпечатков пальцев.

Вот мануал в официальной документации и пример.


Ответ 2

Нагуглил пример, в котором в приложение имплементируется стандартный сервис Android
KeyGuard, который привязывается к текущим настрокам безопасности Дройда. Перенести
в свое, думаю, не сложно
https://github.com/googlesamples/android-ConfirmCredential

Пароль с солью (salt+password)

#безопасность #хеширование

Есть ли смысл "солить" пароль несколько раз?
$db_password = $salt.hash_func($salt.hash_func($salt.hash_func($salt.$my_password)))

Или это не повысит эффективность?    

Ответы

Ответ 1

@Knes есть прямой смысл солить несколько раз и использовать несколько разных хэш
алгоритмов. Смысл здесь такой, что радужные таблицы составляются для конкретного хэш
алгоритма, а поскольку соль хранится в открытом доступе то подобрать алгоритм соления
пароля при однократном солении все же можно, а если соление примерно такое:
db_password=hash1(salt1/2+hash2(password+salt2)+salt1/2)

то, чтобы расколотить такую комбинацию нужно сначала провести реверс-инжиниринг кода
(чтобы раскрыть алгоритм соления) и только потом применить радужные таблицы совместно
с брут-форсом.


Ответ 2

Я думаю что здесь большую роль играет длина и сложность самой соли а не количество
раз ее использования.

Где происходит шифрование данных, и где находится ключ tls/ssl?

#безопасность #ssl #https #криптография #tls

Интересует вопрос безопасности https соединения.


Не могу понять, где именно происходит шифрование данных, когда запрашивается какой-нибудь
сайт по https? - В браузере, в операционной системе клиента или вообще на сервере? 
Каким образом передается ключ браузеру, чтобы расшифровать сообщение?  Просто в ответном
сообщении или как-то еще, его же могут перехватить? 
Знает ли браузер алгоритм шифрования? - это открытая информация? Если так, то почему
не используются закрытые алгоритмы (о которых никто не знает), или постоянно меняющиеся,
чтобы злоумышленнику было сложнее разгадать? 

    

Ответы

Ответ 1

Шифрование происходит с обеих сторон. Ведь если шифровать будет
только одна сторона (например только сервер), значит трафик от
другой стороны (от клиента) будет не зашифрован. Его можно будет
подслушать или даже изменить.
Формально никто не передает никому ключ. В протоколе TLS клиент и сервер должны сгенерировать
общий секрет (shared secret), набор из 48 байт. Потом клиент и сервер на основании
общего секрета вычисляют ключи: ключ шифрования клиента и ключ шифрования сервера.
Процедура вычисления ключей из общего секрета стандартная, и задана в описании протокола
TLS. Сервер и клиент знают 2 ключа шифрования, одним шифруют, вторым дешифруют. А теперь
самое интересное - как клиент и сервер вычисляют общий секрет. Это зависит от выбранного
набора шифров:


TLS_RSA_WITH_: В данном случае клиент сам создает общий секрет генерируя 48 случайных
байт. Затем он шифрует их при помощи публичного RSA ключа, который находится в сертификате
сервера. Сервер получает зашифрованные данные, и расшифровывает их при помощи приватного
RSA ключа. Данная схема используется редко.
TLS_DHE_RSA_/TLS_ECDHE_RSA_/TLS_ECDHE_ECDSA_: Здесь используется криптографическая
схема Диффи-Хеллмана (DHE) или ее версия на эллиптических кривих (ECDHE). Суть схемы
такая: сервер и клиент генерируют случайные большие числа (приватные ключи), вычисляют
на их основе другие числа (публичные ключи), и пересылают друг другу. Имея свой приватный
ключ и публичный ключ другой стороны, они вычисляют общий секрет. Третья сторона, которая
прослушивает канал, видит только 2 публичных ключа, и она не может вычислить общий
секрет. После этого все данные, которыми обменивались клиент и сервер для получение
этого ключа подписываются сертификатом сервера (RSA или ECDSA подписи). Если клиент
доверяет сертификату сервера, он проверяет эту подпись, и если она правильная, начинается
уже обмен данными. Это наиболее часто используемая схема.
Есть еще несколько схем, но они используются очень редко или не используются вообще.


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

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


Я упустил/упростил некоторые детали, что бы описать только основные идеи.


Ответ 2

Работает это так:


У сервера и у клиента имеются т.н. сертификаты. Грубо говоря - сертификаты это набор:
публичный ключ (PubKey)+секретный ключ (PrivKey)
В момент установления соединения происходит т.н. handshake-рукопожатие, опять же
грубо говоря в этот момент клиент и сервер обмениваются информацией какие у них сертификаты
и какие алгоритмы шифрования они поддерживают и могут ли они доверять сертификатам
противной стороны. Handshake проходит успешно, если клиент и сервер имеют корневые
сертификаты, которые доверяют сертификатам респондентов.
Если handshake проходит успешно они обмениваются публичными ключами и на их основе
вычисляют сессионный ключ, который вычисляется как sessionKey=sharedKey(PubKeyClient,
PrivKeyServer)==sharedKey(PubKeyServer, PrivKeyClient) - здесь фигурирует функция sharedKey()
- это некий мат.алгоритм, который вычисляет сессионный ключ на основе публичного ключа
респондента и секретного ключа получателя, причем он тождественно равен сессионному
ключу полученному в результате вычисления на основе публичного ключа получателя и приватного
ключа респондента - собственно на этом вся эта математика и строится - иначе ничего
не взлетит
После этапа 3. обе партии имеют одинаковый ключ, который используется для симметричного
шифрования выбранным алгоритмом, который устанавливается во время handshake
Далее каждая сторона шифрует свои запросы сессионным ключом, принимающая сторона
дешифрует его и вуаля.


В реале все намного сложнее - можете почитать хотя бы Википедии

Update


  его же могут перехватить


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


  Знает ли браузер алгоритм шифрования? - это открытая информация?


Да, это открытая информация. В криптографии защита на основе незнания алгоритма шифрования
не считается надежной защитой. Скорее даже наоборот, знание алгоритма - это наоборот
способ защиты - как некая гарантия надежности алгоритма. Существует определенная процедура
как бы сертификации алгоритмов, которая и подтверждает его надежность - то есть устойчивость
к разнообразным атакам. В случае SSL/TLS для обмена ключами используются RSA и DH,
а для обмена в пределах сессии используются симметричные алгоритмы IDEA и AES.

В чем смысл класса Permission в java

#java #безопасность

public class Worker {

private static String path;

public static void main(String[] argv) throws Exception {
    path = "C:\\glassfish-4.1.1\\glassfish4\\README.txt";
    Permission permission = new FilePermission(path, "read");
    try {
        AccessController.checkPermission(permission);
    }catch (Exception e){
        System.out.printf(String.valueOf(e));
    }
    System.out.println(new FileInputStream(new File(path)).read());
}
}


Этот класс вернет что-то похожее на 


  java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\glassfish-4.1.1\glassfish4\README.txt"
"read")84


Почему удалось прочитать из файла, когда прав на это нет!?
    

Ответы

Ответ 1

Для ограничения доступа к файлам в файловой системе используются методы класса File


setExecutable()
setReadable()
setWritable()


Пример, который приводите вы, относится к настройке SecurityManager. Это механизм
который позволяет ограничивать Java приложению доступ к определенным ресурсам (не только
файлам). В качестве примера, возьмем апплеты - SecurityManager не дает им доступа к
файловой системе.

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

Файл у вас прочитался потому что в JDK, по умолчанию, SecurityManager отключен. Проверить
это можно таким образом:

System.out.println(System.getSecurityManager()); // null, если отключен


Запустите приложение с ключом VM -Djava.security.manager и файл у вас прочитать не
получится, до тех пор пока не будет настроена соответствующая security policy. Дефолтные
лежат в $JAVA_HOME/lib/security.

 public static void main(String[] args) throws FileNotFoundException, IOException {
        System.out.println(System.getSecurityManager());
        String path = "D:/test/file.txt";
        check(path, "read,write");
        System.out.println(new FileInputStream(new File(path)).read());
    }

    static void check(String path, String actions) {
        FilePermission perm = new FilePermission(path, actions);

        try {
            AccessController.checkPermission(perm);
        } catch (Exception e) {
            System.out.println(e);
        }
    }


Подробнее смотрите в официальной документации.

Существуют ли вирусы на языках программирования, которые не компилируются в машинных код?

#java #c_sharp #net #безопасность #вирусы

Собственно, интересно, а существуют ли вирусы, которые написаны на какой-нибудь JAVA
или .NET и вообще возможно ли существование?

В минусы подобных платформ можно отнести то, что:


Можно без особых проблем декомпилировать вирус и получить исходных код, что позволит
в кротчайшие сроки получить лекарство
Необходимость Runtime программ. Правда, Microsoft начали по умолчанию поставлять
новые Win с .Net

    

Ответы

Ответ 1

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


Ответ 2

Конечно!

Раньше были очень распространены вирусы на Visual Basic. Например, классический вирус
ILOVEYOU.

Из более старого — макровирусы под Microsoft Office.


Ответ 3

Трояны на .NET вполне себе бывают, сейчас это даже не редкость. Мальварь под Андроид
по большей части как раз на жабе писана. Макро-вирусы сейчас широко используются, там
VBA. Трояны на JS - массовое явление.


Ответ 4

Существует целый класс -- "скрипт-вирусы", которые точно никуда не компилируются,
ЕМНИП скорость написания лекарства не помогает, если вирус расползается быстрее чем
лечится. LoveLetter - за сутки более 2 млн. компьютеров. + многие "бут-вирусы" некоторые
были написаны на javascript c запуском с autorun.html.

Чем плох %n в printf?

#cpp #c #безопасность #инспекция_кода #language_lawyer

http://ideone.com/ffjDAv

#include 

char *names = "Windows\0System\0Config\0";

int main() {
  int l, r;

  for (char *name=names; *name; name+=r-l+1)
    if (printf("Folder: %n%s%n\n", &l, name, &(r=0)), !r)
      break; // Произошла ошибка, вероятно, стоит что-то сделать

  return 0;
}


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

http://ideone.com/xd5SYu

#include 
#include 

char *names = "Windows\0System\0Config\0";

int main() {
  for (char *name=names; *name; name+=strlen(name)+1)
    printf("Folder: %s\n", name);

  return 0;
}


PS: На основе обсуждения в другом ответе.
    

Ответы

Ответ 1

Если потом вместо printf кто-нибудь напишет wprintf - то первый код сломается для
строк, содержащих национальные символы.

Проверка файлов пользователей на вирусы

#php #веб_программирование #безопасность #вирусы

Здравствуйте. Хочу проверять файлы пользователей на вирусы. Во время загрузки или
после - не важно. Как это можно реализовать? Видел подобное на паре файлообменников.
Сам нашел вот это - https://www.virustotal.com/ru/documentation/public-api/ И даже
уже сделал проверку. Но наткнулся на это -


  Usage restrictions The public API can only be used for non-commercial purposes,
always with the idea of helping the community
  in mind. You must make sure you comply with our Best Practices, pay
  special attention to the fact that VirusTotal should not be used for
  antivirus comparatives. Any kind of usage is always bound by our Terms
  of Service. In no event shall you issue any public statement, press
  release, or use VirusTotal's logo, name or trademark on any customer
  list or in any other manner without our prior written consent in each
  instance. If in doubt, please do not hesitate to contact us with your
  particular use case in order to make sure that it is compliant with
  our terms.


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

Ответы

Ответ 1

Посмотрите в сторону ClamAV, это свободное ПО. Довольно часто используется как раз
на почтовых серверах и файлообменниках.

Развернуть его (или другой антивирус) на своем сервере, пожалуй, единственный бесплатный
вариант, если нужно обрабатывать очень большое количество файлов. 

Также можете посмотреть в сторону scanii.com и других подобных площадок, если платные
варианты подходят. Собственно, и у самого virustotal есть платный приватный API, где
нет ограничения в 4 запроса в минуту.

Получить статус chassis intrusion из-под windows

#windows #безопасность #железо #wmi

Возможно ли получить статус chassis intrusion из-под windows? Dell делает это с помощью
WMI, они создают свой namespace и как-то записывают туда значение, а сами предоставляют
скрипты для выборки из этих namespace. Я пробовал смотреть в Win32_SystemEnclosure,
замыкая и размыкая chassis intrusion, но ничего не менялось.
    

Ответы

Ответ 1

Попробовал поиграться с классом WMI Win32_SystemEnclosure. Так вот, при закрытом
корпусе (у меня теперь есть датчик на новом корпусе :) ) запрос wmiServices.InstancesOf
Win32_SystemEnclosure выдаёт (привожу только относящиеся к делу инстансы):

SecurityBreach=3
BreachDescription = NULL
SecurityStatus = 3 


Если же открываю корпус, то, в зависимости от того, далеко ли крышка от датчика:

SecurityBreach=4 или 5
BreachDescription = "Alert" или "Intrusion"
SecurityStatus =1 


Так что вот вам и ответ. У меня не Dell. Мать Asus, производитель корпуса, подозреваю,
не при чём.

TEE vs SharedPreferences в разработке android

#android #безопасность

Вопрос довольно простой - что лучше TEE или настройки приложения sharedPreferences.
На текущий момент я разрабатываю приложение которое связывается с сервером для получения/отправки
данных, короче обычный клиент-сервер. Для того чтобы отправить/получить данные я использую
токены которые хранятся в памяти устройства SharedPreferences. Но на мой взгляд история
с sharedPreferences немного проигрывает потому что при наличии рут доступа можно спокойно
взять все что угодно из памяти устройства. Дальше немного теории:


  Безопасная среда исполнения (Trusted Execution Environment, TEE)
  характеризуется защищенностью, контролем целостности и наличием
  собственной оперативной памяти и пространства хранения. Она
  изолирована от обычной «функционально богатой среды исполнения» (Rich
  Execution Environment, REE), в которой работают операционная система и
  приложения мобильного устройства.


вот ссылка может кому будет интересно почитать про TEE. Этот вопрос задается для
того чтобы понять имеет ли смысл запариться и сделать к примеру авторизацию через отпечаток
пальца или же не мучиться и использовать логин/пароль как и раньше. Так же довольно
интересный вопрос - как например туда забросить данные типа токена или это невозможно.
Возьмем живой пример - приложение для банкинга (Приват24 или Сбербанк не суть) пользователь
выбрал как способ входа приложить свой палец к нужному месту на экране и дальше он
получает доступ к своим счетам. До сегодня я получал всю нужную мне информацию посредством
отправки токена на определенный адрес и все, но при прикладывании пальца дается ли
мне токен или же там как-то иначе все начинает работать? Может кто-то работал с такой
темой и может мне посоветовать куда копать и стоит ли копать вообще :)

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

Ответы

Ответ 1

Я копал. Лучше конечно смотреть в сторону TEE, есть либа RxFingerPrint, которая умеет
с помощью ключа аутентификации отпечатка складывать в защищенный KeyStore данные.

И что немаловажно все сделано в идеологии RxJava - мелочь, а приятно.

Как защититься от чрезмерной “пробивки” адресов через обработчик ajax запросов?

#xss #ajax #безопасность #token #форма

Есть форма, где одно из первых полей сразу после заполнения .on('blur') прозрачно
пробивается через БД сайта — зарегистрирован уже такой, или нет? В зависимости от результата,
прячется или показывается часть полей ниже.
Злодеи могут такой механизм задолбать массовыми запросами, в результате чего типа
получат инфу, которой у них быть не должно — отн. того, кто на сайте есть, а кого нет.
Как пока делаю: в сессии храню кол-во запросов. Если больше N — далее не обрабатываю,
все ответы негативны. Понятно, что можно сессию сбросить, через прокси заходить, через
Тор. Но, наверное, от полномасштабной пробивки это как-то защитит.
Как хочется делать: что-то типа защиты форм, где всякий раз генерится уникальный
токен, который можно использовать только раз.
Вопрос: как «правильно» защититься от совсем уж наглой и массовой пробивки данных
через обработчик ajax запросов?    

Ответы

Ответ 1

Подход с хранением количества запросов для определенных IP адресов как правило защищает
неплохо, да и что-либо другое придумать тут крайне сложно. 
Можно лишь сменить уровень на котором проходит фильтрация и перенести эту задачу
непосредственно на веб сервер. 
Если используете IIS, то есть специальный модуль: Dynamic IP Restrictions module. 
Думаю есть аналоги для Apache

Защита от Self-XSS

#javascript #безопасность #xss

Есть ли какие-нибудь защитные алгоритмы от этой атаки?
    

Ответы

Ответ 1

Self-XSS - один из видов социальной инженерии, при котором словами от жертвы добиваются
того, что он/она самостоятельно выполняет вредоносный javascript-код, путем его копирования
в адресную строку или консоль разработчика.

Бороться можно пробовать только путем инструктажа пользователей. Наподобие:


  Дорогие пользователи! 
  
  Пожалуйста не верьте личным сообщениям, сулящим смерть вашему любимому актеру,
ежели вы немедленно не скопируете в адресную нижеприведенный код, и не нажмете enter.


По другому - никак. Это психология - техническими средствами уж точно тут не поможешь.

node.js: зачем использовать express?

#nodejs #безопасность #шаблонизаторы #jade

Прочитал массу статей, но так и не понял какой смысл привязываться к express и шаблонизаторам?
Не дает ли больше контроля над собственным приложением подход с использованием базовых
модулей node.js как описано в этой книжке

Прежде всего интересует с точки зрения безопасности (в том числе "затруднение" ддос
атаки), а не удобства и времени разработки.
    

Ответы

Ответ 1

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

Что касается контроля. Node.js даёт вообще максимальный контроль за происходящем.
Но, чем более низкоуровневые инструменты ты используешь, тем больше придётся реализовать
самому. Да, это даст максимальную гибкость в тех местах, которые нужны лично тебе.
Но одновременно это значительно увеличит время разработки.

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

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

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

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

Сертификат для KeyStore

#java #android #безопасность #криптография

Создаю хранилище для PrivateKey. В строке     KeyStore.PrivateKeyEntry skEntry =
new KeyStore.PrivateKeyEntry() в функцию PrivateKeyEntry() необходимо передать 2 параметра
один из которых сам приватный ключ, а второй параметр это сертификат. Я не совсем понимаю
как этот сертификат получить имея открытый и закрытый ключ.
Весь кусок кода(строку в которой проблема выделил):

final KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(4096, new SecureRandom());
final KeyPair key = keyGen.generateKeyPair();
KeyStore store = KeyStore.getInstance(KeyStore.getDefaultType());
KeyStore.ProtectionParameter protParam = new KeyStore.PasswordProtection(password.getText().toString().toCharArray());

KeyStore.PrivateKeyEntry skEntry = new KeyStore.PrivateKeyEntry(?????????)

store.setEntry(nickname.getText().toString(), skEntry, protParam);

    

Ответы

Ответ 1

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

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

Точно такую же роль этого удостоверяющего документа в публичной криптографии имеет
цифровой сертификат. В реале цифровые сертификаты генерируют доверенные центры, типа
VeriSign, Thawte и проч. Их подписи распознаются нормальными браузерами и устройствами,
поскольку они могут сверить слепок подписи (fingerprint) со слепками, которые хранятся
в устройствах. Для интереса зайдите в своем Android устройстве в раздел Сертификаты
безопасности - в настройках девайса или в любом настольном браузере в настройках, типа:


. 

Вообще-то сертификация ключа стоит и денег и времени.

В вашем случае, вы сами генерируете на лету пару ключей и поэтому не сможете предъявить
нормальный сертификат. На этот случай предусмотрена генерация т.н. Self Signed Certificate,
то есть сертификата, который вы сами же и подписали своим же ключом. Возвращаясь к
нашему примеру с квартирой, это аналог того, что  - предъявитель ключа пишет расписку,
типа: да, я имярек, мамой клянусь, что это моя квартира :)

Теперь ближе к делу. Вам надо cгенерировать т.н. SelfSigned сертификат стандарта
X.509. Но здесь начинаются проблемы. Реализация класса X509Certificate из коробки подразумевает
его создания только из битового массива или из InputStream, Selfsign реализован, но
почему-то скрыт от широкой общественности. Подробнее об этом здесь

К счастью есть такая либа как Bouncy Castle, в котором это можно относительно легко
сделать.

Но опять же к несчастью, напрямую использовать Bouncy Castle в Android нельзя так
как Google по неизвестным причинам его уже использует в коде Android, но в каком то
урезанном виде, так что 90% Bouncy Castle неработоспособны. То есть при попытке включить
библиотеку Bouncy Castle в ваш код, будет выдана ошибка о задвоении.

Опять же к счастью (мир не без добрых людей) - умные люди написали Spongy Castle
- специальный порт Bouncy Castle для Android'а который избавлен от конфликта имен.

Ну вот теперь:


Импортируем Spongy Castle через Gradle
Читаем как генерировать сертификат


P.S. Уффф... зачем я так много написал? Наверное в честь пятницы

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

Защита от SQL инъекций в jdbc java

#java #безопасность #jdbc #preparedstatement #sql_injection

Часто вижу утверждения, что надо использовать PreparedStatement вместо обычного Statement,
чтобы защититься от sql инъекций. Как он защищает?
    

Ответы

Ответ 1

Коротко, для нетерпеливых:

При использовании Statement строки запроса и значений складываются.

При использовании PreparedStatement имеется шаблон запроса и данные в него вставляются,
с отражением кавычек.

Ниже подробнее с примерами.



Вступление.

Имеем такую простую таблицу с данными.

+-----------+----+--------+
| userName  | id |  pass  |
+-----------+----+--------+
| admin     |  1 |  admin |
| user      |  2 |  pass  |
| chuchelo  |  3 |  elli  |
+-----------+----+--------+


Модель User, будет содержать имя и пароль, а так же метод логин, который спросит
данные с консоли.

class UserLogin {
    String name;
    String pass;

    public UserLogin() {
    }

    public void login()  {
        BufferedReader reader = null;
        try{
            reader = new BufferedReader(new InputStreamReader(System.in));

            System.out.println("user name: ");
            name = reader.readLine();

            System.out.println("pass: ");
            pass = reader.readLine();
       } catch (IOException e) {
            e.printStackTrace();
        }finally {
            if (reader != null)
                try {
                    reader.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
        }
    }




Метод, который будет работать с обычным Statement:

UserLogin user = new UserLogin();
user.login();
try (Connection connect = MyConnection.getConnection()){
    Statement statement = connect.createStatement();
    String query = "SELECT userName, id, pass FROM users WHERE userName='" + user.name
+ "' AND pass = '" + user.pass + "'";
    System.out.println(query);
    ResultSet resultSet = statement.executeQuery(query);

    while (resultSet.next()){
        System.out.printf("User: id=%d name=%s pass=%s\n",
                resultSet.getInt("id"),
                resultSet.getString("userName"),
                resultSet.getString("pass"));
    }
    MyConnection.closeConnect();
} catch (SQLException e) {
    e.printStackTrace();
}


Теперь если мы запустим этот метод и введем в консоль данные без инъекции:

user name: admin
pass: admin

User: id=1 name=admin pass=admin


При этом сам запрос выглядит так:

 SELECT userName, id, pass FROM users WHERE userName='admin' AND pass = 'admin'


Если допустить ошибку в имени или пароле, то данные выведены не будет. 

Теперь попробуем использовать инъекцию(' or'1'='1), т.е. введем такие данные:

user name: admin' or'1'='1
pass: blabla


То мы все равно получаем результат, несмотря на то, что пароль неверный:

 User: id=1 name=admin pass=admin


При этом сам запрос теперь выглядит так:

  SELECT userName, id, pass FROM users WHERE userName='admin' or'1'='1' AND pass
= 'blabla'


т.к. выражение or'1'='1' всегда равно true, то даже без указания пароля мы получим
все данные.



Как от этого защитит PreparedStatement?

Метод который будет получать данные из базы с помощью PreparedStatement:

UserLogin user = new UserLogin();
user.login();
try (Connection connect = MyConnection.getConnection()){
    String query = "SELECT userName, id, pass FROM users WHERE userName=? AND pass=?";
    PreparedStatement statement = connect.prepareStatement(query);
    statement.setString(1, user.name);
    statement.setString(2, user.pass);
    System.out.println(statement);
    ResultSet resultSet = statement.executeQuery();

    while (resultSet.next()){
        System.out.printf("User: id=%d name=%s pass=%s\n",
        resultSet.getInt("id"),
        resultSet.getString("userName"),
        resultSet.getString("pass"));
    }
    MyConnection.closeConnect();
} catch (SQLException e) {
    e.printStackTrace();
}


Все тоже самое, только заменили обычный Statement на PreparedStatement. Надеюсь вы
на слово поверите, что при правильных данных мы получим верный результат, если нет
то вот лог в консоли:

user name: user
pass: pass
User: id=2 name=user pass=pass
Запрос:
SELECT userName, id, pass FROM users WHERE userName='user' AND pass='pass'


А теперь попробуем использовать инъекцию:

user name: user' or'1'='1
pass: inject


И ответа не получаем, потому что запрос выглядит так:

  SELECT userName, id, pass FROM users WHERE userName='user\' or\'1\'=\'1' AND pass='inject'


Т.е. все кавычки были отражены слешем, инъекция не удалась. 



Отличие Statement от PreparedStatement:

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

PreparedStatement - вставляет значения в запрос и за счет методов setString setInt
и прочих. Он сам понимает где нужны кавычки, а где нет. Соответственно все входные
данных оборачивает ими.