Във Microinvest Warehouse Open има проблем със сигурността, който на няколко пъти съм повдигал. За мое съжаление, хората от Microinvest го неглижират. С настоящия си постинг бих искал да дам публичност на проблема, така че от една страна хората, които ползват продукта да преценят до колко той отговаря на техните разбирания за сигурност, а от друга да стимулирам хората от Microinvest да го отстранят.
Microinvest Warehouse Open, както и повечето складово счетоводни програми, принадлежат към класа програми, предоставящи интерфейс върху някаква база данни. С други думи казано съхранението, манипулирането и управлението на данните се извършва от някаква СУБД (в случая на Warehouse Open това е MySQL), а приложният софтуер ни предоставя по-удобен начин да се случва това (не ни се налага да пишем директно сложни SQL команди). Когато се налага да се реализират някакви правила за достъп и промяна на данните сме изправени пред следната дилема – дали да ползваме функционалностите предоставени от СУБД или да направим нещо върху нея (ако е възможно), което да е реализирано в приложния софтуер.
Всяка себе уважаваща се СУБД предлага доста гъвкавост при управление на достъпа до данните. В повечето случаи не е трудно да се ограничи достъпа на потребителя до конкретна база данни, таблица, колони или редове в таблица, както и операциите, които може да прави върху дадени данни (да ги изтрива, променя по специфичен начин и т.н.). Имайки това в предвид, някак си съвсем естествено идва потребителите на приложния софтуер, да са потребители на СУБД. Разбира се, това може да наложи да се направят множество специфични изгледи на таблици или използването на stored procedures. Съответно, това усложнява структурата на базата данни и може би коства повече усилия да се реализира.
Другата възможност е сигурността да е реализирано в самия приложен софтуер. Най-често това става, като се съхранява таблица с потребители, информация за правата им за достъп и хешове на паролите им. Съответно, когато някой потребител се идентифицира в приложението, то проверява предоставената информация от съответната таблица. Ако всичко е успешно, то променя интерфейса си, съгласно зададените права за достъп. Предимството на този подход е че не се налага да се прави по сложна структура на базата данни и съответно времето за програмиране на приложението би било по-малко. Разбира се, това става на цената на редица недостатъци. За да може приложението да се закачи да СУБД, то трябва да използва потребител от СУБД. Този потребител, в термините на СУБД, трябва да има достъп за четене/промяна (поне) до данните, които управлява приложението. В частност и до таблицата с потребители на приложението. Основните рисковете, които крие тази реализация, са три:
- Данните за идентифициране пред СУБД трябва да се пазят в тайна. Разбиването на паролата на този единствен потребител, компрометира най-малко данните на използваното приложение. В същото време тази информация трябва да съхранява някъде, така че когато някой потребител иска да влезе в приложението, то да може да се закачи до СУБД.
- Ефективно всеки потребител на приложението има повече права, от колкото биха му били нужни за да си върши работата. Това от своя страна означава, че много по-лесно може да се използват грешки на самото приложение (sql injections, грешки в модела/интерфейса направата за достъп и т.н.).
- При злонамерени опити за прихващане на комуникациите между приложението и СУБД, чисто статистически най-вероятно е да има успех при потребителите, които най-често ползват приложението. Обикновено тези потребители (от бизнес гледна точка) не би трябвало да имат значителни права за работа върху данните. Така че компрометирането на техните account-и, не би трябвало да нанесе сериозни щети, ако управлението на сигурността на данните на приложението се извършва от СУБД. Когато самото приложение има грижата да управлява правата за достъп, то рискът от компрометиране на системата е значително по-висок.
Подходът за реализиране на системата за сигурност в приложния софтуер се ползва най-често в web базираните приложения. Като цяло крайният потребител има достъп единствено до интерфейса на приложението, така че възможностите му да прочете файла, в който приложението съхранява информацията за достъп до СУБД или да предприеме атаки върху комуникацията между СУБД и приложението са значително ограничени. Съответно негативните ефекти от реализирането на този подход са силно смекчени.
За съжаление това не е така при stand-alone приложенията. Ако чрез инструментите на операционната система би могло да се ограничат възможностите за атака (от компютъра на който работи приложението) на комуникацията между приложния софтуер и СУБД, то не е толкова лесно да се ограничи достъпа до файла, който съхранява информацията за достъп до СУБД. Като цяло затвореният софтуер разчита на security through obscurity подхода. Информацията се пази криптирана и се разчита, че само приложението знае алгоритъма и ключа който се използва за декриптирането и. Разбира се, този подход не работи при приложенията с отворен код, тъй като всеки би могъл до види използвания алгоритъм и ключ. За мое най-голямо учудване Microinvest Warehouse Open използва именно този подход.
Лесно може да видите информацията касаеща връзката до СУБД чрез:
cat ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep Db
Криптираната парола за достъп до MySQL се съхранява във value полето на DbPassword реда. Бърз поглед върху изходния код на Warehouse Open ни дава информация за използвания алгоритъм и ключ. Имайки тази информация, лесно може да видим паролата чрез тази команда:
cat ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep DbPassword | cut -f4 -d'"' | openssl enc -des-cbc -a -d -K 4d6963726f696e76 -iv 1234567890abcdef; echo
Мисля, че не е необходимо да обяснявам какви биха могли да бъдат последствията, ако паролата за достъп стане известна на злонамерен човек. Ако при инсталирането на Warehouse Open е използван административен потребител на MySQL, то рискът се пренася и върху другите приложения, които използват същия MySQL сървър.
Като цяло докато този проблем не бъде разрешен, не може да се разчита на правата за достъп на Warehouse Open. Съвсем тривиално е всеки да се сдобие с каквито права за достъп иска. Разбира се, това не добавя кой знае какъв допълнителен риск, ако всичко (приложен софтуер и СУБД) се върти на една машина, до която злонамерения потребител има физически достъп. В такава ситуация, макар и една идея по-трудно, могат да се случат доста неприятни неща. За съжаление, този проблем компрометира ситуации, в които машината, на която е разположена СУБД е добре физически и мрежово защитена.
