Добро пожаловать, Гость
Логин: Пароль: Запомнить меня

ТЕМА: Системный подход к безопасности. А надо ли?

Системный подход к безопасности. А надо ли? 4 года 7 мес. назад #2255

Приветствую!

Более подходящего раздела найти не удалось. Есть сходный по тематике - "Авторизация", но авторизация это лишь мизерная часть системы обеспечения безопасности. Кстати, этот момент также заставляет усомниться в приверженности разработчиков системному подходу.
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


Применительно к нашим баранам нашему ЭЖД как ИС, нужен ли системный подход в построении системы безопасности? Строго говоря, не обязателен. Другое дело, что при этом может получиться:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


Полагая применение системного подхода в построении подсистемы информационной безопасности нашего ЭЖД оправданным, приступим.

Что есть ИС? В самом общем случае это информация плюс методы её обработки.
По мере апроксимации идеальной, умозрительной модели ИС к её действующему, реальному воплощению, разработчикам с системным подходом неизменно приходится пополнять перечни и самой информации, и методов её обработки новыми, вспомогательными списками, обусловленными и деталями применённых аппаратных средств, и условиями эксплуатации, и требованиями по обеспечению работоспособности при сбоях или вредоносных воздействиях.

То есть, определения для реальных ИС ЭЖД и подсистемы её безопасности будут выглядеть уже не так лаконично, но, тем не менее, строго:
- ИС ЭЖД - это совокупность программно-аппаратных средств для приёма, переработки, хранения и представления информации.
- безопасность ИС ЭЖД - это свойство сохранять свою функциональность на фоне неблагоприятных факторов.
- неблагоприятные факторы - аппаратные и программные сбои, несанкционированный доступ к ИС и её компонентам.
- подсистема обеспечения безопасности ИС ЭЖД - это набор методов и технологий, даже так, систематизированный набор методов и технологий по защите как информации, так и самой ИС.

Казалось бы, чего проще, построителям ИС с системным подходом надо формализовать перечень необходимых и достаточных средств, подобрать из существующих/создать свои, приемлемые по надёжности, прожорливости, удобству сопровождения, и интегрировать их в своё творение.

Возможно, в плане аппаратных средств это и проделано, всякие там резервирования, дублирования, бэкапы и откаты, на автоматической или полуавтоматической основе. Хотя, судя по тому, что до сих пор ЭЖД периодически недоступен, эта работа была проделана спустя рукава. Упоминания DDoS выглядят как отговорки, а выдаваемое сообщение, что "ЭЖД будет доступен через 6-7 секунд" - это костыль, заплатка, а вовсе не решение системной проблемы. Эти и подобные им казусы творятся на центральном оборудовании системы и конечным пользователям видны лишь опосредованно.

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

Возьмём, к примеру, такой элемент, касающийся безопасности, как передача приватных данных через публичные каналы. В нашем ЭЖД было решено использовать такой инструмент, как HTTPS. Вот только наличие даже превосходного инструмента ещё не гарантирует успешный результат без навыков использования. А в нашем ЭЖД, складывается такое навязчивое впечатление, HTTPS "прикручен" больше для галочки, чем для работы. Запомненные браузерами пароли не воспринимаются, в более чем одной вкладке работать невозможно. За Яндекс или Гугл почтой я подобных неудобств от применения этого же самого инструмента не наблюдал.

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


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

Далее, рассмотрим такой немаловажный элемент подсистемы обеспечения информационной безопасности, как технология аутентификации пользователей. Что имеем в нашем ЭЖД? Голый механизм, с высосанной из пальца, скорее всего пятиклассником, схемой генерации цифровых паролей, равных логину. Ведь существуют технологии генерации уникальных логинов/паролей не только из цифр, существуют же отработанные методики по составлению требований к устойчивости паролей, но применения их не видно. Что также не создаёт впечатления о системном подходе.
(В прошлогодичной редакции ЭЖД от МРКО были попытки привести систему выдачи доступов к тому виду, что аккаунт пользователя привязан к эл. почте, а свой пароль пользователь задаёт только сам, школьный админ его ни не видит, ни подменить не может. Может лишь выдать новый "код приглашения". В той реалиазии, правда, были два неприятных косяка, первый, "код приглашения" был чудовищной длины, а ведь даже такая монструозная компания, как МайкроСофт, на все миллионы своих инсталляций обходится двадцатипятизначными кодами, а второй, это то, что код нельзя было сгенерить персонально, только классу скопом. Если это не системный подход, то, по крайней мере, что-то очень похожее на подвижки в его сторону.)

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


