Почему «электронные дневники» до сих пор ненадежны в образовании?

- КиТ :: Будь в СЕТИ!

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

Если говорить конкретно, то электронных дневников. Как известно, цифровые внедрения нынче повсеместны: школы и университеты заводят собственные странички в социальных сетях и блогах для информирования о происходящем, редкое учебное заведение не имеет собственного сайта, а электронные журналы вот-вот окончательно вытеснят бумажные… И это лишь часть тех перемен, которые происходят у нас на глазах. Конечно же, в информационный век этому уже не приходится удивляться: люди привыкли, что вся интересующая их информация находится интернете.

Очевидно, эти процессы инкапсулируют в себе и немалую ответственность как со стороны пользователей, так и со стороны разработчиков. Теперь недостаточно, уходя из кабинета, запирать дверь на ключ, оставляя позади нее всё важное. В цифровом мире физическая недоступность не является гарантией безопасности (однако, несомненно, этот аспект крайне важен в плане обеспечения комплексной безопасности). Но, обо всем по порядку. Проблема #1: человеческий фактор.

«Самая большая уязвимость любой информационной системы — это её пользователь»(с) С этим высказыванием трудно поспорить — человек есть человек. Именно эта проблема является ключевой в плане надежности и безопасности информационных ресурсов как со стороны пользователей, так и разработчиков. Эта проблема актуальна ровно столько, сколько существует сам человек, а поэтому она не относится к цифровому миру, как таковому. Ведь и во времена, предшествующие цифровым, например, бумажный журнал было доверено переносить конкретному человеку (старосте, кажется), который, в общем-то, мог бы пользоваться своим положением или быть использованным другими своими одногруппниками, что в конечном счете вполне могло привести к подделке оригинальной информации, ее компроментации. Другой пример, когда виновниками выступают уже не доверенные лица, а непосредственные «владельцы» информации. Если рассматривать это на конкретном примере, то легко представить себе обычного, скажем, секретаря, не подумавшего не только забрать, но и вообще закрыть журнал с важной информацией на время своего отсутствия в кабинете. Такое бывает и нередко. Это также может привести к утечке/подделке важных для учреждения сведений.

В современное время примеры неаккуратности человеческого фактора остаются идентичными, разве что бумажки заменяются компьютерами. На самом деле это несет еще большую угрозу. Если запрограммировать и «заразить» бумажку было нельзя, то с компьютерами все обстоит иначе.

Редкий сотрудник (по крайней мере, в сфере школьного образования) нажимает Win+L, отлучаясь по делам, некоторых в принципе не заботит, стоят ли пароли на их учетных записях Windows, а третьи вообще пускают за свой ноутбук чуть ли ни каждого встречного… Все это лишь усугубляет и без того ненадежные системы. Вы можете использовать самые безопасные браузеры, накачать дюжину различных антивирусов и даже использовать уникальный пароль учетной записи, но если пускать за свое место других людей без пристального наблюдения за их действиями, ничто не сможет гарантировать надежность рабочего места и отсутствие утечек.

Теперь хотелось бы привести простой пример эксплуатации «человеческого фактора».

Есть добрый преподаватель географии Иван Иванович, который попросил своего «ученика-компьютерщика» Антона Антоновича разобраться с тем, почему на его компьютере нет звука в презентации(обычная проблема). Ученик, быстро разобравшись с проблемой, пока Иван Иванович пишет на доске материал к следующему уроку, подумывает о перехвате данных своего учителя с этого компьютера(часто это почта, логины-пароли от соц.сетей и электронных журналов и т.д). Заранее Антоном был заготовлен злобный JavaScript-сценарий, являющийся частью его self-made сниффера: И «ученик-компьютерщик» решает встроить свой скрипт внутрь любимого браузера Ивана Ивановича. Сделать Антон это может как стандартными средствами, предоставленными непосредственно браузерами, так и сторонними, вроде расширений TamperMonkey(Chrome), GreaseMonkey(FireFox) и т.д. После чего он довольно встает с захваченного PC и идет с улыбкой к любимому учителю географии, информируя его о починке исходной проблемы. Но с этого момента все вводимые данные на захваченном компьютере будут течь к Антону. Для более пущего эффекта он может сбросить всю историю браузера, включая запомненные ранее аутентификационные данные из форм.

Кроме того, Антон может попытать счастье и постараться вытащить пароль учетной записи Windows, используя средства наподобие (WindowsCredentialsEditor). Ведь вряд ли у Ивана Ивановича десяток различных паролей — так ведь неудобно — поэтому, вполне вероятно, что всего один единственный ;)

Проблема #2: ненадежность информационных ресурсов(электронных журналов)

Начать, пожалуй, следует с того, что ни один электронный журнал, встретившийся мне, не обладал должной системой защиты и системой выявления несанкционированного доступа. Я не хотел бы их перечислять. Все они, с точки зрения *безопасной* авторизации, напоминали какие-то форумы и многочисленные сайты-пиратки, построенные на движке DLE. Везде для входа в свой кабинет нужно было лишь указать логин(который часто представлял из себя email) и пароль. Ни о какой истории входов-выходов и информации об открытых «висячих» сессиях и речи нет. Однако данные, находящиеся внутри, все же представляют определенную ценность.

