lwIP на 32-битном микроконтроллере Stellaris - безопасный вход
Я хочу использовать свой микроконтроллер Stellaris LM3S8962 в качестве моста между Интернетом и группой датчиков. Я буду использовать узлы Zigbee для связи от датчиков к микроконтроллеру. Мне удалось использовать стек TCP/IP lwIP (для LM3S8962) для доступа к HTML-страницам, хранящимся во флэш-памяти контроллера.
Теперь я хочу добавить систему безопасного входа в систему для того же. То, что я в основном хочу, - то, что - когда я ввожу IP-адрес контроллера в браузере, он должен запросить у меня имя пользователя и пароль. Я хочу сделать эту систему максимально безопасной, используя стек TCP/IP lwIP.
К вашему сведению, стек не поддерживает PHP или любые другие скрипты. Функция CGI (в C) поддерживается, но я не знаю, как реализовать часть безопасности. Пожалуйста, руководство.
1 ответ
Есть в основном два способа аутентификации пользователей по HTTP на вашей платформе:
- "классическая" базовая HTTP-аутентификация (точную спецификацию см. в RFC2616),
- форма входа в систему, создание идентификатора сеанса и его возврат в браузер для сохранения в файле cookie или в URL-адресе.
Обычная HTTP-аутентификация работает, когда вы вставляете проверку в подпрограмму обслуживания веб-страницы, чтобы увидеть, существует ли HTTP-заголовок авторизации. Если есть, вы должны декодировать его (см. RFC) и проверить указанное имя пользователя / пароль. Если учетные данные в порядке, перейдите к обслуживанию веб-страницы. Если учетные данные неверны или заголовок авторизации отсутствует, вы должны вернуть код ошибки 401. Затем браузер запросит у пользователя учетные данные. Это решение довольно простое, и вы получите диалоговое окно входа в браузер, а не красивую HTML-страницу. Кроме того, микроконтроллер должен будет проверять учетные данные для каждого запроса страницы.
Аутентификация через форму входа в систему работает на вашем сервере, поддерживая список должным образом аутентифицированных пользовательских сеансов (возможно, в памяти) и проверяя запрос по этому списку. После входа в систему для этого сеанса должен быть создан уникальный случайный идентификатор, а данные сеанса должны быть внесены в ваш список. Новый идентификатор сеанса должен быть возвращен браузеру для включения в предстоящие HTTP-запросы. Вы можете выбрать идентификатор сеанса для добавления в cookie-файл браузера или встроить его в URL-адрес в качестве параметра URL-адреса (? Id=xxxxx). Параметр URL внедряется путем отправки ответа 302 Redirection в браузер с новым URL. Если вам нужно решение для файлов cookie, вы можете отправить ответ на запрос входа в систему с заголовком HTTP-ответа Set-Cookie. В решении формы входа в систему фактические учетные данные (имя пользователя / пароль) проверяются только один раз при входе в систему. После этого в списке активных сеансов проверяется только идентификатор сеанса. Идентификатор сеанса должен быть извлечен из запросов для каждой обслуживающей веб-страницы (из URL-адреса или из заголовка Cookie HTTP). Кроме того, вам нужно будет реализовать какое-то время ожидания сеанса, как в качестве меры безопасности, так и для установления ограничений на размер списка активных сеансов.
Теперь самое сложное: в обоих решениях имя пользователя / пароль передаются в некоторых запросах (в каждом запросе для базовой HTTP-аутентификации и на странице входа POST для решения формы входа) и могут быть извлечены из сетевого трафика. Кроме того, информация, необходимая для захвата сеанса, присутствует в каждом запросе в обоих решениях. Если это проблема (система работает в свободно доступном сегменте локальной сети или по сетевым каналам вне вашего контроля), вам, вероятно, потребуется SSL, чтобы скрыть эти конфиденциальные данные. Как получить разумную реализацию SSL для вашей платформы, это другой вопрос.