Пожелания:

1. Доработать таки применение инструмента HTTPS до вменяемого, то есть так, чтобы запомненные пароли в любых браузерах воспринимались, чтобы работать можно было одновременно более чем в одной вкладке. (И так, чтобы высоким начальникам на понедельничных посиделках не приходилось рассуждать на тему кукисов, кешей и сессий).

2. Доработать таки механизм генерации логинов/паролей до включения не только цифр, но и знаков латинского алфавита. Это на текущий момент. А в перспективе - пересмотреть пагубную методику равенства пароля логину.

3. Возможно, счесть необходимым разработать некое "Cоглашение о пользовании услугами ЭЖД" для всех категорий пользователей, в котором, среди прочих прав и обязанностей, явно указать ответственность пользователя за сохранность своих учётных данных.
Племя — это всего лишь мысль, приковывающая мыслящего к вечной войне с теми, кого не отпускают иные мысли. © Барри Лонгиер. "Враг мой".
Администратор запретил публиковать записи гостям.
Спасибо сказали: Николай, Галкин Ярослав

Системный подход к безопасности. А надо ли? 4 года 7 мес. назад #2262

  • Галкин Ярослав
  • Галкин Ярослав аватар
  • Вне сайта
  • Администратор
  • ГБОУ Школа № 2051
  • Сообщений: 1589
  • Спасибо получено: 492
  • Репутация: 36
Поддерживаю
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2272

  • Черенков Максим
  • Черенков Максим аватар
  • Вне сайта
  • Администратор
  • Сообщений: 2587
  • Спасибо получено: 991
  • Репутация: 38
Пожелания:
1. Доработать таки применение инструмента HTTPS до вменяемого, то есть так, чтобы запомненные пароли в любых браузерах воспринимались, чтобы работать можно было одновременно более чем в одной вкладке. (И так, чтобы высоким начальникам на понедельничных посиделках не приходилось рассуждать на тему кукисов, кешей и сессий).
А как это связанно между собой?! Как кэш БД связан протоколом HTTPS и хранением параметров в куки?! Сейчас звучит не как предложение, а как каша. Что конкретно Вы планируете к доработке в HTTPS? Сертификаты, дополнительные средства защиты каналов, токены?
2. Доработать таки механизм генерации логинов/паролей до включения не только цифр, но и знаков латинского алфавита. Это на текущий момент. А в перспективе - пересмотреть пагубную методику равенства пароля логину.
Это, безусловно, принимается. Но не сегодня. Сначала важно закрыть все процедурные вопросы, связанные с отладкой входа, синхронизацией данных из 3 сторонних по отношению к ЭЖД систем.
3. Возможно, счесть необходимым разработать некое "Cоглашение о пользовании услугами ЭЖД" для всех категорий пользователей, в котором, среди прочих прав и обязанностей, явно указать ответственность пользователя за сохранность своих учётных данных.
Это правильно. В целом так и должно быть. Но тогда все пользователи систем, использующие ботов под учетными данными админов, получат колоссальные проблемы. Хотя мне кажется, что они к ним готовы.
С уважением,
зам. директора ГМЦ
Черенков Максим
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2277

Черенков Максим В. пишет:
Пожелания:
1. Доработать таки применение инструмента HTTPS до вменяемого, то есть так, чтобы запомненные пароли в любых браузерах воспринимались, чтобы работать можно было одновременно более чем в одной вкладке. (И так, чтобы высоким начальникам на понедельничных посиделках не приходилось рассуждать на тему кукисов, кешей и сессий).
А как это связанно между собой?! Как кэш БД связан протоколом HTTPS и хранением параметров в куки?! Сейчас звучит не как предложение, а как каша. Что конкретно Вы планируете к доработке в HTTPS? Сертификаты, дополнительные средства защиты каналов, токены?

