Повторна оценка: какво остана от миналогодишните уязвимости

Затворена задача не доказва, че уязвимостта остава отстранена. При повторна оценка на клиент година по-късно около половината от предишните констатации още можеха да бъдат използвани: някои не бяха поправени, а други се бяха появили отново. Повторната проверка показва какво е отстранено и дали последващи промени са възстановили риска.

Допускането, което никой не тества

Жизненият цикъл, който повечето организации всъщност следват, изглежда така. Възлага се тест. Пристига доклад с констатации, всяка с критичност и препоръка. Някой ги превръща в заявки, които се проверяват и приоритизират, разпределят, оспорват, понижават по приоритет, повторно приоритизират и в крайна сметка се преместват в затворено състояние. Електронна таблица пожълтява, после позеленява. Въпросът се смята за приключен до следващия годишен тест.

Забележете какво липсва. В нито един момент никой не опитва отново първоначалната атака по независим начин. Една констатация се отбелязва като решена чрез промяна на състоянието в система за заявки, направена от екипа, който притежава кода, по собствена оценка на собствената му промяна. Това не е проверка; то е самооценка, записана в инструмент, създаден да проследява работа, не да установява факти за сигурността.

Затварянето на заявка и потвърденото отстраняване са различни събития, а те се разминават по напълно обикновени, незлонамерени причини:

• Разработчик поправя поведението така, както го е разбрал от резюмето на доклада — а то не винаги съвпада с поведението, което тестерът е използвал.
• Поправка се слива и заявката се затваря при сливането — преди промяната да достигне тестваната среда, или поне не до всички тествани среди.
• Заявката се затваря като няма да се поправи, приет риск или смекчено от компенсиращ контрол, а месеци по-късно този нюанс се е сплескал до „затворено“ в отчитането, което ръководството вижда.
• Поправката адресира единствения случай, посочен в доклада, а никой не потърси другите седем.

Почти нищо в обичайния процес не отличава тези изходи от истинска, трайна поправка. Проследяващата система не може да види разликата; тя записва само това, което човек е въвел в нея. И тъй като следващият тест обикновено е нов ангажимент с нов обхват, миналогодишните констатации рядко се проверяват отново нарочно. Ако някоя изплува отново, тя обикновено се записва като нова констатация, а не като доказателство, че отстраняването се е провалило — по-тих и много по-скъп извод.

Какво показа повторен ангажимент

Връщайки се при клиент за втори годишен ангажимент, направихме това, което сега правим по правило: преди да тестваме нещо ново, изпълнихме отново всяка констатация от доклада на предишната година. Не преглед на документи, не разговор за това какво е направено — опит, от тестер, да възпроизведе всеки първоначален проблем в текущата система, използвайки първоначалното доказателство като спецификация.

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

Повторно тествани констатации от предишна година   ~23

Все още налични                                     ~половина
Истински поправени                                  ~една трета
Невъзпроизводими                                    остатък
Блокирани от средата                                остатък

Около половината бяха все още налични — все още достижими, все още използваеми, предимно по същите стъпки, както година по-рано. Около една трета бяха истински поправени: атаката беше опитана, тя се провали и се провали по причина, която можехме да припишем на конкретна промяна, а не на късмет или недостъпност. Останалите или не можаха да бъдат възпроизведени — по причини, които не стигат до доказателство за поправка — или не можаха да бъдат достигнати, защото средата се различаваше съществено от първоначално тестваната.

Решаващата дисциплина: всяка все още налична констатация беше повторно демонстрирана с ново доказателство. Не пренесохме нищо на хартия. Констатация, която се появява в два последователни доклада, защото някой я е копирал, е административен артефакт; такава, която се появява два пъти с два независими набора доказателства, година по-късно, е факт за системата. Първото е шум; второто е разговор, по който ръководството може да действа.

