Към съдържанието
wannacode

Сигурност като изискване

Накратко: Функционалните тестове проверяват какво може клиентът. Сигурността пита какво НЕ трябва да може човек, който иска да навреди. Затова изискването за сигурност се пише като сценарий със злонамерен потребител: кой, какво опитва и какво трябва да се случи вместо това.

Проблем

Всички тестове минават, а поръчките са на всички

Клиент отваря поръчката си: адресът завършва на /orders/1042. От любопитство сменя числото на 1041. Вижда чужда поръчка: име, адрес, телефон, какво е купено.

Магазинът има 400 теста. Един от тях проверява, че клиентът вижда своята поръчка. Минава. Никой тест не пита дали вижда и чуждата, защото никое изискване не казва, че не трябва.

Идеята

Сигурността е изискване като всяко друго

В модела на качеството от първия модул сигурността (security) е една от деветте характеристики. Тя е колко добре системата пази данните и действията от хора, които нямат право. ISO/IEC 25010:2023 я дели на шест:

Подхарактеристика В магазина
Поверителност (confidentiality) Клиентът вижда само своите поръчки.
Цялост (integrity) Цената не може да се смени от браузъра.
Неотменимост (non-repudiation) Клиентът не може да твърди, че не е поръчал платената поръчка.
Отчетност (accountability) Всяка смяна на адреса се записва: кой и кога.
Автентичност (authenticity) Влязлият е този, за когото се представя.
Устойчивост (resistance) Магазинът издържа на 10 000 опита за промо код в минута.

Изискването за сигурност се пише и приема като всяко нефункционално: с поведение, което може да се провери, и с граница.

По-точно, за любопитните

Устойчивостта (resistance) е нова в изданието от 2023 г.: способността да се изпълнява работата и по време на атака. ISO/IEC 25010 описва какво се иска, не как се постига. Как се постига (пароли, сесии, токени, недоверен вход), е в модула Сигурност за програмисти от курса по софтуерно инженерство, с код.

Пробвай

Коя част от сигурността?

1. Клиентът сменя номера в адреса на страницата с поръчката си и вижда чужда поръчка с адрес и телефон.
2. Клиентът променя цената на продукта в заявката, която браузърът праща, и плаща 1 € за слушалки за 89 €.
3. Служител сменя адреса за доставка на поръчка, и никой не може да каже кой е бил.
4. Някой пробва по 10 000 промо кода в минута, докато уцели работещ.

Идеята

Злонамереният потребител

Сторито казва какво иска честният клиент. Сигурността пита за друга роля: човек, който иска да навреди. Затова за всяко стори се пише и обратното:

  • стори: „Като клиент искам да виждам поръчките си“;
  • злонамерен сценарий (abuse case): „Като злонамерен клиент искам да видя чужда поръчка, за да взема адреса и телефона“.

Вторият казва какво не трябва да може да стане и какво се случва вместо това. Пише се със същите думи като критериите за приемане:

# language: bg
Функционалност: Поръчките на клиента


  Сценарий: Клиент не вижда чужда поръчка
    Дадено клиент А е влязъл в профила си
    И поръчка 1041 е на клиент Б
    Когато клиент А отвори поръчка 1041
    То вижда „Няма такава поръчка“
    И не вижда името, адреса и телефона на клиент Б
    И опитът е записан в журнала

„Няма такава поръчка“, а не „Нямаш право“: второто казва на нападателя, че поръчката съществува.

По-точно, за любопитните

На английски се срещат и двете имена: abuse case и misuse case, по „Misuse cases“ на Синдре и Опдал (2005). OWASP поддържа списъци с типични атаки и с проверими изисквания за сигурност на уеб приложения (Application Security Verification Standard, ASVS). Нарушеният контрол на достъпа, като чуждата поръчка тук, е на първо място в OWASP Top 10 в изданието от 2021 г.

Пробвай

Какво не трябва да може?

1. Стори: „Като клиент искам да ползвам промо кода си.“ Кой е сценарият със злонамерен потребител?
2. Стори: „Като клиент искам да върна продукт до 14 дни от получаването.“ Кой е сценарият със злонамерен потребител?
3. Стори: „Като служител в склада искам да виждам платените поръчки.“ Какво трябва да е невъзможно?

Идеята

Кой мисли като нападател

Злонамерените сценарии не са работа само на екип по сигурност накрая. Най-евтино се намират на същия разговор, на който се пишат правилата на сторито. На Example Mapping към правилата, примерите и въпросите се добавя още един въпрос: „Кой би искал да злоупотреби с това, и как?“

  • промо кодът: две платени поръчки едновременно; налучкване на кодове;
  • връщането: чужда поръчка; връщане на по-скъп продукт от купения;
  • количката: цена, сменена в браузъра; отрицателно количество.

Рискът подрежда кои да се напишат първи: тези, при които се губят пари или лични данни.

Приемането е както при производителността: изискванията се договарят с бизнеса предварително, а проверката им е част от приемното тестване. Тестът за проникване (penetration test) от външни хора е полезно допълнение. Но той намира това, което никой не е поискал. Изискването прави сигурността нещо, което се проверява всеки път.

По-точно, за любопитните

CT-AcT v1.0, глава 4, включва и сигурността в приемното тестване на нефункционалните изисквания: изискванията и мерилата се договарят предварително, а бизнесът решава кои рискове приема. Как моделът на заплахите се прави систематично (например STRIDE) и как атаките се проверяват с код, е в модула „Сигурност за програмисти“.

Упражнение

Изискване за сигурност

1. Поръчките. Рецензирай изискването за сигурност на поръчките.

Отбележи проблемите в изискването и избери вида на всеки.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

Тест

Провери се

1. Какво е сценарий със злонамерен потребител (abuse case)?
2. Защо функционалните тестове не хващат чуждата поръчка?
3. Кое е изискване за сигурност, което може да се провери?
4. Кой трябва да мисли за злонамерените сценарии?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·