Э... Максим Вячеславович, я могу себе представить, насколько трудоёмко и утомительно просеивать "тонны словесной руды", тем более чужой и, зачастую, вываленной с недоброжелательством или агрессивностью. Я постараюсь свою мысль перефразировать.
К сертификатам особых претензий нет. Доработки самого HTTPS я не предлагаю. Мои нарекания к использованию HTTPS никак не связаны с кешем БД, никакой каши. Я прошу рассмотреть возможность доработки самого способа использования того конгломерата возможностей, что может HTTPS, вовсе не обязательно, полного. Лишь необходимого для должного уровня безопасности, но, вместе с тем, достаточного для комфортной работы конечных пользователей.
Неудобство первое - отвергание запомненного в Mozilla Firefox пароля.
Неудобство второе - вторая вкладка, открытая в браузере из под того же логина, нефункциональна, вернее, просмотр первого выданного экрана возможен (данные уже в браузере), а какое-либо значимое действие, ведущее к обновлению страницы, возвращает вид второй вкладки к последней проведённой операции в первой.
Самый близкий пример для сравнения - Яндекс или Гугл почты. В их процедурах авторизации запомненный средствами браузера пароль нормально воспринимается, а интерфейс позволяет работать одновременно на нескольких вкладках с разными наборами данных.
Кстати, Сбербанк-Онлайн каким-то образом препятствует сохранению пароля (в Mozilla Firefox), о чём вежливо сообщает.

Черенков Максим В. пишет:
... пользователи систем, использующие ботов под учетными данными админов...

Если честно, не представляю, для каких задач и в каких случаях это может потребоваться. Была, правда, мысль, приспособить какой-либо граббер сайтов для слива экспортных копий журнала попредметно в конце триместра, так как экспорт единой копии на продакшене тогда не работал. Но случилась пропажа оценок, потом КТП, потом мысль и вовсе затёрлась и погасла.

Всем удачи!

PS Иногда в конце рабочего дня ощущаю себя в ситуации, подобной анекдоту из советских времён (причём, и с той и с другой стороны):
Хулиган милиционеру: - Слышь, хочешь анекдот расскажу?
М: - Давай.
Х: - Политический.
М: - Ты что, я же милиционер.
Х: - Так я два раза расскажу.
Племя — это всего лишь мысль, приковывающая мыслящего к вечной войне с теми, кого не отпускают иные мысли. © Барри Лонгиер. "Враг мой".
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2278

  • Галкин Ярослав
  • Галкин Ярослав аватар
  • Вне сайта
  • Администратор
  • ГБОУ Школа № 2051
  • Сообщений: 1589
  • Спасибо получено: 492
  • Репутация: 36
Сюда же напишу по 152-ФЗ и здравому смыслу. В тест версии детям дали информацию по сотовым телефонам учителей, это раз. ЛИЧНЫЕ телефоны учителей нужны для служебных целей, или предлагаете учителям два телефона заводить. Формы "написать сообщение" вполне достаточно. А вот дать такую информацию учителям, в частности телефоны родителей их обучающихся. Следовало. С точки зрения все того-же 152-ФЗ это допустимо. Учитель может использовать ПДн ребенка и родителей в служебных целях, а именно пригласить на беседу, известить об успеваемость, поблагодарить (почему нет?). Мне кажется разработчики просто перепутали кому, какой доступ нужно дать. Пожалуйста повнимательней относитесь к 152, а то про детей и родителей мы помним, а про учителей забываем. Мы тоже люди и имеем право на неприкосновенность личной жизни. Я сам решу дать всем свой телефон, рассказать сколько мне лет, сколько у меня детей, к я живу и т.д. И если так решу, то размещу эту информацию на своем личном сайте.
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2280

  • Черенков Максим
  • Черенков Максим аватар
  • Вне сайта
  • Администратор
  • Сообщений: 2587
  • Спасибо получено: 991
  • Репутация: 38
Давайте по всему разом:
[qoute] Я прошу рассмотреть возможность доработки самого способа использования того конгломерата возможностей, что может HTTPS, вовсе не обязательно, полного. Лишь необходимого для должного уровня безопасности, но, вместе с тем, достаточного для комфортной работы конечных пользователей.[/quote]
Ну пока говорить о безопасности (в полном понимании) в текущей реализации, правда, смешно. Но давайте соберем по этому поводу предложения и повесим их пока в планы доработки без установленной даты?
вторая вкладка, открытая в браузере из под того же логина, нефункциональна, вернее, просмотр первого выданного экрана возможен (данные уже в браузере), а какое-либо значимое действие, ведущее к обновлению страницы, возвращает вид второй вкладки к последней проведённой операции в первой.
Может быть для начала рассмотреть вариант технологической страницы с одновременным выводов всех необходимых сведений? Или экспорта какого-то специфического (настраиваемого) отчета? Для этого нужны случаи, когда Вам требуется вывод журнала в несколько вкладок.
Хулиган милиционеру: - Слышь, хочешь анекдот расскажу?
М: - Давай.
Х: - Политический.
М: - Ты что, я же милиционер.
Х: - Так я два раза расскажу.
Шутка, повторенная дважды, становится более понятной (c) Фоменко
С уважением,
зам. директора ГМЦ
Черенков Максим
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2286