Неудобното в упражнението не беше все още наличната половина, а това, че собственото проследяване на клиента показваше почти всички тези констатации като затворени. Не беше замесена измама и никой не се беше държал зле. Процесът просто нямаше стъпка, способна да улови пропастта между „направихме нещо“ и „това вече не работи“.

Четири начина една констатация да се върне

„Все още налична“ е едно заключение, което покрива четири доста различни провала — и си струва да ги разделим, защото имат различни собственици и различни мерки.

1. Никога не е била действително поправена. Заявката беше затворена заради намерение, не заради промяна. Някой прочете констатацията, съгласи се с нея, планира работата по нея — а работата после беше извадена от обхвата, отложена в списъка с чакащи задачи и по-късно затворена накуп, или вградена в рефакторинг, който така и не беше пуснат. Понякога смекчаване е било обсъдено в нишка коментари и самото обсъждане е станало решението. Системата е същата, каквато беше, когато я използвахме за пръв път: най-честият случай, и провал на работния процес, а не инженерен.

2. Поправена и регресирала. Поправката беше истинска, после върната назад — конфликт при сливане, разрешен в полза на по-стария клон, спешна поправка, отрязана от етикет отпреди поправката, връщане назад, което възстановява билд, за който се знае, че е добър, но не и сигурен, или среда, изградена наново от шаблон, който все още кодираше първоначалната неправилна конфигурация. Поправките на конфигурации са особено крехки: настройка, приложена на ръка, има период на полуразпад, измерван във внедрявания, защото това, което изгражда системата, не знае за нея.

3. Поправена само на едно място. Дефектът беше клас, а докладът назова случай. Този случай беше поправен и проверен. Същият дефект оцеля на съседна крайна точка, втори билд, остаряла версия на API, все още приемаща трафик, или друга среда, никога в обхвата. Никой не пропусна да поправи констатацията; те поправиха точно констатацията, което е разумен прочит на заявка и недостатъчен прочит на уязвимост. Границите на обхвата нанасят най-тихата си вреда тук: тестерът е спрял да гледа на ръба на обхвата — и поправката също.

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

Защо „невъзпроизводима“ е отделна категория

Най-честата нечестност при повторното тестване не е измислянето на поправки. Тя е тихото прехвърляне на невъзпроизводима към поправена. Двете изглеждат съседни — и в двата случая тестерът е опитал атаката и тя не е проработила — а едното е чиста зелена линия в доклад, докато другото е неловък абзац. Но те са твърдения за различни неща. „Поправена“ е твърдение за системата; „невъзпроизводима“ е твърдение за опита.

Констатация може да е недостижима по причини, които не казват абсолютно нищо за дефекта:

• Временно състояние на средата. Зависима услуга беше паднала, опашка не се източваше, функционален флаг случайно беше изключен, компонентът беше по средата на внедряване. Уязвимият път на кода не се изпълняваше тази седмица.
• Променен тестов акаунт. Първоначалният акаунт вече не съществува, или има различна роля, или е загубил право, маловажно за самата уязвимост, но съществено за достигането ѝ. Дефектът е непокътнат; ключът за коридора го няма.
• Липсващи данни. Използването зависеше от записи или връзки, налични преди година и отсъстващи сега. Дефект в контрола на достъпа над обекти, от които не държите нито един, пак е дефект в контрола на достъпа.
• Променена повърхност, същият дефект. Преименувана крайна точка, преструктуриран параметър, препроектиран поток. Първоначалните стъпки се провалят дословно; дали слабостта е преживяла разбъркването е отделен въпрос, на който се отговаря само с истинска работа.

Нищо от това не представлява отстраняване. Докладването им като поправени е начинът, по който една програма натрупва фалшива увереност: линията на тенденцията се подобрява, докато повърхността за атака — не, а първият, който открие несъответствието, е нападател или тестерът догодина.

Честното третиране на категорията изисква само да се каже нещо по-малко спретнато от „затворено“:

• Докладвайте я като отделна категория, видима в резюмето наред с все още наличните и поправените, никога слята с някое от тях.
• Опишете точно пречката — кой акаунт, кои данни, коя зависимост, кое състояние — така че читателят да може да прецени дали е случаен, или значим.
• Кажете какво би го уредило: конкретен достъп, въведен запис, флаг, включен в тестова среда. Назовете го, вместо да оставите читателя да гадае.
• Запазете първоначалната критичност. Невъзпроизводима констатация е отворен въпрос с първоначалната си критичност; понижаването ѝ заради един провалил се опит е същата грешка, само на забавен каданс.
• Пренесете я напред като нерешена, със записана пречка, така че следващия път да бъде опитана първа, вместо преоткрита от нулата.
• Където пречката може да се премахне в рамките на ангажимента, премахнете го и завършете теста. Повторен тест, завършващ с четири невъзпроизводими констатации, защото никой не поиска акаунт в първия ден, е провал в планирането, облечен като резултат.

Третирана така, „невъзпроизводима“ престава да е срам и става полезна: датиран запис за това какво повторният тест не можа да установи. Доклад, който признава несигурност на четири места, е по-достоен за доверие от такъв, който твърди сигурност навсякъде — и по-полезен за инженера, който решава какво да прави в понеделник.

Какво трябва да означава „поправена“

По-голямата част от този разпад е провал на определението, а не на инженерството. Екипите, които затварят констатации бързо, обикновено не лъжат себе си; те приемат сигнал, който прилича на проверка, но не е. Затова си струва да сме точни какво изисква проверено отстраняване.

Констатация е проверена като поправена, когато четири неща са верни едновременно:

• Първоначалните стъпки за възпроизвеждане се изпълняват отново — не някакво приближение, и не еквивалентната проверка на скенер, а същата последователност от заявки, роля, обект и предусловия, спрямо текущия билд.
• Проверката се извършва от човек, който не е внедрил корекцията. Авторът знае какво е целял да промени и може несъзнателно да провери само очаквания резултат. Независимият преглед помага да се открият непълни корекции и други начини за възпроизвеждане на проблема.
• Резултатът се прихваща като доказателство. Отказът, празният набор от резултати, отсъстващият хедър — нещо, за което трета страна може да прецени сама месеци по-късно.
• Проверката е датирана и обвързана с конкретен билд или среда. „Поправена“ не е свойство на система, а на версия на системата на дадено място. Без версията и мястото твърдението не може да бъде опровергано по-късно, а значи не може да му се вярва по-късно.

Сравнете това със сигналите, които екипите приемат вместо него. Затворена заявка описва работен процес, не система. Уверение на разработчик описва направената промяна, а не поведението, което следва — а тази пропаст е мястото, където се ражда повечето повторение. Diff на конфигурация доказва, че настройка се е променила в една дефиниция; той не казва нищо за това дали тази дефиниция е в сила, преживява следващото внедряване, или я подминава друг път до данните. Чисто сканиране е най-съблазнителното: то показва само че един инструмент, с един набор сигнатури, от една наблюдателна точка, вече не вижда това, което виждаше преди — почти безсмислено за дефект в оторизацията или дефект в логиката.

Това са разумни поводи за проверка. Те не са заместители на нея.

Повторно тестване на поправката, не на симптома

Когато тестер докладва инжекция, преминаване или липсваща проверка за оторизация, полезният товар не е уязвимостта; той е инструментът, който я разкри. Уязвимостта е отсъстващата проверка: вход, достигащ интерпретатор, без да бъде параметризиран; път, използван преди каноникализация; обект, върнат, без да се провери дали извикващият има право на него.

Поправка, която блокира докладвания полезен товар и нищо друго, оставя дефекта на място: списък за отказ, отхвърлящ точния низ от доклада, гранично правило, написано срещу единичната прихваната заявка. Констатацията се затваря, скенерът утихва, а дефектът чака някого, който го изпише малко по-различно.

