Прикладная теория Application Security

Прикладная теория Application Security
Владимир Кочетков
/Positive Technologies/Application Inspector/Team Lead
Образовательная программа «Практическая безопасность»

Agenda
Что?
Теоретический минимум, необходимый для осознанной разработки или
анализа защищенности кода
Зачем?
Перестать следовать культу карго
3

Главный вопрос Жизни,
Вселенной и всего остального…
4

…что такое "уязвимость"?
5

Что такое "уязвимость"?
«Недостаток (слабость) программного (программно-технического) обеспечения
средства или информационной системы в целом, который (которая) может быть
использована для реализации угроз безопасности информации» - ГОСТ Р 56546-
2015
6

2015
«В чем сила, брат?» (с)
7

2015
«Набор входных данных, приводящий машину Тьюринга в запрещенную
конфигурацию» - Computer Science
8

2015
«Набор входных данных, приводящий машину Тьюринга в запрещенную
конфигурацию» - Computer Science
9

Существующие определения не
дают ни малейшего
представления о технической
сущности уязвимости
10

Правильный вопрос: в чем
разница между защищенным и
уязвимым кодом?
11

var cmd = new SqlCommand("SELECT Value FROM Discounts WHERE CouponCode LIKE '" +
Request["CouponCode"] + "'");
var connection = new SqlConnection(connectionString);
connection.Open();
cmd.Connection = connection;
var couponValue = cmd.ExecuteScalar();
...
12

var cmd = new SqlCommand("SELECT Value FROM Discounts WHERE CouponCode LIKE '" +
Request["CouponCode"] + "'");
connection.Open();
...
Атакующий имеет возможность нарушить целостность
выходного потока данных (кода SQL-запроса), манипулируя
потоком входных данных (параметром HTTP-запроса),
приходящим в операцию выполнения SQL-кода.
13

var cmd = new SqlCommand("SELECT Value FROM Discounts WHERE CouponCode LIKE
@CouponCode");
cmd.Parameters.AddWithValue("@CouponCode ", Request["CouponCode"]);
connection.Open();
...
14

var cmd = new SqlCommand("SELECT Value FROM Discounts WHERE CouponCode =
@CouponCode");
cmd.Parameters.AddWithValue("@CouponCode ", Request["CouponCode"]);
connection.Open();
...
Атакующий имеет возможность нарушить целостность
выходного потока данных (параметра SQL-запроса),
манипулируя потоком входных данных (параметром HTTP-
запроса), приходящим в операцию выполнения SQL-кода,
что может привести к нарушению правил предметной
области приложения.
15

1)
[Authorize(Roles = "All")]
public ActionResult SomeAction()
{
...
return View();
}
2)
[Authorize(Roles = "Baz, Qux")]
{
...
return View();
}
16

1)
[Authorize(Roles = "All")]
{
...
return View();
}
2)
[Authorize(Roles = "Baz, Qux")]
{
...
return View();
}
Невозможно оценить
защищенность кода, не
владея всеми предметными
областями приложения (в
данном случае, политики
контроля доступа).
17

Критерии уязвимости
определяются множеством
предметных областей
приложения
18

Примеры предметных областей
Вторичные:
― защищенность;
― отказоустойчивость;
― опыт взаимодействия,
― производительность.
Основные:
― интернет-торговля;
― онлайн-банкинг;
― бухучет;
― … (тысячи их).
Каждое приложение реализует модели как основной предметной области, так и
множество моделей вторичных предметных областей

Application Security – вторичная
предметная область
20

Предметная область Application
Security
21

Сущность
– абстракция реального объекта в некотором контексте, обладающая
следующими характеристиками:
• свойство – значимый атрибут абстрагируемого сущностью объекта или
одноместное отношение;
• состояние– множество текущих значений всех свойств сущности;
• инвариант– множество допустимых состояний сущности.
Отношение – утверждение, определяющее взаимосвязь изменения состояний
сущностей.
22

Предметная область –
множество сущностей, их
инварианты и отношения
23