Черенков Максим В. пишет:
Может быть для начала рассмотреть вариант технологической страницы с одновременным выводов всех необходимых сведений? Или экспорта какого-то специфического (настраиваемого) отчета? Для этого нужны случаи, когда Вам требуется вывод журнала в несколько вкладок.

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


Здесь в двух словах не опишу, могу лишь привести обход разработчиками своих же граблей в текущей версии.
Под ролью админа недавно был банер выверки контингента, сейчас есть ссылка "Поддержка". По нажатию открывается новое окно, залогиненное под тем же пользователем. Теперь, в первичном окне можно лазить по журналу, выискивая и копируя инфу о проблеме, а в дочернем окне вносить найденные сведения. А в Яндекс-почте или том же СбербанкОнлайн я могу без особых ухищрений открыть вторую вкладку, настолько же полноценную, как и первая.

вариант ... страницы с ... выводов всех необходимых сведений
- это не какой-то мифический "технологический" инструмент, нужный раз от разу, а вполне себе законченный плоский интерфейс (такой был в позапрошлогодней реализации ЭЖД МРКО). "Одновременный" доступ ко всей информации это слишком, достаточно сделать её доступной в один-два клика, с возможностью в один же клик вернуться на предыдущую ступень, а также в один клик переходить от одного блока однотипной инфы к другому. Навскидку, в интерфейсе АИС "Контингент" сделано нечто подобное, когда в левом столбце список классов: текущий выделен; один клик и мы в любом другом классе. А вот при выборе ученика, они от плоскостности уже уходят - открывается новая страница, с новым набором инфы, перейти к другому ученику уже не так просто.
Племя — это всего лишь мысль, приковывающая мыслящего к вечной войне с теми, кого не отпускают иные мысли. © Барри Лонгиер. "Враг мой".
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2326

  • Черенков Максим
  • Черенков Максим аватар
  • Вне сайта
  • Администратор
  • Сообщений: 2587
  • Спасибо получено: 991
  • Репутация: 38
Здесь в двух словах не опишу, могу лишь привести обход разработчиками своих же граблей в текущей версии.
Под ролью админа недавно был банер выверки контингента, сейчас есть ссылка "Поддержка". По нажатию открывается новое окно, залогиненное под тем же пользователем. Теперь, в первичном окне можно лазить по журналу, выискивая и копируя инфу о проблеме, а в дочернем окне вносить найденные сведения.
Ну, во-первых, это не свои же грабли, а просто пришла команда ДИТ разбираться с ЭЖД.
Во-вторых, это окно задумывалось как "стороннее" по отношению к интерфейсу ЭЖД. Там генерировалась служебная информация для hpsm так, чтобы Пользователь мог свободно перемещаться между классами, контингентом, кадрами. Но! Это окно не могло "дублировать" функционал ЭЖД. Т.е., например, одновременно выставить разные отметки одному учащемуся и предмету Вы не могли.
Также существуют и технологические трудности как раз связанные с безопасностью. Вы не увидите в Сбере или Яндекс.деньгах двух окон транзакций.
При этом в ЭЖД очень много полей с аякс, который либо что-то тянет из базы, либо туда что-то кладет. Открытие двух-трех вкладок значительно повышает нагрузку. Но это мне так кажется, возможно, разработчики так не считают.

А можете описать задачи, которые требуют от Вас открытия нескольких вкладок?
С уважением,
зам. директора ГМЦ
Черенков Максим
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 6 мес. назад #2364

Черенков Максим В. пишет:
Ну, во-первых, это не свои же грабли, а просто пришла команда ДИТ разбираться с ЭЖД.
Мне, непосвящённому в тонкости переподчинения или делегирования частей/зон ответственности ЭЖД, это не известно, да и не особо нужно. Я имею дело с конечным интерфейсом ИС ЭЖД.

Во-вторых, это окно задумывалось как "стороннее" по отношению к интерфейсу ЭЖД. Там генерировалась служебная информация для hpsm так, чтобы Пользователь мог свободно перемещаться между классами, контингентом, кадрами. Но! Это окно не могло "дублировать" функционал ЭЖД. Т.е., например, одновременно выставить разные отметки одному учащемуся и предмету Вы не могли.
И мыслей не было об адаптации этого инструмента под что-то ещё.

