Учитывая, что при разработке ASP можно использовать два языка: vbs и js, здесь представлены программные коды на обоих языках (двуязычная версия? YY средний...) И последнее многословное предложение: машина, на которой я печатал эту статью, не имеет ASP, поэтому предоставленный код не проверялся, и я приношу за это извинения. Если вы обнаружите какие-либо проблемы в коде, пожалуйста, не стесняйтесь комментировать ~ У меня толстая кожа ~
1. Принцип атаки
Подмена файлов cookie в основном использует небезопасную практику хранения информации для входа в систему пользователя в файлах cookie некоторыми системами управления пользователями в текущей сети. Его метод атаки относительно сложен по сравнению с такими уязвимостями, как уязвимости внедрения SQL, но он по-прежнему очень глуп.
Мы знаем, что обычная пользовательская система, основанная на файлах cookie, будет хранить в файлах cookie как минимум две переменные: имя пользователя и уровень пользователя, где имя пользователя — это имя пользователя, а уровень пользователя — это уровень пользователя. Когда наш браузер обращается к странице ASP, он отправляет что-то вроде
ПОЛУЧИТЬ /.../file.asp HTTP 1.0
...
Файлы cookie: имя пользователя=пользователь&уровень пользователя=1
...
пакет, то пока мы знаем имя пользователя администратора и значения уровня пользователя (предполагается, что это admin и 5 соответственно), мы можем передать
ПОЛУЧИТЬ /.../file.asp HTTP 1.0
...
Файлы cookie: имя пользователя=admin&userlevel=5
...
для получения прав администратора. Очень просто, не так ли? Однако до того, как эта уязвимость была обнаружена, почти все системы управления пользователями полагались на файлы cookie.
2. Надежно храните информацию о пользователях
Поскольку файлы cookie не являются безопасными и мы должны хранить информацию для входа в систему пользователя, где она должна храниться?
Мы заметили, что в ASP помимо Cookies есть еще Session, который может хранить информацию. Сессия хранится на сервере и не может быть случайно изменена клиентом, поэтому она имеет чрезвычайно высокий уровень безопасности. Таким образом, вы можете заменить все файлы cookie на сеансовые.
3. Храните информацию о пользователе в течение длительного времени
Использование сеанса для сохранения информации для входа пользователя, хотя и избавляет от проблемы обмана файлов cookie, сеанс не может храниться в течение длительного времени (срок действия сеанса по умолчанию IIS истекает через 20 минут после того, как пользователь перестает отвечать), поэтому описан гибридный метод хранения файлов cookie + сеанс. в этом разделе производится .
Существует два варианта этого метода. Первый заключается в сохранении имени пользователя и пароля в файлах cookie. Когда пользователь посещает страницу, в первую очередь считывается сеанс. При наличии содержимого сеанс имеет преимущественную силу. быть прочитаны, и информация, представленная в файлах cookie, будет использована. Войдите в систему, используя свое имя пользователя и пароль, чтобы определить, является ли содержимое файлов cookie законным. Если оно законно, оно будет сохранено в сеансе. Код для реализации этого метода выглядит следующим образом:
вбс:
Скопируйте код кода следующим образом:
<%
Дим имя пользователя, пароль
имя пользователя = сеанс (имя пользователя)
если имя пользователя = тогда
' В сеансе нет информации для входа пользователя
имя пользователя = Request.Cookies(имя пользователя)
пароль = Request.Cookies(пароль)
' Обратите внимание, что имя пользователя и пароль, полученные в двух приведенных выше предложениях, должны быть защищены от уязвимостей SQL-инъекций (то есть отфильтровываются одинарные кавычки), которые здесь опущены.
если имя пользователя = или пароль = тогда
'Пользователь не авторизован
...
еще
' Предполагается, что объекты conn и rs созданы
rs.Open SELECT TOP 1 * FROM [user] WHERE username=' & username & ' AND пароль=' & пароль & ', conn, 1, 3
если rs.eof тогда
«Информация в файлах cookie является незаконной»
...
еще
«Информация в файлах cookie легальна, войдите в систему автоматически»
Сеанс (имя пользователя) = имя пользователя
...
конец, если
конец, если
еще
'Информация о пользователе уже существует в сеансе, прочитайте ее напрямую
...
конец, если
%>
js:
Скопируйте код кода следующим образом:
<%
вар имя пользователя, пароль;
имя пользователя = сеанс (имя пользователя) + ;
if (имя пользователя == || имя пользователя == неопределенное) {
// В сеансе нет информации о пользователе
имя пользователя = Request.Cookies(имя пользователя) + ;
пароль = Request.Cookies(пароль) + ;
// Обратите внимание, что имя пользователя и пароль, полученные в двух приведенных выше предложениях, должны предотвратить уязвимости SQL-инъекций (то есть отфильтровать одинарные кавычки '), которые здесь опущены.
if (имя пользователя == || имя пользователя == неопределенное || пароль == || пароль == неопределенное) {
//Пользователь не авторизован
...
}
еще {
// Предполагается, что объекты conn и rs созданы
rs.Open(SELECT TOP 1 * FROM [user] WHERE username=' + имя пользователя + ' AND пароль=' + пароль + ', conn, 1, 3);
если (rs.eof) {
//Информация в файлах cookie является незаконной.
...
}
еще {
//Информация в файлах cookie является законной, вход в систему осуществляется автоматически.
Сеанс (имя пользователя) = имя пользователя + ;
...
}
}
}
еще {
// Информация о пользователе уже существует в сеансе, прочитайте ее напрямую
...
}
%>
Однако этот метод не очень безопасен для пользователей, поскольку браузер будет передавать файлы cookie каждый раз, когда они посещают страницу, и как только файлы cookie, содержащие пароли, будут получены другими, учетная запись пользователя будет украдена. Для этой ситуации существует второй метод, который заключается в добавлении поля кода проверки в базу данных информации о пользователе. Когда пользователь входит в систему, случайно генерируется длинное целочисленное значение проверки и сохраняется в поле кода проверки, а также имя пользователя и этот код проверки. значение добавляется. Храните файлы cookie вместо пароля. При проверке информации пользователя в файлах cookie проверяются только имя пользователя и код проверки. Преимущество этого метода заключается в том, что даже если хакер получает файлы cookie пользователя, он может использовать только временно сгенерированный код проверки для входа в систему, но не может получить пароль пользователя. Пока этот пользователь снова войдет в систему, используя имя пользователя и пароль, значение кода проверки изменится, и хакеры не смогут войти в систему с помощью исходного кода проверки.
Реализация этого метода требует лишь небольших изменений в коде метода 1 выше. Во-первых, в вашей программе входа необходимо добавить пункт, где сохраняется информация о пользователе после проверки:
вбс:
Скопируйте код кода следующим образом:
<%
Response.Cookies(verifycode) = int(rnd * 2100000000)
%>
js:
Скопируйте код кода следующим образом:
<%
Response.Cookies(verifycode) = Math.floor(Math.random() * 2100000000);
%>
Затем измените проверку файлов cookie (пароль) на проверку файлов cookie (verifycode) в коде подтверждения, указанном выше.
4. Заключение
Благодаря нашему анализу и обработке уязвимость подмены файлов cookie была полностью устранена. С тех пор наша программа ASP стала более безопасной.