Пример: логистика
Сущность: точки на карте города
• свойство: координаты – пара значений «широта-долгота»;
• инвариант: координаты принадлежат перекресткам города или строениям.
Сущность: маршрут
• свойство: путь - упорядоченное множество точек на карте города;
• инвариант: путь непрерывен и проходит по улицам города в соответствии с ПДД;
• отношение: оптимальность – длина пути минимальна для одних и тех же
начальной и конечной точек.
Сущности: точка загрузки, точка доставки
• свойство: точка на карте города
24

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

Задача коммивояжёра
В терминах предметной области логистики:
построить оптимальный маршрут из точки
загрузки, проходящий через все точки доставки по
одному разу и возвращающийся в точку загрузки.
В терминах предметной области теории графов:
Найти гамильтонов цикл минимального веса в
полном (дополненном ребрами бесконечной длины)
взвешенном графе.
26

Security
27

«Трясина Тьюринга» - не только
об эзотерических языках
28

"Modeling Computer Insecurity" (Sophie Engle, Sean Whalen and Matt Bishop):
Провести полный анализ защищенности программы можно, только выполнив ее
на всех возможных наборах входных данных.
Разработка защищенного кода менее трудоемкий процесс, чем анализ
защищенности уже существующего кода.
Вычислимость проблемы защищенности
Статическая оценка защищенности
программы является неразрешимой
проблемой.
Определение защищенности
текущего состояния программы,
очевидно, разрешимо

Применимость теоремы Райса к
реальным системам – такая же
теоретизация, как и идея
описывать приложение в виде
конечного автомата
30

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

Потоки управления
var name = Request.Params["name"];
var key1 = Request.Params["key1"];
var parm = Request.Params["parm"];
var data = string.IsNullOrEmpty(parm) ? new char[0]: Convert.FromBase64String(parm);
string str1;
if (name + "in" == "admin")
{
if (key1 == "validkey")
{
str1 = Encoding.UTF8.GetString(data);
}
else
{
str1 = "Wrong key!";
}
Response.Write(str1);
}
32

string str1;
{
{
}
else
{
}
}
33

string str1;
{
{
}
else
{
}
}
34

string str1;
{
{
}
else
{
}
}
35

string str1;
{
{
}
else
{
}
}
36

string str1;
{
{
}
else
{
}
}
37

string str1;
{
{
}
else
{
}
}
38

string str1;
{
{
}
else
{
}
}
39

string str1;
{
{
}
else
{
}
}
40

string str1;
{
{
}
else
{
}
}
41

string str1;
{
{
}
else
{
}
}
42

string str1;
{
{
}
else
{
}
}
43

string str1;
{
{
}
else
{
}
}
44

string str1;
{
{
}
else
{
}
}
45

string str1;
{
{
}
else
{
}
}
46

Потоки управления всегда
являются производными от
потоков данных
47

Потоки данных
string str1;
{
{
}
else
{
}
}
48

string str1;
{
{
}
else
{
}
}
49

string str1;
{
{
}
else
{
}
}
50

string str1;
{
{
}
else
{
}
}
51

string str1;
{
{
}
else
{
}
}
52

string str1;
{
{
}
else
{
}
}
53

string str1;
{
{
}
else
{
}
}
54

string str1;
{
{
}
else
{
}
}
55

string str1;
{
{
}
else
{
}
}
56

string str1;
{
{
}
else
{
}
}
57

string str1;
{
{
}
else
{
}
}
58
str1 ∈ {
Encoding.UTF8.GetString(Convert.FromBse64String(Request.Params["parm"])),
"Wrong Key!"
}

Множества значений всех
потоков данных в конкретной
точке потока выполнения
определяют состояние
59

Граф переходов между
состояниями приложения
определяет все возможные
потоки вычисления
60

Граф потоков вычисления
является семантически-
эквивалентной моделью
61

Security
62

Театр начинается с вешалки, а
уязвимость – с недостатка
63

Недостаток
- неэффективная реализация моделей предметных областей приложения и
контролей инвариантов их сущностей
Примеры контролей Application Security:
• предварительная обработка потоков данных;
• подтверждение аутентичности потоков вычисления;
• проверка прав доступа к потокам данных;
• обеспечение соответствия потока вычисления модели функциональной
предметной области;
• …
64