Также существуют и технологические трудности как раз связанные с безопасностью. Вы не увидите в Сбере или Яндекс.деньгах двух окон транзакций.
При этом в ЭЖД очень много полей с аякс, который либо что-то тянет из базы, либо туда что-то кладет. Открытие двух-трех вкладок значительно повышает нагрузку. Но это мне так кажется, возможно, разработчики так не считают.

Тут дело вот в чём, HTTPS - это инструмент для установки и ведения шифрованных соединений, а вот тем, сколько соединений или сколько сессий в рамках одного соединения разрешено установить клиенту, ведает сервер.
Весь вопрос в том, что в ЭЖД сейчас ограничение в одну рабочую вкладку сделано осознанно (в стремлении снизить нагрузку) или по ошибке/недогляду.
Но кто мне мешает открыть другой браузер или включить соседний компьютер? Так что такое ограничение нагрузки представляется малопродуктивным.

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

Расписание.
В моей школе завуч средней школы составляет расписание в Excel. Распечатка выглядит как два листа формата А3. Один - "по ученикам", второй - "по учителям". На каждом из листов сразу все классы (16 штук).
В ЭЖД точной аналогии нет, ближайшие это "расписание" и "занятость". После заполнения расписания в ЭЖД, для проверки правильности как составленного бумажного варианта, так и его электронного отображения, используются оба листа. То есть, внеся расписание "по детям", переходим в "занятость" и смотрим как она сформировалась.
При обнаружении ошибок начинается чехарда с прыганием между "меню->расписание->редактирование расписания" и "меню->расписание->занятость".
В такой ситуации было бы удобнее переключаться между двумя вкладками. Как в интерфейсе совместить эти две формы на одной вкладке пока даже не задумывался. Вполне возможно, такой способ выверки расписания и не применяется нигде.

Корректировка членства учеников в группах в интерфейсе "Завуч->Формирование учебного плана"
(Неудобства описываемые далее касаются очень многих мест всего интерфейса ЭЖД, почему и хотел писать про них отдельную тему.)
Итак, список классов просится быть распарсенным на отдельные вкладки потому, что:
а) после отработки одного класса, чтобы перейти к следующему, надо жмакнуть "К списку классов / групп", при этом не забыв, какой класс сейчас отработан, ведь список откроется девственно чистым, без каких либо намёков (выделений, подсветок) на то, с чем только что работали. (В редактировании расписания список классов постоянно находится в зоне видимости и имеет выделенным текущий класс)
б) дойдя до нижнего на экране пункта, а после его отработки, для доступа ко всем последующим необходимо каждый раз прокручивать экран вниз (в смысле, чтобы содержимое поднялось наверх). А там уже, (вспоминая, что было, что не было) выбирать следующий. И так столько раз, сколько пунктов у меня не влазит на первый экран.

Понажимав бы последовательно ПКМ на каждом элементе списка классов по одному разу и выбрав браузерную опцию "открыть в новой вкладке", заодно прокрутив весь список до конца один лишь раз, я бы имел во вкладках все классы, во первых, ни один не пропустив, во-вторых, не перекручивая экран надцать раз.


Да, неудобство не смертельное, да в текущем варианте работу проделать можно. И, ДА, я прекрасно понимаю и очень хочу, чтобы в первую очередь были найдены и устранены причины потери/искажения информации. И обсуждение интерфейсных качеств или качественных интерфейсов предлагаю перенести в соответствующую ветку форума.
Племя — это всего лишь мысль, приковывающая мыслящего к вечной войне с теми, кого не отпускают иные мысли. © Барри Лонгиер. "Враг мой".
Администратор запретил публиковать записи гостям.
Спасибо сказали: Сергей

Системный подход к безопасности. А надо ли? 4 года 2 нед. назад #7815

  • Олег
  • Олег аватар
  • Вне сайта
  • Живу я здесь
  • ГБОУ Школа 1205
  • Сообщений: 1858
  • Спасибо получено: 1066
  • Репутация: 42
Хммм... Честно говоря, я в замешательстве!

Совершенно случайно обнаружил, что некоторые функции псевдо-API ЭЖД МРКО дают доступ к данным, которые НЕ относятся к текущей школе!!!
Т.е., к примеру, авторизовавшись в своем ЭЖД, я могу легко с помощью простенького POST-запроса на javascript прямо из браузера получить информацию о пропусках ЛЮБОГО ученика из базы ЭЖД МРКО по его идентификатору!
Подтвердить не могу (т.к. у меня нет доступа в ЭЖД других школ), но практически на 100% уверен - смогу с помощью этого же запроса ИЗМЕНИТЬ статус любых пропущенных уроков у любого ученика из базы ЭЖД МРКО!

