В этой книге тема безопасности рассматривается под необычным углом. Вместо использования классического подхода, когда безопасность находится в центре внимания, мы решили сделать основной темой проектирование программного обеспечения. Поначалу это может прозвучать немного странно, но если учесть, что уязвимости зачастую вызваны плохой архитектурой, обсуждение безопасности с точки зрения проектирования намного привлекательнее. Что, если существенного количества уязвимостей можно было бы избежать, применяя хорошие методы проектирования и общепринятые рекомендации? Это кардинально изменило бы наши взгляды на разработку ПО и послужило бы поводом для выбора определенных архитектурных решений.
Таким образом, исследование того, как проектирование ПО связано с безопасностью, — главная цель книги. Это означает, что здесь вы не найдете обсуждения таких классических аспектов безопасности, как переполнение буфера, недостатки криптографических хеш-функций или выбор подходящего метода аутентификации. Вместо этого вы узнаете, почему некоторые архитектурные решения важны с точки зрения безопасности и как с их помощью можно создавать программное обеспечение с глубокой защитой.
Вашему внимаю предлагаю отрывок из книги.
Антракт: анти-«Гамлет»
Это реальная история о том, как отрицательные числа могут привести к большим финансовым потерям. Она основана на проблеме, возникшей у нашего клиента, над которой мы работали, но, чтобы поделиться с вами подробностями, нам пришлось исказить контекст. В частности, мы изменили продукт, который продавала компания: уверяем вас, это были не книги. Интересно, что существуют подобные примеры, в которых книги действительно фигурировали. Компания Amazon столкнулась с похожей программной ошибкой около 2000 года. Однако мы не знаем всю подноготную тех случаев.
Это история также о том, что серьезная проблема с безопасностью существовала в промышленной среде на протяжении долгого времени, не привлекая к себе внимания и не вызывая никаких неисправностей — по крайней мере не в техническом смысле. Тем не менее из-за нее предприятие теряло деньги. На практике возместить потери оказалось невозможно, но можно было раскрыть личности тех, кто нажился на этой проблеме.
Наконец, эта история о том, как международная торговая компания случайно позволила своим клиентам самостоятельно получать скидки в своем интернет-магазине. Мы покажем, как ее финансовые потери стали результатом поверхностного проектирования с недостаточным или отсутствующим моделированием, с чем мы часто сталкиваемся. А также проиллюстрируем значимость четкого и сознательного моделирования.
Этот интернет-магазин не представляет собой ничего особенного — типичный сайт, на котором клиент помещает книги в корзину, оформляет заказ, проводит оплату кредитной картой и затем получает товар через службу доставки (рис. 2.1).
Магазин открылся уже давно и продолжает развиваться. Компания пригласила команду специалистов по безопасности для проведения аудита и тестирования. В частности, они проверяют конфигурацию системы в промышленной среде и ее кодовую базу. А также выполняют тесты, пытаясь манипулировать системой снаружи в поисках дыр в безопасности. Команда получила установку расследовать все, что может показаться подозрительным.
Анализ показал, что инфраструктура довольно надежная. Вслед за этим специалисты взялись за брандмауэры и просканировали открытые порты операционной системы. Они направили веб-серверу вредоносные пакеты, но никаких проблем это не вызвало. И это неудивительно: в наши дни проблемы с безопасностью редко возникают из-за дефектов в инфраструктуре. Все уже знают, что объекты, которые не должны быть доступны всем подряд, необходимо изолировать.
В это же время другие члены команды исследовали приложение интернет-магазина с технической точки зрения, пытаясь найти способы обойти механизм аутентификации. Они проверяли, можно ли похитить открытый сеанс клиента, пробовали «отравить» cookie. И снова безрезультатно. Но и тут все было ожидаемо, так как безопасность достигалась правильной конфигурацией веб-сервера, а создатели магазина явно сверялись с документацией, когда конфигурировали свое приложение.
Прорыв произошел, когда один из членов команды, Джо Тестер, заинтересовался полем Количество, в котором клиент указывает, сколько книг ему нужно, в форме заказа. Он указал в нем фрагмент JavaScript-кода, чтобы узнать, будет ли тот выполнен. Но ничего не произошло. Затем попытался спровоцировать внедрение SQL — опять безуспешно. Наконец из любопытства он ввел -1 в качестве количества экземпляров «Гамлета» по цене 39 долларов. То есть Джо Тестер попытался купить один отрицательный «Гамлет» — анти-«Гамлет».
К своему удивлению, он не получил сообщения об ошибке. Магазин принял заказ и выполнил процедуру его обработки. Джо указал кредитную карту и получил электронное письмо с подтверждением того, что заказ был принят. «Странно», — подумал он. Сделав заметку в записной книжке, Джо продолжил работу. На следующее утро в дверь кабинета команды безопасности постучали, и внутрь неуверенно заглянула женщина.
«Я из бухгалтерии, — представилась она. — Хотела спросить, не знаете ли вы кого-нибудь по имени Джо Тестер?» И сразу же уточнила: «Я просто поспрашивала тут, и кто-то мне сказал, что вы можете знать».
«Да, это наш тестовый клиент, — ответила команда. — Что с ним не так?»
Женщина из бухгалтерии продолжила: «Я просматривала журнал дебиторской задолженности и заметила, что система сгенерировала для этого клиента возвратную накладную в размере 39 долларов. Но когда мы собрались отправить по почте его книгу, обнаружилась странная вещь: его адрес совпадает с адресом этого офиса. Вот почему я насторожилась и начала расспрашивать».
Система пыталась выплатить деньги Джо Тестеру. Нехорошо.
Книжный интернет-магазин с нарушением бизнес-целостности
Сделаем шаг назад и посмотрим, что же произошло. Интернет-магазин принял заказ с –1 экземпляром «Гамлета», и это, несомненно, странно. Но давайте подумаем о логических последствиях, которые это за собой влечет.
Если кто-то покупает книгу по цене 39 долларов, сумма заказа будет равна 39 долларам, поэтому по логике клиент уплачивает эту сумму магазину. В нашем случае Джо Тестер купил не копию «Гамлета», а отрицательную копию, поэтому сумма заказа равна –39 долларов (рис. 2.2). Он должен уплатить магазину –39 долларов — или магазин должен выплатить 39 долларов ему. Но магазин не должен платить деньги таким образом. Возможно, это Джо Тестер должен передать магазину копию «Гамлета».
С точки зрения безопасности это нарушение. Один из аспектов безопасности относится к целостности данных: это означает, что данные не должны меняться или генерироваться несанкционированным образом. Чаще всего целостность рассматривается в техническом контексте: предоставление контрольных сумм и криптографических подписей для гарантии того, что данные изменяются по правилам. В нашем случае речь идет не о технических, а о бизнес-правилах. Слать деньги клиентам за антикниги — не очень хорошая бизнес-модель. Мы имеем дело с нарушением бизнес-целостности.
Насторожившись, команда безопасности начала расследование, чтобы понять, что на самом деле происходит. Оказывается, что система интернет-магазина вычисляет для заказа сумму «К оплате» в размере –39 долларов, что логично, хоть и странно. Эта сумма последовательно проходит через несколько других систем (рис. 2.3).
Интересно в этой истории то, что в проблеме безопасности нельзя разобраться без понимания каждой из задействованных в ней систем, их взаимодействия и реакции на внешние факторы. Начнем с двух: системы биллинга и журнала дебиторской задолженности.
Система биллинга предназначена для сбора клиентских платежей. Если клиент предпочитает платить кредитной картой и оформляет заказ на 347 долларов, эта сумма снимается с его кредитной карты. Но клиент может выбрать другие методы оплаты: счет-фактуру, накопительный счет-фактуру или подарочные карты. У некоторых клиентов предусмотрены разные методы оплаты для разных сумм. Крупные заказы могут оплачиваться напрямую, а мелкие — накапливаться на счету, который выставляется в конце месяца.
Джо Тестер оформляет заказ на –39 долларов, и эта сумма передается системе биллинга. В ней есть модуль для работы с кредитными картами, который не знает, что делать с отрицательными суммами. С точки зрения биллинга отрицательная сумма означает, что к оплате ничего принимать не нужно. Процедура платежа пропускается.
Принцип работы журнала дебиторской задолженности
Теперь перейдем к журналу дебиторской задолженности. Этот журнал является частью бухгалтерской системы и содержит записи о клиентах, которые должны компании деньги, задолженность существует в период между покупкой книги и поступлением оплаты на счет компании. В журнале дебиторской задолженности имеется баланс каждого клиента. Например, если кто-то оформляет заказ на сумму 347 долларов и выбирает оплату счета-фактуры, 347 долларов прибавляется к балансу клиента. Позже, когда компания получит платеж, баланс в журнале сбрасывается. Иногда люди переплачивают — например, мы могли бы заплатить 350 долларов. В этом случае баланс становится отрицательным, –3 доллара, что означает: компания должна деньги клиенту. С точки зрения банка задолженность компании перед клиентом — вполне нормальное явление, даже в долгосрочной перспективе. Но для книжного интернет-магазина она допустима только как временная ситуация. Если это происходит, магазин должен попытаться как можно скорее вернуть долг.
В обычной ситуации для выплаты задолженности клиенту книжный интернет-магазин высылает возвратную накладную. Эти накладные обрабатываются группами — вот что имела в виду бухгалтер, когда сказала: «Я просматривала журнал дебиторской задолженности…» Когда Джо Тестер сделал свой антизаказ, система интернет-магазина отправила платеж в размере –39 долларов в журнал дебиторской задолженности, то есть сразу же возникла задолженность компании перед Джо. Следующей ночью система обрабатывает журнал, находит неоплаченный долг и создает возвратную накладную, которая должна быть отправлена Джо для сброса его баланса в журнале. Это фактически означает, что наш тестовый клиент получает платеж (рис. 2.4). Это та накладная, которую проницательная сотрудница бухгалтерии посчитала подозрительной и из-за которой у нее возникли вопросы.
Проверки проводились в реальных условиях, поэтому очевидно, что выявленная прореха существует в системе на протяжении некоторого времени. Этот конкретный случай был выявлен только из-за подозрительного адреса. Но аналогичные случаи могли возникать и раньше.
Началось финансовое расследование, призванное определить, насколько серьезной была проблема. Эксплуатационная команда и специалисты по безопасности объединили усилия для перекрестной проверки всех сгенерированных возвратных накладных. После отсеивания накладных для поставщиков и партнеров остались только клиентские записи. Большинство их были корректными и объяснялись повреждением товара или другими понятными причинами. Осталась небольшая часть, поэтому проблема оказалась не слишком серьезной — по крайней мере так казалось в тот момент. Тем не менее сам факт того, что безвозмездная отправка денег оставалась незамеченной, был странным. Техническое расследование продолжили, чтобы раскрыть все детали происходящего при заказе антикниги. Оказалось, что в этот процесс вовлечены еще две важные системы: склад и отправка.
Как система складского учета отслеживает книги в магазине
Система складского учета следит за тем, сколько экземпляров той или иной книги в наличии на складе и доступно для продажи. Для начала можно было бы определить количество штук каждого издания на складских полках, но, к сожалению, оказалось, что все не так просто. Представьте, к примеру, что у нас на складе есть 17 экземпляров «Гамлета». Клиент купил два из них, но их еще не взяли с полки и не отправили. Эти книги не должны учитываться, поскольку они недоступны для продажи, к тому же магазин ими больше не владеет. На складе должно оставаться 15, а не 17 экземпляров «Гамлета».
Еще одна гипотетическая ситуация состоит в том, что полка, предназначенная для романа «Гордость и предубеждение», оказалась пустой. Магазин уже купил 100 экземпляров у издательства, но грузовик с ними еще не доехал до склада. Поскольку эти книги — собственность магазина, они доступны для продажи и должны быть в наличии. То есть на складе должно быть 100 экземпляров «Гордости и предубеждения», а не 0. Может возникнуть и много других странных ситуаций. Система складского учета имеет сложную логику.
Продав три экземпляра «Гамлета», интернет-магазин отправит сообщение системе складского учета, чтобы та уменьшила количество копий «Гамлета» с 15 до 12. Но что, если вместо этого Джо Тестер купит –1 книгу? Количество имеющихся единиц «Гамлета» было равно 15 и должно уменьшиться на –1 — до 16 (рис. 2.5). Продажа одного анти-«Гамлета» увеличивает количество имеющихся экземпляров на 1!
Отправка антикниг
Система отправки заботится о том, чтобы клиенты получили свои книги. Когда интернет-магазин генерирует заказ, система отправки перебирает его позиции и составляет список, по которому работники склада должны упаковать товар. Это сложная система, которая пытается минимизировать труд работников, позволяя им, к примеру, собирать книги сразу для нескольких заказов. Процесс хорошо оптимизирован.
Однако система отправки не очень хорошо справляется с отрицательным количеством книг. Такая позиция в заказе приводит к исключению, которое записывается в системный журнал вместе с множеством других сообщений. К сожалению, в этот журнал никто никогда не заглядывает. Позиция заказа фактически отменяется.
Системы верят в одну и ту же ложь
Складывается интересная картина. С финансовой точки зрения информационные системы согласованы между собой. Системы биллинга и доставки не так важны, так как они не меняют свое состояние. Нас больше интересуют система складского учета и журнал дебиторской задолженности.
- Система складского учета ошибочно полагает, что имеется 16 экземпляров «Гамлета», хотя на самом деле их 15.
- Журнал дебиторской задолженности ошибочно полагает, что магазин должен кому-то деньги.
С финансовой точки зрения эти факты уравновешивают друг друга: вместо 15 книг и нулевой задолженности магазин получает 16 книг и долг, равный цене одной книги. Обе системы заблуждаются, но они верят одной и той же лжи. Эта иллюзия непротиворечива.
Поскольку системы согласованы, регулярные отчеты не показывают никаких расхождений. На самом деле некоторые из них генерируются каждую ночь, а другие, являющиеся частью финансовой отчетности, — ежеквартально. И ни в одном из них нет несоответствий, так как в информационных системах их попросту не было. Несоответствия существуют, но только в виде несогласованности между системой складского учета (16 книг) и фактическим количеством книг на складе (15). Но это можно было заметить только после инвентаризации, которая проводится в конце года. Она подразумевает ручной подсчет товара на складе с последующим его вводом в бухгалтерскую систему. Только это позволило бы заметить недостающую книгу.
Однако в расхождениях, выявленных во время ежегодной инвентаризации, нет ничего странного. Книги — это физические объекты, а на складе многое может случиться. Например, поставщик может передать 133 книги вместо 134. Иногда случается зафиксировать не все коробки или допустить ошибку при подсчете. Книгу могут уронить, повредить и выбросить. Это должно быть отмечено в системе, но иногда люди торопятся и забывают это сделать. Не исключено и воровство. Финансовый отдел относит все это к категории «потеряно на складе», и определенный уровень таких потерь вполне ожидаем.
Собственно говоря, ежегодная инвентаризация, проведенная несколькими месяцами ранее, показала, что потери на складе возросли. Руководство решило, что причиной была недостаточная мотивация у работников склада: возможно, они стали менее внимательными и повредили больше книг, а может быть, книги начали воровать. В итоге руководство отправило их на однодневный выездной семинар с тренером по мотивации, чтобы привести их ценности в соответствие с этикой компании. Складские рабочие были удивлены и не очень-то рады.
Самодельная скидка
При дальнейшем исследовании несогласованностей все оказалось хуже, чем выглядело сначала. Расхождения, выявленные на складе, существенно превысили общее количество возвратных накладных. Но и это был еще не конец.
Осознав, что обычным отчетам доверять нельзя, команда безопасности начала глубокое расследование. Оказалось, что получение возвратной накладной было не самым распространенным способом эксплуатации этого дефекта. Намного большей популярностью пользовались самодельные скидки в виде добавления отрицательных книг перед оформлением заказа, что уменьшало его итоговую сумму (рис. 2.6). Очевидно, что слухи об этой необычной возможности разлетелись по Интернету, так как ею пользовалось довольно много клиентов.
Расследование показало, что из-за этой лазейки компания потеряла значительную сумму денег. Пришло время решать, что с этим делать.
Мы вернемся к техническому дефекту чуть позже. Но что насчет тех денег, которые клиенты задолжали компании, выдавая себе скидки? В конечном счете решение об этом принимает совет директоров. После тщательного анализа ситуации было решено оставить все как есть. Преследование клиентов, среди которых много постоянных, вызовет у них неприязнь к компании и принесет больше вреда, чем если просто смириться с потерями, залатать дыру и двигаться вперед.
Непрерывное нарушение бизнес-целостности длилось месяцами, несмотря на то что формально все было в порядке. И оно, скорее всего, осталось бы незамеченным, если бы не любопытная сотрудница бухгалтерии и тестировщик безопасности, заинтересовавшийся бизнес-процессами (предметной областью, относящейся к продаже книг). Мы убеждены в том, что сегодня по всему миру можно найти множество подобных дефектов, которыми непрерывно пользуются, не вызывая никаких подозрений.
Оформить предзаказ бумажной книги можно на нашем сайте