Рассмотрим пример на реально существующем электронном журнале, который функционировал в течении целого года.

Предположим, тот самый «ученик-компьютерщик» этим же вечером, придя домой и проанализировав свой лог, получил несанкционированный доступ к учетной записи преподавателя: авторизовавшись, Антон увидел следующую картину: что натолкнуло его на мысль о том, что имея в руках auth-данные лишь одного сотрудника своего образовательного учреждения(Ивана Ивановича), он может управлять всеми оценками любого юнита, входящего в состав этого учреждения. Это довольно странно, ведь это идет вразрез с простейшими правилами доступа.

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

Что-либо изменить просто так не удастся, т.к на данный момент уже прошло слишком много времени. Но если заглянуть в исходный код и посмотреть, как все устроено, можно увидеть следующее: Синим обозначено то, что якобы не подлежит замене, красным — что изменяемо. Сразу появляется мысль подставить данные из уязвимого красного блока в синий, т.е заменить SPAN на INPUT. После срабатывания JS-события onChange происходит следующее: Сработала одна из систем, отвечающих за надежность данных. Однако, если вспомнить, что есть , то комментарий можно будет скрыть.

После нажатия на кнопку и обновления страницы можно увидеть: Замороженные данные были подвержены изменению? Да. А причина тому кроется в том, что разработчики данного дневника не подумали проверять данные на серверной стороне. Они доверчиво принимают параметры от клиента, а сервер, как зомби, тупо прожевывает их, не сомневаясь в надежности…

Но, как оказалось, комментарии можно и вовсе обойти, а присутствие/отсутствие на конкретном уроке подделать, что в общем-то уже менее серьезно. Достаточно перейти на страницу урока( ? ссылка в заголовке таблицы ? ): Здесь есть возможность добавить оценку(значок «плюсик»), но не изменить уже существующую(замороженную). Красным цветом снова показано «уязвимое» место системы, а синим — его эксплуатация. Здесь просто воспользоваться методом замены не получится( нельзя просто так взять и заменить DIV на A ), потому что тег ссылки содержит в себе служебные параметры: ID оценки и ID человека, которому она принадлежит. По нажатию на ссылку всплывает окно, ассоциированное с данными оценки. Поэтому для эксплуатации придется совсем немного подкорректировать параметры ссылки: Теперь, если произвести замену, изменить и обновить: Снова удалось заменить замороженные данные. Даже без указания комментария(причины)!

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

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

Исследование HTTP-запросов показало, что комментарий не учитывается вообще — это просто сторонний параметр, который может быть и пустым(значение на пустоту проверяется на клиентской стороне).

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

Проблема #3: нежелание исправлять свои ошибки.

В начале описания проблемы#2 было сказано, что уязвимый электронный журнал функционировал в течении целого учебного года. Исследование же журнала было проведено почти в самом начале учебного года, разработчики и администрация были проинформированы, однако ни одной ошибки так и не было исправлено за всё прошедшее время. Вполне вероятно, что проблемой#1, связанной с человеческим фактором, воспользовалось множество учеников из разных образовательных учреждений, что в итоге могло привести к массовой подделке исходных данных. Проблема#2 лишь усугубляет эту ситуацию.

Сотрудники образовательных учреждений так же продолжают предоставлять доступ к своим компьютерам каждому встречному, не наблюдая за их действиями. Некоторые позаботились о смене своих «штатных» паролей(или их первоначальной установки). В целом ничего не изменилось, и уровень как безопасности, так и надежности остался на прежнем уровне.

Вывод

Проблема, как и положено, кроется в корне. Чтобы ее можно было как-то искоренить, необходимо заставлять людей задумываться о безопасности их рабочего места, о том, что вокруг «ходит» слишком много угроз. Утечка и несанкционированный доступ — часто лишь вопрос времени не только в контексте современных образовательных учреждений. Но на их примере очень легко убедиться в некомпетентности многих сотрудников. На примере электронного журнала() стало видно, что некомпетентность лишь одного человека может повлечь за собою крах, в данном случае, всей системы оценивания.

Многие школьные учителя еще только осваиваются в плане электронных ресурсов, но когда однажды(уже очень скоро) произойдет повсеместный полноценный переход от «олдскульных» бумажных журналов к электронным, необходимо будет уметь объективно оценивать угрозы не только пользователям, но и разработчикам подобных ресурсов. Необходима тщательно проработанная система авторизации, которая бы позволяла отслеживать неправомерный доступ; необходимы и системы логгирования входов и отслеживания открытых сессий текущего аккаунта; необходимо и как можно более сузить области ответственности отдельных аккаунтов.

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

ПодпискаБудь в СЕТИ! Новости социальных сетей - всегда актуальное
 
Группы: ВК | OK | Tg