Правилното повторно тестване означава повторно извеждане на констатацията, а не нейното възпроизвеждане, като се варира по четири оси:

• Входът. Различна форма, дължина и позиция на полезния товар. Ако числов идентификатор е бил векторът, опитайте друг идентификатор, друг негов формат и такъв, принадлежащ на различен собственик.
• Кодирането и представянето. Алтернативно и двойно кодиране, смесен регистър, unicode еквиваленти, JSON тяло там, където е използвано тяло на форма, масив там, където е очакван скалар. Много „поправки“ са сравнения на низове, а те се преодоляват чрез представянето.
• Методът и транспортът. Същата операция с различен глагол; параметърът, преместен от тяло към query string или хедър. Контролите за всеки маршрут и за всеки глагол са повтарящ се източник на частични поправки.
• Входната точка. Същата операция през друг интерфейс — машинното API вместо браузърния поток, групова крайна точка, функция за експорт, остаряла версия на маршрута, все още отговаряща на заявки.

Оценявайте правомощията, покритието и възможността за заобикаляне на контрола. Задължителен доверен шлюз може трайно да налага политика; незадължителен или заобиколим филтър може да ограничава само един път. Тествайте алтернативни входове само с договореното разрешение. Разграничавайте поправка на причината от компенсиращ контрол, без да решавате валидността само според слоя.

Общият принцип: кръпка за симптома отхвърля известен лош вход; поправка на първопричината променя как се взема решението. Затова повторният тест пита не „старият ми полезен товар още ли работи?“, а „присъства ли сега липсващата проверка — в компонента, който притежава данните, за всяко представяне на заявката, което стига до него?“. Ако поправката не може да се опише като промяна в това къде и как се взема решение — параметризация вместо конкатенация, оторизация спрямо обекта вместо маршрута, списък за допускане вместо списък за отказ — тя вероятно е филтър.

Къде се крият регресиите

Констатацията се докладва там, където тестерът случайно я е намерил. Това място е следствие от бюджета за време на ангажимента, а не граница на дефекта, а най-сигурният начин да произведете повторение е да поправите точно това, което докладът описва, и нищо повече. Ето къде същият дефект се появява отново, приблизително по ред на честота:

• Съседни крайни точки и паралелни пътища на кода. Обработчикът за създаване е поправен, а обработчикът за обновяване — не; изгледът за детайли е поправен, а изгледите за списък, търсене и експорт — не; помощна функция е копирана, копието е коригирано, а оригиналът все още се извиква другаде.
• Други билдове и платформи на същия продукт. Функция, внедрена отделно за различни клиенти, или споделена услуга, където само тестваният преден край е имал извикванията си коригирани.
• Други среди и клиентски организации. Поправка, приложена към едно внедряване, но не към останалите, или специфична за клиентска организация конфигурация, никога приведена в съответствие: контролът е правилен за клиентската организация, който беше тестван.
• Изграждания наново на инфраструктурата. Промяна за закаляване, направена на ръка, после изтрита, когато хостът, клъстерът или образът се изгради наново от дефиниция, все още носеща старите настройки. Поправката беше истинска; тя просто не беше там, откъдето системата черпи истината си.
• Обновявания на зависимости. Поведение, премахнато чрез локално прилагане на актуализации за сигурност или конфигурация, после възстановено от повишаване на версия, промяна в стойност по подразбиране нагоре по веригата или транзитивна зависимост, която повторно въвежда премахнат компонент.

Затова въпросът за отстраняването никога не е „къде беше докладвано това?“, а „къде съществува този модел?“. Това е въпрос за търсене в кода и инвентар, обикновено отговорим за следобед — далеч по-евтино от това следващият ангажимент да намери събрата.

Превръщане на повторен тест в регресионен тест