Угроза
- обусловленная недостатком возможность нарушить состояние защищенности
потока вычисления, лишив его одного из свойств:
• конфиденциальности;
• целостности;
• доступности;
• авторизованности;
• аутентичности;
• аппелируемости;
• подотчетности;
• достоверности;
• <нужное вписать>
65

Конфиденциальность
Состояние потока вычисления, при котором доступ к нему осуществлен только
сущностями, имеющими на это право.
A
E
B
66

Целостность
Состояние потока вычисления, при котором изменения в нем осуществлены
только сущностями, имеющими на это право.
A
E
B
C
67

Доступность
Состояние потока вычисления, при котором доступ к нему могут осуществить все
сущности, имеющие на это право.
A B
68

Авторизованность
Состояние потока вычисления, при котором его источниками являются только
сущности, имеющие на это право.
E
B
A
69

Аутентичность
Состояние потока вычисления, при котором подтверждена подлинность его
источника.
‘A’
B
A
70

Аппелируемость
Состояние потока вычисления, при котором его источник не может отказаться от
того, что он является таковым.
A B
71

Уязвимость – состояние
приложения, в котором возможна
реализация угрозы
72

Невозможность реализации
угрозы в каждой точке потока
вычисления* является
инвариантом защищенности
73
* …пересекающего границу доверия

Уязвимость бизнес-логики–
состояние реализации угрозы
через нарушение правил
основной предметной области
74

То, что может сделать с потоками вычисления атакующий, нарушив инварианты
сущностей предметных областей, называется угрозой (threat)
То, где и благодаря чему он может это сделать, называется уязвимостью
(vulnerability), обусловленной недостатком (weakness)
То, как он может это сделать, называется атакой (attack)
То, с какой вероятностью у него это удастся и какие последствия может повлечь,
называется риском (risk)
Иными словами…
75

То, что не позволяет атакующему
провести атаку, обеспечивает
защищенность (security)
76

То, что минимизирует риск,
обеспечивает безопасность
(safety)
77

Акцентировать внимание
разработчикам и пентестерам
необходимо на причинах*, а не
на следствиях**!
* недостатки
** уязвимости, атаки или риски
78

Причинно-следственные связи
Недостаток Угроза
Уязвимость Атака
Риск
Незащищенность
Небезопасность
79

Выводы
Разработка защищенного кода сводится к реализации контроля инвариантов
всех сущностей основной предметной области и области защищенности
Анализ защищенности кода сводится к оценке эффективности реализованных
контролей
Ни то, ни другое – невозможно без досконального изучения основной
предметной области и области защищенности приложения
80

Классификация
Классификация уязвимостей возможна по:
― предметной области; // защищенность приложения
― недостатку; // неэффективная предварительная обработка
потоков данных
― потоку вычисления; // формирующие первообразные потоков выполнения
― угрозе; // нарушение целостности
// уязвимость к атакам инъекций (в зависимости от интерпретатора потока
данных: XSS, SQLi, XMLi,XPATHi, Path Traversal, LINQi,XXE и т.п.)

― предметной области; // защищенность приложения
― недостатку; // неэффективное подтверждение аутентичности
источника потока вычисления
― потоку вычисления; // HTTP-запрос, приводящий к изменению состояния
― угрозе; // нарушение аутентичности
// уязвимость к атакам CSRF

― предметной области; // онлайн-торговля
― недостатку; // неэффективный контроль использования погашенных
купонов на скидку
― потоку вычисления; // транзакция оплаты заказа
― угрозе; // нарушение авторизованности
// уязвимость к атакам на бизнес-логику (повторное использование погашенных
купонов)

Что будет, если поиграть в
алхимию с критериями
классификации?
84

Вопросы?
Владимир Кочетков
vkochetkov@ptsecurity.com
@kochetkov_v
/Positive Technologies/Application Security
/Application Inspector/Compiling and Low-Level Applications Analysis/Team Lead

Прикладная теория Application Security

Прикладная теория Application Security

More Related Content

What's hot

Similar to Прикладная теория Application Security

More from Vladimir Kochetkov

Прикладная теория Application Security