Другие псевдо-API не пробовал на этот счет - просто не было необходимости - но, если такая "дыра" в безопасности есть в одном запросе, то более чем вероятно, что есть и в других - как разработчик ПО знаю, что подобные API-функции пишутся по шаблону, и если общий функционал (каковым является защита) изначально не предусмотрен в одной функции, то он не будет реализован и в других похожих функциях!
Последнее редактирование: 4 года 2 нед. назад от Олег.
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 2 нед. назад #7820

  • Павел (ОЭЖД)
  • Павел (ОЭЖД) аватар
  • Вне сайта
  • Живу я здесь
  • ГБОУ школа №236
  • Сообщений: 1886
  • Спасибо получено: 489
  • Репутация: 42
А откуда вы возьмете идентификатор ученика другой школы?
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 2 нед. назад #7828

  • Олег
  • Олег аватар
  • Вне сайта
  • Живу я здесь
  • ГБОУ Школа 1205
  • Сообщений: 1858
  • Спасибо получено: 1066
  • Репутация: 42
Павел пишет:
А откуда вы возьмете идентификатор ученика другой школы?
А это обычное число. 6-7 разрядное. Ради интереса попробовал - перебрал несколько тысяч среди 6 разрядных и несколько тысяч среди 7 разрядных - практически по всем идентификаторам получил ФИ детей (это API отчество не выдает)! Столько интересных имен среди иностранцев! Даже было несколько, у которых часть имени вбита большими буквами типа аббревиатур!
Последнее редактирование: 4 года 2 нед. назад от Олег.
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 2 нед. назад #7831

  • Павел (ОЭЖД)
  • Павел (ОЭЖД) аватар
  • Вне сайта
  • Живу я здесь
  • ГБОУ школа №236
  • Сообщений: 1886
  • Спасибо получено: 489
  • Репутация: 42
Олег пишет:
Павел пишет:
А откуда вы возьмете идентификатор ученика другой школы?
А это обычное число. 6-7 разрядное. Ради интереса попробовал - перебрал несколько тысяч среди 6 разрядных и несколько тысяч среди 7 разрядных - практически по всем идентификаторам получил ФИ детей (это API отчество не выдает)! Столько интересных имен среди иностранцев! Даже было несколько, у которых часть имени вбита большими буквами типа аббревиатур!
Это логин который в смысле?
Администратор запретил публиковать записи гостям.

Системный подход к безопасности. А надо ли? 4 года 2 нед. назад #7832

  • Олег
  • Олег аватар
  • Вне сайта
  • Живу я здесь
  • ГБОУ Школа 1205
  • Сообщений: 1858
  • Спасибо получено: 1066
  • Репутация: 42
Павел пишет:
Это логин который в смысле?
Нет. Это уникальный идентификатор каждого ученика в системе МРКО ЭЖД. Т.е., у каждого объекта в ЭЖД есть свои уникальные идентификаторы. Некоторые из них - локально-уникальные на уровне базы школы (у классов, предметов, КУПов), некоторые глобально-уникальные на уровне всей базы ЭЖД. Такие глобально-уникальные идентификаторы имеют учителя/ученики/родители. В принципе, конечно, есть прямая связь между этими идентификаторами и логинами-паролями этих объектов. Но, если логин-пароль любого из этих объектов можно легко изменить без каких либо проблем для целостности информации в базе, то идентификаторы никогда не меняются - именно они обеспечивают связь между объектами внутри базы.

По уму, любое API должно делать проверку на принадлежность ученика/учителя/родителя к школе, из под учетной записи которой производится запрос к этому API.
Разработчики очевидно решили этого не делать. Или просто банально упустили это из виду.
В некоторой степени понять их можно - официального API у ЭЖД нет и использует его только интерфейс самого ЭЖД, где по определению не может быть "левых" запросов.

Именно эту уязвимость, очевидно, имел в виду автор мобильного приложения для ЭЖД, когда в одной из тем в этом форуме писал про возможность из под учетки одного ученика получить доступ к оценкам любого другого ученика - если в дневнике ученика активно используется такое API, то действительно легко можно отправить из дневника ученика запрос к API с идентификатором любого другого ученика и получить его оценки!
Администратор запретил публиковать записи гостям.

Поиск на Форуме

Ключевое слово