Всичко това е ръчно, а ръчната проверка се разпада със скоростта, с която се разпадат хората и паметта. Трайният отговор е всяка потвърдена констатация да се преобразува в автоматизирана проверка, която се изпълнява при всеки билд, а дисциплината там е да се проверява резултатът, а не само кодът на състоянието. Тест, който приема всеки отговор, различен от 200, преминава, когато крайната точка е премахната, когато услугата е неправилно конфигурирана и когато нов път за грешка изтече данните в рамките на 500. Тест, който проверява свойството за сигурност, е далеч по-труден за случайно удовлетворяване: заявка за обекта на друга клиентска организация не връща нито едно поле от данните на този обект; неудостоверена привилегирована операция оставя записа непроменен, когато бъде прочетен обратно като администратор.

запис за проверка
  препратка към констатация   <вътрешен id>
  първоначални стъпки         изпълнени отново непроменени
  проверено от                <не внедрилият>
  билд / среда                <идентификатор на билд> / <среда>
  дата на проверка            <дата>
  опитани варианти            кодиране, глагол, алтернативна входна точка
  местоположение на контрола  притежаваща услуга, от страната на сървъра
  доказателство               двойка заявка/отговор, съхранена
  изход                       поправена | частична | непоправена | смекчена на ръба
  регресионен тест            <идентификатор на тест>, изпълнява се при всеки билд

регресионно твърдение (форма, не синтаксис)
  дадено   удостоверена сесия за наемател A
  когато   се заявява обект, притежаван от наемател B
  тогава   отговорът не съдържа стойност на поле от този обект
    и      отговорът не съдържа препратка, позволяваща последващо четене
    и      одитната следа записва отказан достъп
  # твърдение „не 200“ също би преминало, ако маршрутът беше просто изтрит

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

Бъдете честни за ограниченията. Верижни атаки, злоупотреба с бизнес логика, дефекти, нуждаещи се от конкретна последователност човешки действия, и всичко, чиято използваемост е въпрос на преценка, а не на наблюдение — всички се съпротивляват на автоматизацията, както и целият клас дефекти, които никой още не е намерил. Нестабилните тестове за сигурност също се изключват по-бързо от функционалните, затова няколко твърдения, които наистина кодират свойството, превъзхождат много, които само го наподобяват.

Как да го направите част от програмата

Последователността, която работи, приблизително по реда на внедряване:

• Включете повторния тест в ангажимента. Купена отделно, месеци по-късно, проверката се конкурира с новата работа за бюджет и обикновено губи. Включването ѝ в обхвата означава също, че проверяват същите тестери, със същия контекст.
• Проверявайте повторно след големи издания и промяна в инфраструктурата. Това са двете събития зад повечето повторения в пропорциите по-горе. Целенасочена повторна проверка струва част от пълна оценка и улавя регресиите, докато са евтини.
• Поддържайте регистър на предишно потвърдените констатации. Не системата за заявки — траен запис за това какво е било потвърдено, стъпките, доказателството, билда и средата, спрямо които е проверено, датата и дали автоматизирана проверка го покрива. Без него всеки ангажимент започва от нулата и „остана ли това поправено?“ дори не може да се зададе.
• Тествайте повторно извадка от стари констатации всяка година, претеглена към категориите, които се повтарят: оторизация, конфигурация и всичко, поправено на едно място, когато моделът е съществувал на няколко. Третирайте всяко повторение в извадката като доказателство за цялата популация.

В основата на всичко това стои една промяна на нагласата. Отстраняването не е събитие, което заключва констатация; то е твърдение за текущото поведение, а такива твърдения изтичат. Програма, която се измерва по затворени констатации, измерва собствената си документация. Онази, която измерва констатациите, останали поправени — проверени спрямо назован билд на известна дата — измерва нещо истинско.

PXL включва повторен тест на отстраняването стандартно при тестовете за проникване. Изпълняваме отново първоначалните стъпки за възпроизвеждане спрямо поправения билд, потвърждаваме дали контролът е наложен на правилното място и записваме какво намираме — включително къде поправка е частична, къде се държи само на ръба и къде моделът оцелява някъде, където никога не сме го докладвали.