Какие риски безопасности возникают при использовании локального сервера для предоставления графического интерфейса для программы?
Я строю относительно простую программу для сбора и сортировки данных, вводимых пользователем. Я хотел бы использовать локальный сервер, работающий через веб-браузер, по двум причинам. \:
- HTML-формы - это простой и эффективный способ сбора необходимых мне данных.
- Я хочу иметь возможность запускать программу в автономном режиме без необходимости управлять рисками безопасности, связанными с доступом к удаленному серверу.
Изменить: Чтобы уточнить, я имею в виду, что приложение должно быть доступно только из локальной сети, а не из Интернета.
Когда я искал информацию по этой проблеме, я столкнулся с одним или двумя замечаниями о том, что локальные серверы имеют свои собственные угрозы безопасности, но я не совсем понимаю природу или серьезность этих рисков.
(Если это уместно, я буду использовать SWI-Prolog для обработки данных. Я также планирую использовать HTTP-пакет SWI-Prolog для сервера, но я готов пересмотреть этот выбор, если он окажется плохая идея.)
У меня есть два вопроса:
- О каких рисках безопасности нужно знать, когда для этого используется локальный сервер? (Примечание: в моем случае программа, скорее всего, будет иметь дело с какой-то очень конфиденциальной информацией, поэтому у меня нет места для какой-либо слабости в этом вопросе).
- Как можно снизить эти риски? (Или, где я должен искать, чтобы узнать, как решить эту проблему?)
Я очень благодарен за любую помощь!
3 ответа
Есть риски безопасности с любым решением. Вы можете использовать проверенные годами инструменты и однажды быть взломанными (из моего собственного опыта). И вы можете заплатить много за решение безопасности и никогда не быть взломанным. Итак, вам всегда нужно сравнивать усилия с воздействием.
По сути, вам нужно защитить 4 "двери" в вашем случае: 1. Авторизация (перехват пароля или, например, неправильное использование файлов cookie) 2. Протокол http 3. Ввод приложения 4. Другие способы доступа к вашей базе данных (не используя http, например, по ssh-порту со слабым паролем, заняв ваш компьютер или жесткий диск и т. д. В некоторых случаях вам нужно правильно зашифровать том)
1 и 4 не являются специфическими для Пролога, но 4 - только тот, который имеет некоторые специфические для локальных серверов.
Уровень защиты протокола http означает, что не разрешать запросы, которые могут контролировать ваш сервер swi-prolog. Для этой цели я рекомендую установить некоторый обратный прокси-сервер, такой как nginx, который может предотвратить атаки на этом уровне, включая некоторые типы DoS. Таким образом, браузер свяжется с nginx, и nginx перенаправит запрос на ваш сервер, если это правильный запрос http. Вы можете использовать любой другой сервер вместо nginx, если он имеет аналогичные функции.
Вам необходимо установить правильный ключ ssl и разрешить ssl (https) на обратном прокси-сервере. Это не должно быть в вашем сервере swi-prolog. Https зашифрует всю информацию и свяжется с swi-прологом по http.
Подумайте об авторизации. Есть методы, которые можно очень легко сломать. Вам нужно изучить эту тему, там много информации. Я думаю, что это самая важная часть.
Проблема ввода приложения - известный пример - "sql инъекция". Изучите примеры. Все хорошие веб-фреймворки имеют процедуры "входа" для очистки всех возможных инъекций. Возьми существующий код и перепиши его с прологом. Кроме того, проверьте все поля ввода с очень длинной строкой, различными символами и т. Д.
Как видите, безопасность не так проста, но вы можете выбрать подходящие меры, учитывая последствия взлома.
Также подумайте о возможном злоумышленнике. Если кто-то очень заинтересован, чтобы получить вашу информацию, все упомянутые методы хороши. Но это может быть редкий случай. Чаще всего хакеры просто сканируют интернет и пытаются применить известные хаки ко всем найденным серверам. В этом случае вашим лучшим другом должны быть Honey-Pots и сам пролог, потому что вероятность хакерского интереса к внутренним компонентам Swi-пролога крайне мала. (Хакеру нужно хорошо изучить код сервера, чтобы найти дверь).
Поэтому я думаю, что вы найдете адекватные методы для защиты всех конфиденциальных данных. Но, пожалуйста, никогда не используйте пароли с комбинациями слов из словаря и одним и тем же паролем, кроме как для одной цели, это самое важное правило безопасности. По той же причине вы не должны предоставлять своим пользователям доступ ко всей информации, но защита должна быть на уровне приложения.
Особые случаи для локального сервера - это хороший брандмауэр, правильная настройка сети и определение раздела жесткого диска, если ваш локальный сервер может быть украден "хакером".
Но если вы имеете в виду, что приложение должно быть доступно только из вашей локальной сети, а не из Интернета, вам нужно гораздо меньше усилий, в основном вам нужно проверить настройки маршрутизатора / брандмауэра и 4-ую дверь в моем списке.
В случае, если у вас очень ограниченное количество известных пользователей, вы можете просто предложить им использовать VPN, а не защищать ваш сервер, как в случае "глобального" доступа.
Я хотел бы отметить, что мое сообщение касалось проблемы безопасности с использованием переадресации портов в apache для доступа к серверу пролога.
И я знаю об успешной атаке на DOS-инъекцию пролога на веб-сайте SWI-Prolog на основе фреймворка http Я не верю, что автор сайта хочет обнародовать детали, но такая возможность, безусловно, реальна. Очевидно, что этот вектор атаки возможен только в том случае, если сайт оценивает полный код Тьюринга (или код, который он не может доказать, прекратит работу).
Простая мера предосторожности заключается в проверке объекта Request и отклонении запросов от чего-либо, кроме localhost.
Я хотел бы отметить, что сервер pldoc по умолчанию отвечает только на localhost. - Энн Огборн
Я думаю, что пакет SWI_Prolog http - отличный выбор. Ян Вилемейкер приложил много усилий, чтобы сделать его безопасным и масштабируемым.
Я не думаю, что вам нужно беспокоиться о внедрении SQL-кода. Было бы странно полагаться на SQL, когда у вас есть мощные возможности Prolog...
Конечно, вам нужно правильно управлять доступом http на вашем сервере... Как раз сегодня утром в списке рассылки SWI-Prolog появилась интересная статья на эту тему: Энн Огборн делится своим опытом...